Sauvegardes Restic : sortir les données du VPS

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 instantanés chiffrés et dédupliqués de vos fichiers vers un dépôt situé ailleurs : un second VPS, une machine chez vous, ou du stockage objet compatible S3. Ce guide l'installe sur Ubuntu 24.04, de l'installation à un dépôt via SFTP, une première sauvegarde, un timer systemd nocturne, une politique de rétention, et le test de restauration qui prouve que l'ensemble fonctionne. La destination doit être une autre machine, car une copie qui vit sur le même serveur meurt avec le serveur.

Un répertoire backup/ sur la machine qu'il sauvegarde ne vous protège que d'une seule chose : supprimer un fichier par accident. Il ne survit pas à un disque défaillant, car il était sur ce disque. Il ne survit pas à un attaquant disposant de root, car celui-ci supprime d'abord les copies. Il ne survit pas à l'erreur de compte qui supprime le VPS lui-même. Le datacenter le moins efficace du monde plaisante à propos d'une archive tar nommée backup_final_v2_REAL posée sur la même grappe de disques que les données, et la blague fait mouche parce que tant d'entre nous avons fait exactement cela. Hors de la machine, telle est la règle, et restic est la façon la moins pénible de la suivre.

Restic en quatre idées

Dépôt. L'endroit où restic écrit. C'est un répertoire au format propre à restic, plein de blobs chiffrés, que seul restic peut lire. Vous ne l'éditez jamais à la main ; vous lui parlez via les commandes restic et l'adresse -r.

Instantané. Une image à un instant donné des fichiers que vous avez sauvegardés. Chaque exécution de sauvegarde crée un instantané, chaque instantané peut être restauré seul, et chacun se comporte comme une copie complète de vos données à ce moment-là.

Déduplication. Restic découpe les fichiers en morceaux définis par leur contenu et n'envoie que les morceaux que le dépôt n'a pas encore vus. La première sauvegarde envoie tout ; chaque exécution suivante envoie à peu près ce qui a changé. Un instantané nocturne de 20 Go où 50 Mo ont changé coûte environ 50 Mo, ce qui explique pourquoi conserver des dizaines d'instantanés est bon marché.

Chiffrement par défaut. Un dépôt restic est toujours chiffré (AES-256), et chaque commande a besoin du mot de passe du dépôt. L'hôte de sauvegarde ou le fournisseur de stockage ne voit jamais que des blobs chiffrés. La conséquence est dure : perdez le mot de passe et les données sont perdues, définitivement et par conception. Gardez une copie du mot de passe ailleurs que sur ce serveur. C'est assez important pour être répété deux fois de plus ci-dessous.

Installer restic sur Ubuntu 24.04

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

Sur Ubuntu 24.04, ceci installe restic 0.16.4, alors que la version amont actuelle est la 0.19.1. L'écart existe parce qu'une version LTS (long term support, support à long terme) fige les versions de ses paquets, et cela n'a pas d'importance ici : la 0.16.4 fait tout ce que contient ce guide. Si vous voulez la version la plus récente pour ses gains de vitesse, téléchargez le binaire unique officiel depuis la page des releases GitHub du projet restic, décompressez-le avec bunzip2, et installez-le dans /usr/local/bin/restic ; il n'y a rien d'autre dans une installation de restic.

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

Il vous faut une machine de destination : un second petit VPS est la réponse habituelle, et n'importe quelle machine avec un serveur SSH et de l'espace disque libre convient. Restic parle SFTP (transfert de fichiers via SSH), donc l'hôte de sauvegarde n'a besoin de rien d'installé du tout. Dans ce guide, l'hôte de sauvegarde est 10.0.0.12 avec un utilisateur nommé restic. Ne nommez pas cet utilisateur backup : Ubuntu et Debian fournissent un compte système réservé appelé backup (uid 34, sans shell de connexion) sur chaque installation, donc adduser backup échoue et ssh backup@... aboutit dans nologin.

Le job nocturne s'exécutera en tant que root sur le serveur sauvegardé, donc root a besoin d'une connexion par clé vers l'hôte de sauvegarde. Créez une clé dédiée sans phrase de passe, car aucun humain n'est présent à 3 h du matin pour en taper une, et copiez-la :

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 sont nouvelles pour vous, les bases de la gestion des clés SSH expliquent le modèle, les permissions, et comment révoquer une clé plus tard.

