Sauvegarder un serveur Linux avec Borg via SSH

Ce que vous allez mettre en place avec Borg et SSH

Sauvegarder un serveur Linux avec Borg via SSH (Secure Shell) tient en quatre pièces : un dépôt chiffré sur une machine que le serveur ne partage avec rien, un fichier d'environnement qui porte BORG_REPO et BORG_PASSPHRASE, un script d'une vingtaine de lignes, et un timer systemd qui le lance chaque nuit. Le serveur sauvegardé ne rencontre jamais une question interactive, et la cible ne reçoit jamais un octet en clair. Vous saurez restaurer, parce que vous l'aurez fait avant d'en avoir besoin.

Ce guide est écrit pour Ubuntu 24.04 et pour Borg 1.2, la version que cette image installe. Vous jouez chaque commande une première fois contre un dépôt local, pour apprendre sans réseau, puis vous la rejouez à l'identique contre un dépôt ssh://. C'est le point fort de Borg : la cible est une URL, pas une autre syntaxe.

Installer Borg, puis vérifier sa version avant d'écrire une commande

Le paquet s'installe en premier, sur le serveur à sauvegarder. Sur une image neuve, la commande borg n'existe pas encore : lancée avant cette étape, borg --version répond command not found.

sudo apt update && sudo apt install -y borgbackup

Une fois le paquet en place, demandez la version :

borg --version

Le paquet borgbackup d'Ubuntu 24.04 est en 1.2 (1.2.8 au moment où j'écris, septembre 2026) et borg --version doit afficher une version qui commence par 1.2. Ce chiffre décide de tout ce qui suit. Borg 2 renomme les commandes : borg init devient borg repo-create, la liste des archives devient borg repo-list, et la notation dépôt::archive disparaît au profit de -r et de BORG_REPO. Borg 2 est encore en bêta en septembre 2026. Si votre borg --version commence par 2, ce guide ne correspond pas à votre binaire. La même règle vaut pour la cible : un client 1.2 dialogue avec un borg serve 1.x, et deux versions majeures différentes ne se parlent pas.

Où envoyer la sauvegarde : un second VPS ou une Storage Box, pas de stockage objet

Borg a besoin d'un borg qui tourne à l'autre bout de la connexion. Le client ouvre une session SSH, lance borg serve sur la cible et dialogue avec lui par un protocole RPC (remote procedure call, appel de procédure à distance). Cela limite les cibles à deux familles.

La première est un second VPS que vous administrez, chez un autre fournisseur ou au moins dans un autre datacenter que le serveur sauvegardé. Vous y installez le même paquet, vous créez un utilisateur dédié et vous contrôlez chaque option de son fichier authorized_keys, ce qui rend possible le mode append-only décrit plus bas. Transformer un VPS en cible de sauvegarde hors site détaille le dimensionnement et le durcissement SSH de cette machine.

La seconde est une Storage Box Hetzner. Hetzner y fournit borg et expose SSH sur le port 23, donc l'URL ressemble à ssh://u123456@u123456.your-storagebox.de:23/./borg/serveur1. Vous ne gérez pas le serveur SSH de la box : la clé publique se dépose par SFTP en suivant la documentation Hetzner, et les restrictions command= ne sont pas à votre main. Les box sont hébergées en Allemagne ou en Finlande, ce qui répond à la question de résidence des données pour un lecteur français.

Ce que Borg ne sait pas faire : parler à un stockage objet. OVH Object Storage et Scaleway Object Storage exposent une API S3, pas un shell SSH, et borg serve ne peut pas y tourner. Si votre cible est un bucket S3, l'outil est restic, et le comparatif restic ou BorgBackup explique pourquoi la destination décide du choix. Enfin, le snapshot proposé par votre hébergeur n'est pas une sauvegarde : il vit chez le même fournisseur, sur la même infrastructure, et disparaît avec le compte. Snapshot ou sauvegarde fait la différence en détail.

Préparer l'environnement : BORG_REPO et BORG_PASSPHRASE dans un fichier

