Restic : sauvegarder les données de votre VPS ailleurs

Pourquoi une sauvegarde sur le même serveur n’est pas une sauvegarde

Restic est un outil de sauvegarde libre et open source qui envoie des snapshots chiffrés et dédupliqués de vos fichiers vers un repository situé ailleurs : un deuxième VPS, une machine chez vous ou un stockage objet compatible S3. Ce guide explique comment le configurer sur Ubuntu 24.04, de l’installation à l’utilisation d’un repository via SFTP, en passant par une première sauvegarde, un timer systemd quotidien, une politique de rétention et un test de restauration qui vérifie le bon fonctionnement de l’ensemble. La destination doit être une autre machine, car une copie stockée sur le même serveur est perdue avec lui.

Un répertoire backup/ sur la machine qu’il sauvegarde vous protège d’une seule chose : la suppression accidentelle d’un fichier. Il ne résiste pas à une panne du disque, puisqu’il se trouve sur ce disque. Il ne résiste pas à un attaquant disposant de root, car celui-ci supprime d’abord les copies. Il ne résiste pas non plus à une erreur de compte qui supprime le VPS lui-même. Le datacenter le moins efficace au monde se moque d’un tarball nommé backup_final_v2_REAL placé sur le même array que les données, et la plaisanterie fonctionne parce que beaucoup d’entre nous ont déjà fait exactement cela. La règle est de stocker la copie hors de la machine, et restic est le moyen le moins contraignant de la respecter.

Restic en quatre idées

Repository. L’emplacement où restic écrit les sauvegardes. Il s’agit d’un répertoire dans le format propre à restic, rempli de blobs chiffrés que seul restic peut lire. Vous ne le modifiez jamais manuellement ; vous y accédez avec les commandes restic et l’adresse -r.

Snapshot. Une représentation des fichiers sauvegardés à un instant donné. Chaque exécution de la sauvegarde crée un snapshot. Chaque snapshot peut être restauré séparément et se comporte comme une copie complète de vos données à cet instant.

Déduplication. Restic découpe les fichiers en chunks définis par leur contenu et envoie uniquement ceux que le repository ne contient pas encore. La première sauvegarde envoie tout. Les suivantes envoient environ le volume des modifications. Un snapshot nocturne de 20 GB dans lequel 50 MB ont changé coûte environ 50 MB. C’est pourquoi il est peu coûteux de conserver des dizaines de snapshots.

Chiffrement par défaut. Un repository restic est toujours chiffré (AES-256) et chaque commande nécessite le mot de passe du repository. L’hôte de sauvegarde ou le fournisseur de stockage ne voit jamais que des blobs chiffrés. La conséquence est importante : si vous perdez le mot de passe, les données sont définitivement perdues, conformément à la conception du système. Conservez une copie du mot de passe ailleurs que sur ce serveur. C’est suffisamment important pour que nous y revenions encore deux fois ci-dessous.

Installer restic sur Ubuntu 24.04

sudo apt update && sudo apt install -y restic
restic version

Sur Ubuntu 24.04, cette commande installe restic 0.16.4, alors que la version actuellement publiée par le projet est 0.19.1. Cet écart s’explique par le fait qu’une version LTS (support à long terme) fige les versions de ses paquets. Il n’a pas d’importance ici : 0.16.4 fournit toutes les fonctions nécessaires à ce guide. Si vous voulez la version la plus récente pour bénéficier de ses améliorations de vitesse, téléchargez le binaire unique officiel depuis la page des releases du projet restic sur GitHub, décompressez-le avec bunzip2, puis installez-le dans /usr/local/bin/restic. L’installation de restic ne nécessite aucune autre étape.

Créer le dépôt sur un autre serveur via SFTP

Vous avez besoin d’une machine de destination : un second petit VPS est généralement le plus simple, mais n’importe quelle machine disposant d’un serveur SSH et d’espace disque disponible convient. Restic utilise SFTP (transfert de fichiers via SSH), donc l’hôte de sauvegarde n’a besoin d’aucun logiciel supplémentaire. Dans ce guide, l’hôte de sauvegarde est 10.0.0.12 et utilise un utilisateur nommé restic. Ne nommez pas cet utilisateur backup : Ubuntu et Debian installent sur chaque système un compte système réservé nommé backup (uid 34, sans shell de connexion). Par conséquent, adduser backup échoue et ssh backup@... arrive dans nologin.