Ensuite, le mot de passe du dépôt. Générez-en un solide dans un fichier accessible uniquement à root :

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

Maintenant, copiez ce mot de passe dans votre gestionnaire de mots de passe, avant d'aller plus loin. Si ce VPS meurt, le dépôt plus ce mot de passe ramènent tout ; le dépôt sans le mot de passe ne ramène rien.

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

La destination alternative est le stockage objet compatible S3, qui est le bon choix quand vous ne voulez pas faire tourner une seconde machine. N'importe quel bucket compatible S3 fonctionne de la même façon ; seuls l'adresse et 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. Le reste de ce guide montre 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 tout le système de fichiers. Le système d'exploitation revient avec une réinstallation ; votre configuration et vos données, non. Pour un VPS typique, cela signifie /etc, /home, et l'endroit où vos applications gardent leur état, comme /srv ou /var/www. Excluez les caches, car ils sont volumineux, ils changent tous les jours, et ils se reconstruisent tout seuls :

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 tout, elle prend donc un moment. Relancez la même commande et elle se termine en quelques secondes, signalant quelques fichiers changés et quelques Mio ajoutés, car la déduplication n'envoie que les nouveaux morceaux. Listez ce que vous avez :

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

Chaque instantané affiche un ID, une heure, et les chemins qu'il contient. Ce sont ces ID qui servent à la restauration.

Exécutions nocturnes avec un timer systemd

Taper l'adresse du dépôt à chaque commande devient lassant, et une sauvegarde que vous lancez à la main cesse d'arriver en moins d'un mois. Les deux problèmes se règlent avec un script et un timer. Le script définit les deux variables d'environnement que restic lit, RESTIC_REPOSITORY et RESTIC_PASSWORD_FILE, pour que chaque commande à l'intérieur reste courte :

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. Maintenant l'horaire : un service oneshot qui exécute le script, et un timer qui le déclenche à 03:00 chaque nuit. Un timer vaut mieux qu'une ligne cron ici parce que l'exécution est journalisée dans le journal, et Persistent=true lance une sauvegarde manquée dès que le serveur est de nouveau en marche après un arrêt.

# /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 lancez le service une fois à la main et regardez-le travailler :

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 indique quand la prochaine exécution se déclenche. Vous pouvez aussi générer la paire de fichiers d'unité au lieu de les taper :

Le schéma complet derrière ces deux fichiers, y compris la syntaxe du calendrier et les directives de durcissement qu'un service peut porter, se trouve dans exécuter un programme comme un service systemd sur un VPS.

Une sauvegarde n'est qu'une rumeur tant que vous ne l'avez pas restaurée

Traitez cette phrase comme un commandement. Un job de sauvegarde qui passe au vert chaque nuit prouve seulement qu'un job s'est exécuté ; il ne prouve pas que vos données reviennent. Deux vérifications comblent l'écart.

D'abord, restic check, que le script exécute déjà chaque nuit. Il vérifie la structure du dépôt et l'index, de sorte qu'une corruption silencieuse sur l'hôte de sauvegarde est détectée dès la nuit suivante plutôt que le jour de la restauration. Une fois par mois, lancez la version plus poussée, 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 aléatoire à chaque fois, les exécutions mensuelles parcourent tout le dépôt sans jamais payer un téléchargement complet.

Ensuite, le test de restauration. Toujours dans le shell root ci-dessus, restaurez un vrai répertoire depuis le dernier instantané vers un emplacement temporaire et comparez-le aux fichiers en production :

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

diff qui n'affiche rien signifie que chaque octet est revenu identique, ce qui est la seule preuve qui compte. Supprimez /srv/restore-drill ensuite. Faites ce test chaque mois, et une ou deux fois par an faites la version complète : restaurez le dernier instantané en entier sur un VPS temporaire et vérifiez que votre application démarre réellement à partir de lui. Le jour où vous aurez besoin que cela marche sous pression, vous voudrez que ce soit une routine que vous avez déjà faite.

Rétention : forget plus prune

Sans politique, les instantanés s'accumulent indéfiniment et le dépôt ne fait que grossir. La ligne forget du script applique une politique chaque nuit : --keep-daily 7 garde un instantané par jour pour 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 pas protégé par une règle est oublié.