Borg lit sa configuration dans des variables d'environnement. BORG_REPO désigne le dépôt, BORG_PASSPHRASE répond à la question de la phrase de passe. Quand les deux sont posées, aucune commande ne pose de question, ce qui est la condition pour tourner sous systemd. Le fichier appartient à root, en mode 600, parce qu'il contient le secret qui déchiffre toutes vos sauvegardes.

sudo install -d -m 700 /etc/borg
PHRASE=$(head -c 32 /dev/urandom | base64)
sudo sh -c "umask 077; cat > /etc/borg/env" <<EOF
BORG_REPO="/var/backups/borg-test"
BORG_PASSPHRASE="$PHRASE"
EOF
sudo cat /etc/borg/env

Copiez la phrase de passe dans votre gestionnaire de mots de passe maintenant, pas plus tard. Le dépôt local /var/backups/borg-test sert uniquement à apprendre les commandes : un dépôt sur le disque du serveur qu'il sauvegarde disparaît avec lui. Vous le remplacerez par l'URL ssh:// sans toucher au reste.

Les commandes suivantes s'exécutent dans un shell root, avec le fichier chargé dans l'environnement :

sudo -i
set -a; . /etc/borg/env; set +a
echo "$BORG_REPO"

N'écrivez pas sudo borg ... : sudo remet l'environnement à zéro, donc Borg ne verrait ni BORG_REPO ni BORG_PASSPHRASE, et vous retrouveriez la question interactive que vous cherchez à éviter. set -a exporte toutes les variables que . assigne, et set +a referme cette parenthèse.

Créer le dépôt chiffré avec borg init en mode repokey

borg init --encryption=repokey-blake2
borg key export :: /root/borg-cle-serveur1.txt
chmod 600 /root/borg-cle-serveur1.txt

borg init sans argument crée le dépôt désigné par BORG_REPO et, comme BORG_PASSPHRASE est posée, il ne demande rien. Le mode repokey range la clé de chiffrement dans la configuration du dépôt, elle-même protégée par la phrase de passe. Le mode keyfile la range dans ~/.config/borg/keys sur le client, ce qui signifie qu'un serveur réinstallé sans ce fichier a perdu ses sauvegardes. Avec repokey, le dépôt et la phrase de passe suffisent pour restaurer depuis n'importe quelle machine.

borg key export écrit une copie de la clé, toujours chiffrée par la phrase de passe, dans un fichier. Elle sert le jour où la configuration du dépôt est corrompue. Rangez ce fichier hors du serveur, et si possible dans un autre endroit que la phrase de passe. borg key export --paper :: produit une version à imprimer. Chaque dépôt a sa propre clé : quand vous créerez le dépôt distant, exportez de nouveau.

C'est aussi la réponse au RGPD (règlement général sur la protection des données) pour ce qui relève de la technique. Le chiffrement se fait sur le serveur sauvegardé, avant que le moindre octet parte sur le réseau. La cible stocke des segments chiffrés dont elle ne connaît ni les noms de fichiers, ni le contenu, ni l'arborescence, ni les métadonnées. L'article 32 demande des mesures techniques appropriées et cite le chiffrement en exemple ; le chiffrement des données au repos chez un tiers en est une, à condition que la clé et la phrase de passe restent chez vous. Le chiffrement ne règle pas tout : où la cible se trouve reste une question à part, et résidence des données et coût d'un VPS de stockage européen la traite. Si la cible est un VPS de stockage à vous, chiffrer ses données sur un VPS de stockage couvre la couche disque, en plus de celle de Borg.

Première archive : borg create avec des exclusions

borg create --stats --list --filter AME \
  --exclude-caches \
  --exclude '/home/*/.cache' \
  ::serveur1-{now:%Y-%m-%d_%H-%M-%S} \
  /etc /home

Une archive est un instantané des chemins listés, nommé ici serveur1- suivi de la date. {now:...} est un espace réservé que Borg remplace à l'exécution, ce qui donne un nom unique à chaque passage. Le :: devant le nom signifie « dans le dépôt BORG_REPO ».

