Un fichier de configuration supprimé ou remplacé trop vite peut remettre un service dans le mauvais état. Avec Restic, le piège consiste à restaurer directement sur le chemin actif. Récupérez d’abord le fichier dans un répertoire de test, puis comparez-le avant toute copie.
La méthode part d’un dépôt déjà initialisé et accessible avec les identifiants habituels. Elle vise un fichier précis, par exemple /etc/mon-service/config.ini, et laisse la version actuellement utilisée intacte tant que le contrôle n’est pas terminé.
Identifier le snapshot et le chemin à récupérer
Définissez le dépôt avec les mêmes variables ou le même fichier d’environnement que votre sauvegarde. Évitez de coller le mot de passe du dépôt dans l’historique Bash. Si le service Restic tourne déjà dans un script ou une unité systemd, reprenez son mécanisme d’authentification au lieu d’en créer un autre pour la restauration.
Commencez par lister les snapshots qui contiennent le chemin recherché :
export RESTIC_REPOSITORY=/srv/restic-repo
restic snapshots --path /etc/mon-service/config.iniLa sortie affiche les identifiants, la date, l’hôte et les chemins sauvegardés. Choisissez un identifiant précis plutôt que latest si plusieurs machines ou plusieurs sauvegardes peuvent contenir ce fichier. Dans cet exemple, remplacez 8f3a1c2d par l’identifiant retenu.
SNAPSHOT=8f3a1c2d
restic ls "$SNAPSHOT" --path /etc/mon-service/config.inirestic ls confirme le chemin présent dans l’archive avant d’écrire quoi que ce soit. Si aucun résultat ne correspond, arrêtez-vous là. Un chemin mal saisi ou un snapshot pris après l’incident ne sera pas réparé par une seconde restauration.
Restaurer dans un répertoire de test
Créez un répertoire réservé au contrôle. Il ne doit pas être un point de montage de production ni le dossier du service concerné :
sudo install -d -m 0700 /srv/restore-restic-test
restic restore "$SNAPSHOT"
--target /srv/restore-restic-test
--include /etc/mon-service/config.iniRestic recrée l’arborescence sous la cible. Le fichier restauré se trouve donc ici :
/srv/restore-restic-test/etc/mon-service/config.iniCe répertoire séparé évite d’écraser /etc/mon-service/config.ini pendant le test. C’est le choix à garder pour un fichier de service, une clé de configuration ou une base exportée. Une restauration directe à la racine transforme une erreur de snapshot en incident de production.
Comparer le fichier avant de le remettre en service
Contrôlez d’abord les droits, la taille et les différences. La commande diff ne modifie aucun fichier :
sudo stat /etc/mon-service/config.ini
sudo stat /srv/restore-restic-test/etc/mon-service/config.ini
sudo diff -u
/etc/mon-service/config.ini
/srv/restore-restic-test/etc/mon-service/config.iniUn diff sans sortie retourne le code 0 : les deux contenus sont identiques. S’il affiche des lignes supprimées et ajoutées, lisez-les avant de décider. Une ancienne adresse, un port ou un secret expiré peut être exactement la raison pour laquelle le fichier a changé.
Quand la copie restaurée est la bonne, sauvegardez d’abord la version active, puis remplacez-la dans une courte fenêtre de maintenance. Vérifiez ensuite la syntaxe et l’état du service avec les commandes adaptées à votre logiciel, par exemple systemctl status mon-service et le journal associé.
Le contrôle de restauration mérite le même soin qu’une sauvegarde. Le guide BorgBackup applique la même logique avec une extraction hors production. Pour retrouver un chemin avant de lancer Restic, la commande find sous Linux évite de restaurer un fichier homonyme au mauvais emplacement.
Quand ne pas restaurer un seul fichier
Un fichier isolé suffit pour une configuration supprimée ou une version écrasée. Il ne suffit pas toujours pour une application qui répartit son état entre une base de données, des fichiers et un journal de transactions. Dans ce cas, restaurez un ensemble cohérent dans une VM ou un répertoire isolé, puis validez la procédure avec le service arrêté ou une copie de test.
La documentation Restic sur la restauration décrit le ciblage par snapshot, chemin et répertoire de destination. Gardez le répertoire de test jusqu’à la vérification finale. Sa suppression après validation ne touche pas le dépôt Restic ni le fichier actif.