forget seul ne retire que les enregistrements d'instantanés ; les morceaux de données restent dans le dépôt jusqu'à ce que quelque chose les supprime. C'est ce que fait --prune : il trouve les morceaux qu'aucun instantané restant ne référence et les supprime, et c'est là que l'espace disque revient réellement. Prune fait un vrai travail sur le dépôt, donc sur un grand dépôt certains lancent forget chaque nuit et --prune chaque semaine ; aux tailles typiques d'un VPS, chaque nuit convient.

Bases de données : dumper d'abord, puis sauvegarder le dump

Restic copie les fichiers au fur et à mesure qu'il les lit, et une base de données écrit dans ses fichiers en continu. Un fichier de base de données capturé en pleine écriture se restaure en base corrompue, car la copie mélange des pages d'avant et d'après une écriture. La solution est standard : faites produire par le moteur de base de données un export cohérent vers un fichier, puis laissez restic sauvegarder ce fichier.

Pour PostgreSQL, ajoutez une ligne de dump en haut de restic-backup.sh, avant la commande restic backup, et incluez le répertoire du dump dans les chemins de sauvegarde :

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

mysqldump remplit le même rôle pour MariaDB et MySQL. Pour un exemple complet de tout le schéma, la section de sauvegarde de Nextcloud active le mode maintenance, dumpe Postgres, et copie les fichiers comme un ensemble cohérent, exactement l'ensemble que restic devrait emporter hors de la machine chaque nuit. SQLite est la même idée avec un plus petit marteau : le guide Vaultwarden arrête le conteneur quelques secondes pour prendre une copie à froid de db.sqlite3, et cette archive est ce que restic expédie 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'y a pas de mode non chiffré, et chaque commande exige le mot de passe du dépôt. La machine ou le fournisseur qui stocke le dépôt ne détient jamais que des blobs chiffrés, donc un hôte de sauvegarde compromis n'expose pas vos fichiers. La contrepartie est absolue : sans le mot de passe, les données ne peuvent être récupérées par personne, alors stockez-en une copie ailleurs que sur le serveur.

Restic fait-il des sauvegardes incrémentales ?

Chaque instantané restic se comporte comme une sauvegarde complète, tout en coûtant un stockage incrémental. Restic découpe les fichiers en morceaux et n'envoie que les morceaux que le dépôt n'a pas déjà stockés, donc une exécution nocturne transfère à peu près ce qui a changé ce jour-là. Contrairement aux schémas incrémentaux traditionnels, il n'y a pas de chaîne à rejouer : n'importe quel instantané se restaure directement et supprimer un ancien instantané ne casse jamais un plus récent.

Comment restaurer des fichiers depuis une sauvegarde restic ?

Lancez restic snapshots pour trouver l'ID de l'instantané, puis restic restore <id> --target /un/dossier/vide pour le restaurer, en ajoutant --include /chemin pour n'en restaurer qu'une partie. latest fonctionne à la place d'un ID. Restic recrée la structure de répertoires d'origine sous la cible, donc restaurer /etc/ssh aboutit dans /un/dossier/vide/etc/ssh. Entraînez-vous avant d'en avoir besoin, car une sauvegarde non testée est une rumeur.

À quelle fréquence faut-il lancer restic backup ?

Chaque nuit est le plancher raisonnable pour un serveur, et la déduplication rend cela bon marché : chaque exécution n'envoie que les morceaux qui ont changé depuis la dernière. Des données qui changent vite, ou dont perdre ne serait-ce qu'une journée ferait mal, peuvent tourner toutes les quelques heures avec le même modèle de timer. La fréquence est la moitié facile ; lancez aussi restic check régulièrement et un test de restauration chaque mois, car un horaire sans vérification est un faux réconfort.

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

Les sauvegardes sont irrécupérables. Le chiffrement de restic n'a ni porte dérobée ni réinitialisation, donc le mot de passe est aussi important que les sauvegardes elles-mêmes. Gardez-en une copie dans votre gestionnaire de mots de passe et partout ailleurs de durable qui n'est pas le serveur sauvegardé. Tant que vous avez encore accès, restic key add peut enregistrer un second mot de passe pour le même dépôt, ce qui vous donne une roue de secours.