Sauvegardes avec restic

Module 8: Sauvegardes et surveillance · Temps de lecture : 12 minutes

Objectif pédagogique : À l'issue de cette leçon, vous savez créer avec restic des sauvegardes chiffrées vers un stockage situé hors de votre serveur, supprimer les anciennes versions selon une politique de rétention, vérifier la sauvegarde et restaurer des fichiers, et faire tourner l'ensemble automatiquement.

Notions clés : restic, dépôt (repository), init, mot de passe (fichier), backend (sftp, S3, rest-server), backup, snapshots, forget, --keep-daily/--keep-weekly/--keep-monthly, prune, check, restore, mount, déduplication, append-only, timer systemd

Pourquoi restic ?

Il existe de nombreux programmes de sauvegarde. restic est un bon choix pour votre propre serveur, car il :

• chiffre tout avant que les données ne quittent le serveur ; le stockage ne voit que des blocs illisibles ;
• déduplique : un fichier qui n'a pas changé n'est pas stocké à nouveau, si bien que des sauvegardes quotidiennes occupent peu d'espace ;
• prend en charge de nombreux types de stockage : un dossier, un autre serveur via SFTP, un stockage compatible S3, votre propre rest-server ;
• est un programme unique, disponible dans les dépôts de paquets de Debian et Ubuntu (apt install restic).

BorgBackup est une alternative aux caractéristiques comparables. Les principes de cette leçon s'y appliquent également.

Les notions