--exclude-caches ignore tout répertoire contenant un fichier CACHEDIR.TAG, ce que fait cargo pour ses répertoires target, et Borg pour son propre cache. --exclude '/home/*/.cache' retire les caches utilisateur. Le motif est un motif shell, et Borg ignore la barre oblique initiale, donc il désigne home/alice/.cache tel que l'archive le stocke. Ajoutez une ligne --exclude par chemin à écarter, plutôt qu'un seul motif que vous ne saurez plus relire dans six mois.

--stats affiche trois tailles à la fin : originale, compressée, dédupliquée. La troisième est ce que ce passage a réellement écrit dans le dépôt. Relancez la même commande une minute plus tard : la taille dédupliquée tombe presque à zéro, parce que Borg découpe les fichiers en blocs, calcule une empreinte par bloc et ne stocke un bloc qu'une fois, quelle que soit l'archive qui le référence. --list --filter AME n'affiche que les fichiers ajoutés (A), modifiés (M) ou en erreur (E), ce qui garde le journal lisible.

Pour une base de données, sauvegardez un dump (pg_dump, mysqldump) écrit dans un dossier que Borg lit, jamais les fichiers vivants sous /var/lib : ils changent pendant la lecture, et le moteur refusera de charger la copie.

Lister, puis restaurer dans un répertoire de test

borg list
ARCHIVE=$(borg list --last 1 --short)
borg list "::$ARCHIVE" etc/passwd etc/group

borg list sans archive énumère les archives du dépôt, avec leur date. --last 1 --short ne renvoie que le nom de la plus récente, ce qui évite de le recopier à la main. Avec une archive, borg list énumère les fichiers qu'elle contient, ici limités aux chemins passés en argument. Notez l'absence de barre oblique initiale : les chemins sont stockés en relatif.

mkdir -p /root/restauration-test && cd /root/restauration-test
borg extract --list "::$ARCHIVE" etc/passwd
diff /etc/passwd etc/passwd && echo identique

borg extract écrit toujours dans le répertoire courant et n'a pas d'option de destination. C'est pourquoi la première ligne se place dans un répertoire vide : lancé depuis /, il écraserait les fichiers du système, ce qui est le comportement voulu pour une restauration complète et pas pour un test. Le diff doit afficher identique. Vous venez de faire votre premier test de restauration. Les suivants ont leur section à la fin de ce guide.

Faire le ménage : borg prune, puis borg compact

borg prune --list --glob-archives 'serveur1-*' \
  --keep-daily 7 --keep-weekly 4 --keep-monthly 6
borg compact

prune conserve sept archives quotidiennes, quatre hebdomadaires et six mensuelles. Tout le reste est marqué comme supprimé. --glob-archives limite l'opération aux archives dont le nom commence par serveur1-, ce qui compte dès qu'un second serveur écrit dans le même dépôt ou que vous gardez une archive manuelle à part. --list affiche ce qu'il garde et ce qu'il retire.

Depuis Borg 1.2, prune ne libère aucun octet. Il enregistre une transaction qui marque des données comme supprimées. C'est borg compact qui réécrit les segments et rend l'espace au disque. Un dépôt qui grossit alors que vous élaguez chaque nuit a presque toujours cette cause : compact n'est jamais lancé.

Passer au dépôt distant : ssh://utilisateur@hote:port/./depot

Rien ne change côté commandes. Seule BORG_REPO change, et l'URL dit à Borg de lancer borg serve sur la cible à travers SSH. Cette section demande une seconde machine joignable en SSH ; tant que vous ne l'avez pas, le dépôt local des sections précédentes reste utilisable tel quel, timer compris.

Sur le serveur de sauvegarde, installez Borg et créez un utilisateur sans mot de passe :

sudo apt update && sudo apt install -y borgbackup
sudo adduser --disabled-password --gecos "" borg
sudo -u borg install -d -m 700 /home/borg/.ssh /home/borg/depots