La tâche nocturne s’exécutera avec les droits de root sur le serveur sauvegardé. Le compte root doit donc pouvoir se connecter à l’hôte de sauvegarde avec une clé. Créez une clé dédiée sans phrase secrète, car personne ne sera présent à 3 heures du matin pour la saisir, puis copiez-la sur l’hôte :

sudo ssh-keygen -t ed25519 -f /root/.ssh/id_ed25519 -N "" -C "web1-restic"
sudo ssh-copy-id -i /root/.ssh/id_ed25519.pub restic@10.0.0.12
sudo ssh restic@10.0.0.12 true && echo key login works

Si les clés vous sont peu familières, Principes de base de la gestion des clés SSH explique leur fonctionnement, les permissions à appliquer et la manière de révoquer une clé ultérieurement.

Passez ensuite au mot de passe du dépôt. Générez un mot de passe robuste dans un fichier accessible uniquement par root :

openssl rand -base64 32 | sudo tee /root/.restic-password
sudo chmod 600 /root/.restic-password

Copiez maintenant ce mot de passe dans votre gestionnaire de mots de passe, avant d’aller plus loin. Si ce VPS tombe en panne, le dépôt et ce mot de passe permettent de tout restaurer ; le dépôt sans le mot de passe ne permet de rien restaurer.

Initialisez le dépôt :

sudo restic -r sftp:restic@10.0.0.12:/srv/restic/web1 --password-file /root/.restic-password init

created restic repository 9f3c2a1b0d at sftp:restic@10.0.0.12:/srv/restic/web1

L’autre destination possible est un stockage objet compatible S3. C’est le bon choix si vous ne souhaitez pas gérer une seconde machine. N’importe quel bucket compatible S3 fonctionne de la même manière ; seuls l’adresse et les deux variables d’identifiants changent :

export AWS_ACCESS_KEY_ID=your-key-id
export AWS_SECRET_ACCESS_KEY=your-secret-key
sudo -E restic -r s3:https://s3.example.com/web1-backups --password-file /root/.restic-password init

Tout ce qui suit init est identique pour les deux destinations. La suite de ce guide utilise l’adresse SFTP ; remplacez-la par la vôtre.

La première sauvegarde, avec des exclusions

Sauvegardez les données que vous ne pouvez pas réinstaller, pas l’ensemble du système de fichiers. Le système d’exploitation revient après une réinstallation ; votre configuration et vos données, non. Pour un VPS classique, cela signifie /etc, /home et les emplacements où vos applications stockent leur état, par exemple /srv ou /var/www. Excluez les caches, car ils sont volumineux, changent tous les jours et se recréent automatiquement :

sudo restic -r sftp:restic@10.0.0.12:/srv/restic/web1 --password-file /root/.restic-password backup /etc /home /srv --exclude '/home/*/.cache'

Files:        4181 new,     0 changed,     0 unmodified
Added to the repository: 731.204 MiB (312.418 MiB stored)
snapshot 5b8a3f2c saved

La première exécution envoie toutes les données, ce qui prend un certain temps. Exécutez à nouveau la même commande : elle se termine en quelques secondes et signale quelques fichiers modifiés ainsi que quelques MiB ajoutés, car la déduplication n’envoie que les nouveaux blocs. Affichez ce dont vous disposez :

sudo restic -r sftp:restic@10.0.0.12:/srv/restic/web1 --password-file /root/.restic-password snapshots

Chaque snapshot affiche un ID, une date et une heure, ainsi que les chemins qu’il contient. Ce sont ces ID qui servent à restaurer les données.

Exécutions nocturnes avec un timer systemd

Saisir l’adresse du dépôt dans chaque commande devient vite fastidieux, et une sauvegarde lancée manuellement cesse généralement d’être effectuée au bout d’un mois. Un seul script et un seul timer règlent ces deux problèmes. Le script définit les deux variables d’environnement lues par restic, RESTIC_REPOSITORY et RESTIC_PASSWORD_FILE. Toutes les commandes qu’il contient restent ainsi courtes :

sudo nano /usr/local/bin/restic-backup.sh

#!/usr/bin/env bash
set -euo pipefail
export RESTIC_REPOSITORY='sftp:restic@10.0.0.12:/srv/restic/web1'
export RESTIC_PASSWORD_FILE=/root/.restic-password

restic backup /etc /home /srv --exclude '/home/*/.cache'
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
restic check