• Dépôt (repository) : l'endroit où restic stocke les sauvegardes. Toujours en dehors du serveur que vous sauvegardez.
• Snapshot : une sauvegarde à un moment donné. (Attention : ce n'est pas la même chose que le snapshot de votre fournisseur vu à la leçon 8.1.)
• Mot de passe : chaque dépôt possède un mot de passe qui sert à tout chiffrer. La documentation de restic est claire à ce sujet : si vous perdez le mot de passe, vous perdez les données de façon irrémédiable.

Créer un dépôt

Supposons que vous disposiez d'un serveur de stockage backup.example.net auquel vous accédez via SFTP avec une clé, en tant qu'utilisateur web1. Créez d'abord un fichier de mot de passe sur le serveur (et conservez le même mot de passe dans votre gestionnaire de mots de passe, leçon 8.1) :

root@web1:~# install -m 600 /dev/null /root/.restic-wachtwoord
root@web1:~# openssl rand -base64 32 > /root/.restic-wachtwoord
root@web1:~# export RESTIC_REPOSITORY=sftp:web1@backup.example.net:/srv/restic/web1
root@web1:~# export RESTIC_PASSWORD_FILE=/root/.restic-wachtwoord
root@web1:~# restic init
created restic repository 5f1a9c2e3b at sftp:web1@backup.example.net:/srv/restic/web1

Please note that knowledge of your password is required to access
the repository. Losing your password means that your data is
irrecoverably lost.

Grâce aux variables d'environnement RESTIC_REPOSITORY et RESTIC_PASSWORD_FILE, vous n'avez pas besoin de saisir les options -r et --password-file à chaque fois.

Créer une sauvegarde

D'abord le dump de la base de données (leçon 8.1), puis la sauvegarde :

root@web1:~# restic backup /etc /var/www /opt /var/backups/db \
    --exclude /var/www/*/cache --tag dagelijks
repository 5f1a9c2e opened (version 2, compression level auto)
...
Files:        8421 new,     0 changed,     0 unmodified
Dirs:         1203 new,     0 changed,     0 unmodified
Added to the repository: 612.338 MiB (402.117 MiB stored)

processed 8421 files, 1.204 GiB in 0:41
snapshot 3c7e91d4 saved

Le lendemain, c'est beaucoup plus rapide : seul ce qui a changé est envoyé.

root@web1:~# restic snapshots
ID        Time                 Host  Tags       Paths
-----------------------------------------------------------------------
3c7e91d4  2026-11-08 03:10:02  web1  dagelijks  /etc /opt /var/backups/db /var/www
a18f0b77  2026-11-09 03:10:05  web1  dagelijks  /etc /opt /var/backups/db /var/www
-----------------------------------------------------------------------
2 snapshots

Faire le ménage : forget et prune

Un snapshot de plus chaque jour, cela fait 365 snapshots au bout d'un an. Avec forget, vous décidez lesquels vous conservez, au moyen d'une politique de rétention :

root@web1:~# restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

Voici comment fonctionne cette politique :

• --keep-daily 7 : examine les sept derniers jours comportant un snapshot et conserve le plus récent de chaque jour ;
• --keep-weekly 4 : idem pour les quatre dernières semaines (du lundi au dimanche) ;
• --keep-monthly 6 : idem pour les six derniers mois.

Un snapshot est conservé s'il répond à au moins une des règles. Tout ce qui ne répond à aucune règle est oublié. Testez d'abord une nouvelle politique avec --dry-run : vous voyez ainsi ce qui serait supprimé, sans que rien ne change.

Différence importante : forget supprime uniquement la référence à un snapshot. Les données restent dans le dépôt jusqu'à ce que prune supprime les blocs qui ne sont plus utilisés par aucun snapshot. L'option --prune de forget fait les deux en une seule fois. Prune prend du temps et verrouille le dépôt ; ne le planifiez donc pas en même temps que votre sauvegarde.

Vérifier : check

Une sauvegarde qui s'endommage silencieusement, vous ne le remarquez qu'au moment de la restauration. Faites vérifier le dépôt régulièrement par restic :

root@web1:~# restic check
...
no errors were found
root@web1:~# restic check --read-data-subset=5%

Un simple check vérifie la structure. Avec --read-data-subset, il relit aussi réellement une partie des données et en vérifie le contenu. Faites-le par exemple chaque semaine sur quelques pour cent ; ainsi, au bout d'un certain temps, tout aura été lu au moins une fois.

Restaurer : restore et mount

Restaurez vers un dossier distinct, jamais directement par-dessus l'original :

root@web1:~# restic restore latest --target /tmp/terug --include /etc/nginx
restoring snapshot a18f0b77 of [/etc /opt /var/backups/db /var/www] at 2026-11-09 03:10:05 ...
Summary: Restored 41 files/dirs (88.104 KiB) in 0:00
root@web1:~# diff -r /tmp/terug/etc/nginx /etc/nginx && echo gelijk
gelijk

latest désigne le snapshot le plus récent ; vous pouvez aussi utiliser un ID (restic restore 3c7e91d4 ...). Avec restic mount /mnt/restic (nécessite FUSE), vous voyez tous les snapshots sous forme de dossiers, vous pouvez les parcourir et copier des fichiers individuels. Pour arrêter : Ctrl+C.

Pour restaurer une base de données, vous récupérez le dump puis vous l'importez, par exemple gunzip < alles.sql.gz | mariadb.

Automatiquement, chaque nuit

Créez un script et un timer systemd (leçon 6.3). Le script :

#!/bin/sh
# /usr/local/sbin/backup.sh
set -eu
export RESTIC_REPOSITORY=sftp:web1@backup.example.net:/srv/restic/web1
export RESTIC_PASSWORD_FILE=/root/.restic-wachtwoord
mariadb-dump --single-transaction --all-databases | gzip > /var/backups/db/alles.sql.gz
restic backup /etc /var/www /opt /var/backups/db --tag dagelijks
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

Un .service avec Type=oneshot et ExecStart=/usr/local/sbin/backup.sh, et un .timer avec OnCalendar=*-*-* 03:10:00 et Persistent=true. set -eu fait en sorte que le script s'arrête à la première erreur, afin que systemd considère l'exécution comme échouée. Associez-y une notification (leçon 8.3), sinon vous ne remarquerez pas une sauvegarde échouée.

Contre les ransomwares : append-only

Dans le script ci-dessus, le serveur peut lui-même effacer la sauvegarde (forget et prune). Si un attaquant prend le contrôle du serveur, il le peut donc aussi. Deux façons de l'éviter :

• rest-server en mode append-only : sur le serveur de stockage, vous faites tourner le rest-server propre à restic avec l'option --append-only. Le serveur web peut alors ajouter des sauvegardes, mais rien effacer. Le ménage (forget --prune) se fait depuis une autre machine bien sécurisée, disposant de tous les droits.
• Stockage avec gestion des versions ou verrouillage d'objets chez un fournisseur S3, de sorte que les objets supprimés restent récupérables pendant un certain temps.

Attention à un piège subtil que la documentation de restic mentionne elle-même : un attaquant qui ajoute de faux snapshots peut amener une politique comme --keep-weekly à oublier de vrais snapshots. Avec --keep-within (par exemple --keep-within 30d), tout ce qui date de cette période est conservé, faux ou vrai.

Résumé

• restic chiffre, déduplique et peut sauvegarder vers de nombreux types de stockage hors de votre serveur ; perdre le mot de passe, c'est tout perdre.
• init crée le dépôt, backup un snapshot, snapshots les affiche.
• forget avec --keep-* détermine ce que vous conservez ; seul prune (ou --prune) supprime réellement les données. Testez avec --dry-run.
• check (avec --read-data-subset) vérifie, restore --target restaure vers un dossier distinct, mount vous permet de parcourir les sauvegardes.
• Automatisez avec un timer et une notification, et gardez au moins un dépôt hors de portée du serveur (append-only).

Quiz

Exercice

Exercice Z8.2 : Que reste-t-il après forget ? Le fichier d'exemple restic-snapshots.txt contient une liste de snapshots et une politique de rétention. Déterminez quels snapshots subsistent après restic forget avec cette politique. Le programme compare votre réponse à la clé fixe.

Exercice O8.2 : Un test de restauration. Sur votre propre serveur, créez un dépôt restic hors du serveur, sauvegardez /etc et vos données, puis restaurez un dossier vers /tmp/terug. Comparez avec diff, notez combien de temps cela a pris, et indiquez où votre mot de passe et vos identifiants de stockage sont conservés hors du serveur.

Pour aller plus loin

• Stratégie de sauvegarde : la règle du 3-2-1 pour votre propre entreprise
• Documentation de restic, Preparing a new repository : https://restic.readthedocs.io/en/stable/030_preparing_a_new_repo.html
• Documentation de restic, Removing backup snapshots (forget et prune) : https://restic.readthedocs.io/en/stable/060_forget.html
• Documentation de restic, Restoring from backup : https://restic.readthedocs.io/en/stable/050_restore.html
• rest-server (append-only) : https://github.com/restic/rest-server