Sur le serveur à sauvegarder, générez une clé SSH réservée à Borg, sans phrase de passe puisque systemd l'utilisera sans vous :

sudo install -d -m 700 /root/.ssh
sudo ssh-keygen -t ed25519 -N "" -f /root/.ssh/borg_ed25519 -C "borg serveur1"
sudo cat /root/.ssh/borg_ed25519.pub

Collez la clé publique dans /home/borg/.ssh/authorized_keys sur le serveur de sauvegarde, sur une seule ligne, précédée des options qui la bornent :

command="borg serve --restrict-to-repository /home/borg/depots/serveur1 --append-only",restrict ssh-ed25519 AAAAC3... borg serveur1

sudo chown borg:borg /home/borg/.ssh/authorized_keys
sudo chmod 600 /home/borg/.ssh/authorized_keys

command= remplace toute commande que le client demanderait par celle-ci : avec cette clé, on ne peut rien faire d'autre que borg serve. --restrict-to-repository n'autorise que ce dépôt, ni un autre chemin, ni un sous-répertoire. restrict coupe la redirection de ports, l'agent, le X11 et le pseudo-terminal, et coupera aussi les fonctionnalités SSH ajoutées dans une version future. --append-only a sa propre section juste après. Si ce serveur écoute sur Internet, fail2ban devant SSH sur Ubuntu 24.04 absorbe le bruit des tentatives de connexion.

Revenez sur le serveur à sauvegarder et modifiez /etc/borg/env :

BORG_REPO="ssh://borg@203.0.113.10:22/./depots/serveur1"
BORG_PASSPHRASE="<la même phrase que plus haut>"
BORG_RSH="ssh -i /root/.ssh/borg_ed25519 -o StrictHostKeyChecking=accept-new"

Dans l'URL, /./depots/serveur1 est un chemin relatif au répertoire courant de la session SSH, donc au répertoire personnel de borg : /home/borg/depots/serveur1, exactement ce que --restrict-to-repository autorise. Un chemin absolu s'écrit ssh://borg@203.0.113.10:22/home/borg/depots/serveur1 et fonctionne aussi. Pour une Storage Box, l'URL devient ssh://u123456@u123456.your-storagebox.de:23/./borg/serveur1, avec le port 23. BORG_RSH remplace la commande ssh par défaut : -i désigne la clé dédiée, et accept-new enregistre la clé d'hôte à la première connexion tout en refusant une clé qui aurait changé. Sans cette option, la première exécution sous systemd, où personne ne peut répondre « yes », s'arrête sur Host key verification failed.

Rechargez l'environnement et rejouez la séquence :

set -a; . /etc/borg/env; set +a
borg init --encryption=repokey-blake2
borg key export :: /root/borg-cle-serveur1-distant.txt
borg create --stats --exclude-caches --exclude '/home/*/.cache' \
  ::serveur1-{now:%Y-%m-%d_%H-%M-%S} /etc /home
borg list

Les mêmes list, extract et prune que plus haut fonctionnent sans modification. La seule différence visible est le temps : chaque bloc traverse le réseau, et la première archive envoie tout. Les suivantes n'envoient que les blocs nouveaux, parce que le client garde dans /root/.cache/borg un cache des empreintes déjà présentes dans le dépôt.

Mode append-only : ce qu'un attaquant ne peut pas effacer

Le serveur sauvegardé détient tout ce qu'il faut pour détruire ses propres sauvegardes : la clé SSH et la phrase de passe sont dans /etc/borg/env. Un rançongiciel qui obtient root sur ce serveur peut lancer borg delete sur chaque archive, puis chiffrer le disque. Vos sauvegardes disparaissent avec la machine qu'elles devaient protéger.