sudo chmod 700 /usr/local/bin/restic-backup.sh

Les lignes forget et check sont expliquées dans les deux sections suivantes. Configurez maintenant la planification : un service oneshot qui exécute le script, et un timer qui le lance à 03:00 chaque nuit. Ici, un timer est préférable à une ligne cron, car l’exécution est journalisée dans le journal systemd et Persistent=true lance une sauvegarde manquée dès que le serveur est de nouveau disponible après une interruption.

# /etc/systemd/system/restic-backup.service
[Unit]
Description=Nightly restic backup
Wants=network-online.target
After=network-online.target

[Service]
Type=oneshot
ExecStart=/usr/local/bin/restic-backup.sh

# /etc/systemd/system/restic-backup.timer
[Unit]
Description=Run the nightly restic backup

[Timer]
OnCalendar=*-*-* 03:00:00
RandomizedDelaySec=15m
Persistent=true

[Install]
WantedBy=timers.target

Activez le timer, puis exécutez le service une fois manuellement et surveillez son exécution :

sudo systemctl daemon-reload
sudo systemctl enable --now restic-backup.timer
sudo systemctl start restic-backup.service
sudo journalctl -u restic-backup.service -f

systemctl list-timers affiche l’heure de la prochaine exécution. Vous pouvez aussi générer les deux fichiers d’unité au lieu de les saisir :

Le fonctionnement complet de ces deux fichiers, notamment la syntaxe des calendriers et les directives de hardening qu’un service peut utiliser, est décrit dans exécuter un programme comme service systemd sur un VPS.

Une sauvegarde n’est pas fiable tant que vous ne l’avez pas restaurée

Considérez cette phrase comme un commandement. Une tâche de sauvegarde qui se termine correctement chaque nuit prouve seulement qu’une tâche a été exécutée ; elle ne prouve pas que vos données peuvent être récupérées. Deux contrôles permettent de combler cet écart.

D’abord, restic check, que le script exécute déjà chaque nuit. Cette commande vérifie la structure du dépôt et l’index. Elle détecte ainsi une corruption silencieuse sur le serveur de sauvegarde dès la nuit suivante, au lieu d’attendre le jour de la restauration. Une fois par mois, exécutez la version approfondie, qui télécharge et vérifie cryptographiquement un dixième aléatoire des données réelles :

sudo -i
export RESTIC_REPOSITORY='sftp:restic@10.0.0.12:/srv/restic/web1'
export RESTIC_PASSWORD_FILE=/root/.restic-password
restic check --read-data-subset=10%

Comme le sous-ensemble est choisi aléatoirement à chaque exécution, les contrôles mensuels parcourent progressivement tout le dépôt sans nécessiter un téléchargement complet.

Ensuite, effectuez un test de restauration. Toujours dans le shell root utilisé précédemment, restaurez un répertoire réel depuis le dernier snapshot vers un emplacement de test, puis comparez-le aux fichiers actifs :

restic restore latest --target /srv/restore-drill --include /etc/ssh
diff -r /etc/ssh /srv/restore-drill/etc/ssh

diff n’affichant rien signifie que chaque octet a été restauré à l’identique. C’est la seule preuve qui compte. Supprimez /srv/restore-drill ensuite. Effectuez ce test tous les mois. Une ou deux fois par an, exécutez la version complète : restaurez l’intégralité du dernier snapshot sur un VPS de test et vérifiez que votre application démarre réellement à partir de celui-ci. Le jour où cette procédure devra fonctionner sous pression, vous voudrez pouvoir vous appuyer sur une routine que vous aurez déjà exécutée.

Rétention : forget et prune

Sans politique de rétention, les snapshots s’accumulent indéfiniment et le repository continue de grossir. La ligne forget du script applique une politique chaque nuit : --keep-daily 7 conserve un snapshot par jour pendant les sept derniers jours, --keep-weekly 4 un par semaine pendant quatre semaines et --keep-monthly 6 un par mois pendant six mois. Tout ce qui n’est protégé par aucune règle est oublié.

forget supprime uniquement les enregistrements des snapshots ; les blocs de données restent dans le repository jusqu’à ce qu’une commande les supprime. C’est le rôle de --prune : cette commande recherche les blocs qui ne sont plus référencés par aucun snapshot et les supprime. C’est à ce moment que l’espace disque est effectivement libéré. Prune effectue un véritable travail sur le repository. Sur un repository volumineux, certains administrateurs exécutent donc forget chaque nuit et --prune chaque semaine. Pour les tailles habituelles d’un VPS, une exécution quotidienne convient.

