Un fichier de configuration disparaît, un service ne redémarre plus et la sauvegarde Borg semble rassurante. Pourtant, une archive visible dans BorgBackup ne prouve pas que vous pourrez récupérer le bon fichier au bon endroit.
La méthode la moins risquée consiste à restaurer dans un répertoire vide, à relire le résultat, puis à comparer avant de toucher au chemin actif. Vous saurez ainsi si le dépôt, le mot de passe, l’archive et les données restaurées sont réellement utilisables.
Préparer un répertoire de restauration isolé
Cette procédure suppose un dépôt Borg déjà initialisé et chiffré. Utilisez le même compte, la même clé SSH et le même moyen de fournir la phrase de passe que votre tâche de sauvegarde. Si vous restaurez des fichiers système, l’extraction doit disposer des droits nécessaires pour relire leurs propriétaires et permissions.
Avant de lancer Borg, notez quatre éléments : l’URL exacte du dépôt, le nom de l’archive, le chemin à récupérer et un emplacement de test avec assez d’espace libre. Un disque monté sous /srv ou /var/tmp convient mieux que / ou /etc.
export BORG_REPO='ssh://[email protected]/./srv/borg/serveur1'
mkdir -p /srv/restore-borg-test
findmnt -T /srv/restore-borg-test
df -h /srv/restore-borg-testfindmnt doit montrer le système de fichiers qui recevra l’extraction. df -h évite de remplir une partition locale avec une archive plus grosse que prévu. La documentation de BorgBackup détaille le format des dépôts et des archives.
Lister l’archive et contrôler le dépôt Borg
Commencez par la lecture. Borg doit ouvrir le dépôt et afficher les archives sans erreur de clé, de chemin ou d’authentification. Copiez ensuite le nom exact de l’archive retenue dans la variable ARCHIVE.
borg list
export ARCHIVE='2026-08-31T02:15:00'
borg list ::"$ARCHIVE"
borg check --repository-onlyLa dernière commande vérifie la structure du dépôt, mais elle ne remplace pas une restauration. Un contrôle avec --verify-data relit les données et peut être long sur un dépôt distant. Planifiez-le hors d’une période de sauvegarde ou de forte activité disque.
borg check --verify-dataExtraire un fichier dans le répertoire de test
Choisissez un fichier utile, par exemple la configuration d’un service. Les chemins listés par Borg ne commencent généralement pas par /. Vérifiez d’abord que le fichier demandé appartient bien à l’archive, puis simulez l’extraction.
borg list ::"$ARCHIVE" etc/mon-service/config.yml
borg extract --dry-run ::"$ARCHIVE" etc/mon-service/config.ymlLe mode --dry-run affiche le travail prévu sans créer le fichier. S’il ne remonte ni erreur de déchiffrement ni chemin absent, placez-vous dans le répertoire de test avant l’extraction réelle. La commande borg extract recrée alors l’arborescence sous le dossier courant.
cd /srv/restore-borg-test
borg extract ::"$ARCHIVE" etc/mon-service/config.yml
stat etc/mon-service/config.yml
sha256sum etc/mon-service/config.ymlComparer avant de remettre le fichier en production
Le fichier restauré est maintenant lisible hors de la production. S’il existe encore une version active, comparez-les avant toute copie. Des différences peuvent être normales après une modification récente. Elles doivent être comprises, pas écrasées par réflexe.
diff -u /etc/mon-service/config.yml \
/srv/restore-borg-test/etc/mon-service/config.ymlPour un dossier, remplacez diff -u par diff -ru. Gardez la restauration de test jusqu’à la fin de l’incident. Copier directement depuis l’archive vers /etc, /var/lib ou une base de données peut remplacer une version plus récente et compliquer le retour arrière.
Pour une sauvegarde cloud gérée avec un autre outil, le même principe reste valable : l’article sur Rclone sous Linux applique aussi une restauration dans un emplacement séparé. Borg est un bon choix quand vous avez besoin de déduplication et de chiffrement, mais je privilégierais toujours une extraction de test régulière plutôt qu’un rapport de sauvegarde marqué comme réussi.