--append-only sur la ligne authorized_keys ferme cette porte. À travers cette clé, borg serve ajoute des données et n'en supprime jamais. prune et delete fonctionnent en apparence : ils écrivent une nouvelle transaction qui marque des archives comme supprimées, mais les segments restent sur le disque, et vous pouvez revenir en arrière en retirant les segments écrits après l'attaque, comme le décrit la documentation de Borg. borg compact à travers cette clé ne produit ni avertissement ni erreur, et ne compacte rien. La documentation le dit en toutes lettres, et c'est le piège de ce mode : le dépôt grossit jusqu'à ce que quelqu'un compacte sans la restriction.

Un second piège se cache dans le code de Borg : borg init recopie l'état append-only de la connexion dans le fichier config du dépôt. Comme vous avez initialisé à travers la clé restreinte, le dépôt lui-même porte append_only = 1, et un compact lancé localement sur le serveur n'y ferait rien non plus, toujours sans un mot. Vérifiez et remettez la valeur à 0 côté serveur de sauvegarde. La restriction reste portée par la clé SSH, ce qui suffit :

sudo -u borg borg config /home/borg/depots/serveur1 append_only
sudo -u borg borg config /home/borg/depots/serveur1 append_only 0

Le compactage se fait ensuite depuis ce même serveur, par vous, après avoir vérifié que la liste des archives est celle que vous attendez :

sudo -u borg borg list /home/borg/depots/serveur1
sudo -u borg borg compact /home/borg/depots/serveur1

list vous demande la phrase de passe, puisqu'il doit lire le manifeste chiffré. compact ne la demande pas : il déplace des segments chiffrés sans les ouvrir. Il pose un verrou exclusif sur le dépôt, donc s'il tombe en même temps que la sauvegarde nocturne, l'un des deux s'arrête sur Failed to create/acquire the lock ... (timeout). Choisissez une heure creuse, une fois par mois. Sur une Storage Box, cette protection n'est pas à votre main puisque vous n'éditez pas les options de la clé : les snapshots de la box, déclenchés côté Hetzner et invisibles pour le client, jouent le même rôle de copie que le serveur compromis ne peut pas effacer.

Automatiser avec un timer systemd

Un cron ferait l'affaire, mais un timer systemd apporte le journal, le rattrapage d'un passage manqué, le chargement du fichier d'environnement sans script d'emballage, et un état failed visible dans systemctl. Service et timer systemd sur un VPS explique la mécanique ; voici le cas Borg.

Le script, dans /usr/local/sbin/borg-sauvegarde :

#!/bin/bash
set -uo pipefail

borg create --stats --exclude-caches \
  --exclude '/home/*/.cache' \
  ::serveur1-{now:%Y-%m-%d_%H-%M-%S} \
  /etc /home /srv
create_rc=$?

borg prune --list --glob-archives 'serveur1-*' \
  --keep-daily 7 --keep-weekly 4 --keep-monthly 6
prune_rc=$?

# Sans effet a travers une cle append-only ; libere l'espace partout ailleurs.
borg compact
compact_rc=$?

# Codes de retour Borg : 0 succes, 1 avertissement, 2 erreur.
if [ "$create_rc" -ge 2 ] || [ "$prune_rc" -ge 2 ] || [ "$compact_rc" -ge 2 ]; then
  exit 2
fi
exit 0

Borg renvoie 1 quand un fichier a changé pendant la lecture ou qu'un chemin est illisible, et 2 quand l'opération a échoué. Le script laisse passer les avertissements, sinon un fichier de log qui bouge empêcherait le prune toutes les nuits, et il remonte les erreurs à systemd, qui marque alors l'unité failed. Remplacez /srv par vos données réelles, et ajoutez le dump de base de données avant borg create si vous en avez une.

Le service, dans /etc/systemd/system/borg-sauvegarde.service :

[Unit]
Description=Sauvegarde Borg de serveur1
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
EnvironmentFile=/etc/borg/env
ExecStart=/usr/local/sbin/borg-sauvegarde
Nice=10
IOSchedulingClass=idle

Le timer, dans /etc/systemd/system/borg-sauvegarde.timer :

[Unit]
Description=Sauvegarde Borg quotidienne