Bases de données : créez d’abord un dump, puis sauvegardez-le

Restic copie les fichiers au fur et à mesure de leur lecture, tandis qu’une base de données écrit en continu dans ses fichiers. Un fichier de base de données capturé pendant une écriture sera restauré comme une base corrompue, car la copie mélange des pages antérieures et postérieures à l’écriture. La solution est standard : demandez au moteur de base de données de produire un export cohérent dans un fichier, puis laissez restic sauvegarder ce fichier.

Pour PostgreSQL, ajoutez une ligne de dump au début de restic-backup.sh, avant la commande restic backup, et incluez le répertoire du dump dans les chemins sauvegardés :

mkdir -p /var/backups/db
sudo -u postgres pg_dump myapp | gzip > /var/backups/db/myapp.sql.gz

mysqldump joue le même rôle pour MariaDB et MySQL. Pour voir un exemple complet de cette méthode, la section sur la sauvegarde de Nextcloud active le mode maintenance, crée un dump de Postgres et copie les fichiers en un seul ensemble cohérent, c’est-à-dire exactement l’ensemble que restic doit transférer hors du serveur chaque nuit. SQLite repose sur le même principe, avec une méthode plus simple : le guide Vaultwarden arrête le conteneur pendant quelques secondes pour effectuer une copie à froid de db.sqlite3, puis restic transfère cette archive hors du serveur.

FAQ

Les sauvegardes restic sont-elles chiffrées ?

Oui, toujours. Chaque dépôt restic est chiffré avec AES-256. Il n’existe pas de mode non chiffré et chaque commande nécessite le mot de passe du dépôt. La machine ou le fournisseur qui stocke le dépôt ne contient que des blobs chiffrés. Un serveur de sauvegarde compromis n’expose donc pas vos fichiers. La contrepartie est stricte : sans le mot de passe, personne ne peut récupérer les données. Conservez donc une copie en dehors du serveur.

Restic effectue-t-il des sauvegardes incrémentielles ?

Chaque snapshot restic se comporte comme une sauvegarde complète, tout en utilisant un espace de stockage incrémentiel. Restic découpe les fichiers en chunks et envoie uniquement ceux qui ne sont pas encore présents dans le dépôt. Une exécution nocturne transfère donc environ les données modifiées pendant la journée. Contrairement aux schémas incrémentiels traditionnels, il n’existe aucune chaîne à rejouer : chaque snapshot se restaure directement et la suppression d’un ancien snapshot ne casse jamais un snapshot plus récent.

Comment restaurer des fichiers depuis une sauvegarde restic ?

Exécutez restic snapshots pour trouver l’ID du snapshot, puis restic restore <id> --target /some/empty/dir pour le restaurer. Ajoutez --include /path pour n’en restaurer qu’une partie. latest peut être utilisé à la place d’un ID. Restic recrée la structure de répertoires d’origine sous la cible. La restauration de /etc/ssh aboutit donc à /some/empty/dir/etc/ssh. Testez cette procédure avant d’en avoir besoin : une sauvegarde non testée reste une simple supposition.

À quelle fréquence dois-je exécuter restic backup ?

Une exécution nocturne constitue le minimum raisonnable pour un serveur. La déduplication en limite le coût : chaque exécution envoie uniquement les chunks modifiés depuis la précédente. Les données qui changent rapidement, ou dont la perte d’une seule journée serait problématique, peuvent être sauvegardées toutes les quelques heures avec le même principe de timer. La fréquence n’est que la première moitié du problème. Exécutez également restic check régulièrement et effectuez un exercice de restauration chaque mois. Une planification sans vérification procure un faux sentiment de sécurité.

Que se passe-t-il si je perds le mot de passe de mon dépôt restic ?

Les sauvegardes deviennent irrécupérables. Le chiffrement de restic ne possède ni backdoor ni procédure de réinitialisation. Le mot de passe est donc aussi important que les sauvegardes elles-mêmes. Conservez-en une copie dans votre gestionnaire de mots de passe et dans un autre emplacement durable qui ne soit pas le serveur sauvegardé. Tant que vous y avez encore accès, restic key add peut enregistrer un second mot de passe pour le même dépôt. Vous disposez ainsi d’un mot de passe de secours.