[Timer]
OnCalendar=*-*-* 03:30:00
RandomizedDelaySec=20min
Persistent=true

[Install]
WantedBy=timers.target

sudo chmod 755 /usr/local/sbin/borg-sauvegarde
sudo systemctl daemon-reload
sudo systemctl enable --now borg-sauvegarde.timer
sudo systemctl start borg-sauvegarde.service
sudo journalctl -u borg-sauvegarde.service -n 40 --no-pager
systemctl list-timers borg-sauvegarde.timer

EnvironmentFile= charge BORG_REPO, BORG_PASSPHRASE et BORG_RSH exactement comme votre set -a le faisait, ce qui est la raison d'avoir mis ces lignes dans un fichier plutôt que dans votre .bashrc. La commande borg create vit dans un script et non dans ExecStart= parce que systemd lit les % d'une ligne ExecStart= comme ses propres spécificateurs (%m est l'identifiant de la machine), et la commande n'arrive jamais à Borg telle que vous l'avez écrite. Persistent=true rejoue un passage manqué au prochain démarrage si le serveur était éteint à 3 h 30. RandomizedDelaySec étale le départ, ce qui évite que dix serveurs frappent la même cible à la même seconde. Enfin, OnCalendar s'exprime dans le fuseau horaire du serveur : un VPS livré en UTC lance la sauvegarde à 5 h 30, heure de Paris, en été. timedatectl vous dit lequel il utilise.

journalctl doit montrer les statistiques de create, la liste de prune et une fin sans erreur. list-timers doit afficher la prochaine exécution dans la colonne NEXT. Une unité failed se lit avec systemctl status borg-sauvegarde.service.

Tester la restauration, sinon ce n'est pas une sauvegarde

Une sauvegarde que personne n'a restaurée est une hypothèse. Le test complet se fait depuis une autre machine, idéalement un VPS neuf que vous détruisez ensuite, parce que c'est la situation d'un vrai sinistre : le serveur d'origine n'existe plus.

Sur cette machine, installez borgbackup, recréez /etc/borg/env avec la même BORG_REPO, la même phrase de passe et une clé SSH acceptée par le serveur de sauvegarde, puis :

sudo -i
set -a; . /etc/borg/env; set +a
borg list
ARCHIVE=$(borg list --last 1 --short)
mkdir -p /root/restauration-test && cd /root/restauration-test
borg extract --list "::$ARCHIVE" etc home
ls etc home

La première commande depuis une machine inconnue du dépôt reconstruit le cache local des empreintes, ce qui prend du temps sur un gros dépôt et n'est pas une erreur. L'extraction restitue les propriétaires, les permissions, les dates et les liens symboliques. Pour une restauration complète, vous vous placeriez dans / avant borg extract, après avoir réinstallé le système de base.

Ce test révèle une dépendance que l'on oublie : la clé SSH privée. Si le serveur d'origine a brûlé, /root/.ssh/borg_ed25519 a brûlé avec lui, et le serveur de sauvegarde refuse la machine neuve. Rangez cette clé privée avec la clé exportée par borg key export, ou gardez un autre accès au serveur de sauvegarde pour y autoriser une nouvelle clé. Faites le test une fois par mois, notez la date, et ajoutez borg check une fois par trimestre : il vérifie la cohérence du dépôt, et borg check --verify-data relit chaque bloc, ce qui est long mais sans appel.

Les pannes que vous verrez, avec le message exact

Repository /var/backups/borg-test does not exist. BORG_REPO pointe sur un chemin qui n'a pas été initialisé, ou l'environnement n'est pas chargé dans ce shell. Un echo "$BORG_REPO" vide signifie que vous avez oublié set -a; . /etc/borg/env; set +a, ou que vous êtes passé par sudo borg.

passphrase supplied in BORG_PASSPHRASE, by BORG_PASSCOMMAND or via BORG_PASSPHRASE_FD is incorrect. La phrase du fichier n'est pas celle du dépôt. Cela arrive quand on régénère /etc/borg/env avec une nouvelle phrase tirée de /dev/urandom alors que le dépôt existe déjà. Reprenez la phrase depuis le gestionnaire de mots de passe.

Failed to create/acquire the lock ... (timeout). Un autre borg tient le dépôt : la sauvegarde de la nuit tourne encore, ou un compact côté serveur. borg break-lock retire un verrou orphelin laissé par un plantage, jamais un verrou tenu par un processus vivant.

Connection closed by remote host, précédé d'une ligne Remote: qui dit que la commande borg est introuvable. Le paquet n'est pas installé sur la cible, ou il n'est pas dans le PATH d'une session SSH non interactive. BORG_REMOTE_PATH=/chemin/vers/borg dans /etc/borg/env donne le chemin complet.

Repository path not allowed: ... Le chemin de l'URL ne correspond pas à celui de --restrict-to-repository. Comparez les deux caractère par caractère : /./depots/serveur1 se résout dans le répertoire personnel de l'utilisateur SSH, et un chemin absolu différent change le résultat.

Host key verification failed. Message d'OpenSSH, pas de Borg : la clé d'hôte de la cible n'est pas dans /root/.ssh/known_hosts et personne n'est là pour répondre. StrictHostKeyChecking=accept-new dans BORG_RSH règle le premier contact. Si le message apparaît après des mois de bon fonctionnement, la clé de la cible a changé, et c'est la question à poser avant de forcer quoi que ce soit.

Le dépôt grossit malgré prune. compact ne tourne pas, ou il tourne à travers une clé append-only, où il ne fait rien et ne le dit pas, ou le fichier config du dépôt porte encore append_only = 1 parce que borg init est passé par la clé restreinte. Vérifiez avec borg config, puis compactez depuis le serveur de sauvegarde.

FAQ

Borg peut-il sauvegarder vers OVH Object Storage ou un bucket S3 ?

Non. Borg a besoin d'un borg serve à l'autre bout d'une connexion SSH, et un stockage objet expose une API HTTP, pas un shell. Les cibles possibles sont un serveur Linux où Borg est installé, ou une Storage Box Hetzner qui le fournit sur le port 23. Pour un bucket S3 chez OVH ou Scaleway, l'outil est restic, qui parle S3 nativement.

Que se passe-t-il si je perds la phrase de passe Borg ?

Les données sont perdues. Le dépôt contient la clé, mais elle est chiffrée par la phrase de passe, et il n'existe aucun mécanisme de récupération. Rangez la phrase de passe dans un gestionnaire de mots de passe, la clé exportée par borg key export à un autre endroit, et la clé SSH privée avec elle : les trois sont nécessaires pour restaurer depuis une machine neuve.

Pourquoi borg prune ne libère-t-il pas d'espace disque ?

Depuis Borg 1.2, prune marque des archives comme supprimées dans une nouvelle transaction et ne touche pas aux segments. Seul borg compact réécrit les segments et rend l'espace. Si compact passe par une clé SSH en --append-only, ou si le dépôt porte append_only = 1 dans son fichier config, il ne fait rien et n'affiche aucun avertissement. Remettez la valeur à 0 avec borg config, puis lancez compact depuis le serveur de sauvegarde, après avoir vérifié la liste des archives.

Faut-il utiliser Borg 1.2 ou Borg 2 ?

Celle que votre image installe, des deux côtés. Ubuntu 24.04 fournit Borg 1.2 et ce guide est écrit pour elle. Borg 2, encore en bêta en septembre 2026, renomme les commandes (borg repo-create remplace borg init) et abandonne la notation ::. Un client et un borg serve de versions majeures différentes ne se parlent pas, donc vérifiez aussi la version de la cible.

Puis-je sauvegarder une base de données avec Borg ?

Oui, par un dump. Faites écrire pg_dump ou mysqldump dans un répertoire que borg create lit, avant la sauvegarde, dans le même script. Copier les fichiers de /var/lib/postgresql pendant que le serveur écrit donne une copie incohérente que le moteur refusera de charger.