Pourquoi automatiser vos sauvegardes avec Restic
Un VPS héberge souvent des données irremplaçables : bases de données, volumes Docker, fichiers de configuration. Restic répond à trois exigences clés d'une bonne stratégie : le chiffrement (AES-256, le dépôt est inutilisable sans le mot de passe), la déduplication (les blocs identiques ne sont stockés qu'une fois, ce qui réduit drastiquement le volume et le coût), et le support de backends variés (S3, Backblaze B2, SFTP, stockage local). Self-héberger Restic sur le VPS plutôt que de dépendre d'un service de backup managé vous donne le contrôle total du chiffrement : la clé reste chez vous, le fournisseur de stockage ne voit que des blobs opaques. C'est la base d'une stratégie 3-2-1 sérieuse.
Ce que Restic vous apporte
- Chiffrement AES-256 côté client : le backend de stockage ne voit que des données illisibles.
- Déduplication par blocs qui réduit fortement la taille et le coût des sauvegardes successives.
- Snapshots incrémentaux rapides : seuls les nouveaux blocs sont transférés à chaque run.
- Backends multiples (S3, Backblaze B2, SFTP, rest-server, local) sans changer de workflow.
- Restauration granulaire : un fichier, un dossier ou tout un snapshot via
restic restore. - Politique de rétention automatisée avec
forget --prune(garder N quotidiens, M hebdos...).
La règle 3-2-1 : pourquoi un snapshot hébergeur ne suffit pas
Activer les snapshots de votre fournisseur VPS est utile, mais ce n'est pas une stratégie de sauvegarde : c'est une seule copie supplémentaire, chez le même fournisseur, qui partage le sort de votre VM. Trois scénarios le montrent. Si la VM est supprimée (erreur de manipulation, impayé, résiliation), ses snapshots disparaissent souvent avec elle. Si un attaquant prend la main sur votre compte chez l'hébergeur, il efface VM et snapshots en quelques clics ou par l'API. Et un snapshot n'est jamais restauré à titre d'essai : une base de données figée en pleine écriture peut s'avérer inutilisable le jour où vous en avez besoin.
La règle 3-2-1 répond à ces trois risques : trois copies des données, sur deux supports distincts, dont une hors du fournisseur, chiffrée avant de quitter le serveur. Restic construit précisément ce dernier maillon, le seul qui survit à la perte complète du compte hébergeur.
Les trois copies d'une stratégie 3-2-1 sur VPS
- Copie 1, les données vivantes sur le disque du VPS : c'est l'original, et la source des restaurations les plus rapides.
- Copie 2, les snapshots du fournisseur : ils couvrent une mise à jour ratée ou une erreur de configuration, avec un retour en arrière de toute la machine.
- Copie 3, le dépôt Restic chez un autre fournisseur de stockage objet : chiffré côté client, il reste hors d'atteinte du tableau de bord de votre hébergeur.
- Deux supports réellement séparés : le disque du VPS d'un côté, le stockage objet d'un tiers de l'autre, avec des identifiants distincts.
Prérequis pour ce déploiement
Restic est frugal : il fonctionne sur n'importe quel VPS, y compris 1 vCPU et 1 Go de RAM, la déduplication consommant un peu de mémoire proportionnellement à la taille du dépôt. Vous avez besoin du binaire restic, d'un backend de destination distant (un bucket S3-compatible chez un fournisseur, ou un autre serveur en SFTP) et de ses identifiants. Pas de Docker obligatoire ici : Restic est un outil en ligne de commande.
Vérifiez la version que fournit votre distribution : Debian 13 et Ubuntu 26.04 livrent une 0.18, mais Ubuntu 24.04 en est à la 0.16.4 et Debian 12 à la 0.14.0, trop ancienne pour l'option --stdin-from-command utilisée plus bas (apparue en 0.17.0). Dans ce cas, installez le binaire officiel depuis la page des releases (0.19.1, publiée le 5 juillet 2026) : seuls ces binaires officiels embarquent la commande restic self-update, un paquet de distribution se met à jour par apt. Prévoyez enfin un timer systemd (ou cron) pour l'automatisation, et un emplacement sûr hors du VPS pour conserver le mot de passe du dépôt.
Backblaze B2 ou Cloudflare R2 : choisir le backend S3
Faites défiler le tableau
| Critère | Backblaze B2 | Cloudflare R2 |
|---|---|---|
| Stockage offert | Les 10 premiers Go | 10 Go-mois par mois (classe Standard) |
| Sortie de données (egress) | Gratuite jusqu'à 3 fois le volume stocké en moyenne sur le mois, et sans limite vers les CDN partenaires (Cloudflare, Fastly) | Gratuite, sans plafond |
| Endpoint S3 | Propre à la région du compte, par exemple `s3.us-west-004.backblazeb2.com` | `<account-id>.r2.cloudflarestorage.com`, région `auto` |
| Clés d'accès | Application Key dédiée : la clé maîtresse est refusée par l'API S3 | Jeton d'API R2 avec droits de lecture et d'écriture sur les objets |
| Point d'attention | Une restauration complète et fréquente peut dépasser le quota de sortie gratuit | Les tests de restauration réguliers n'ajoutent aucun coût de sortie |
Mettre en place des sauvegardes Restic automatisées
Installer Restic et préparer le fichier d'environnement
Installez
restic(paquet récent ou binaire officiel, voir les prérequis), puis créez/root/.restic-env. Écrivez-le en simples lignesCLÉ=valeur, sansexport: c'est le format que lit la directiveEnvironmentFile=de systemd, et il se charge aussi dans un shell. Pour Restic, B2 s'utilise de préférence par son API compatible S3 :# /root/.restic-env (Backblaze B2, S3 API) RESTIC_REPOSITORY=s3:https://s3.us-west-004.backblazeb2.com/my-bucket RESTIC_PASSWORD=change-me AWS_ACCESS_KEY_ID=b2-key-id AWS_SECRET_ACCESS_KEY=b2-application-key # Cloudflare R2 # RESTIC_REPOSITORY=s3:https://<account-id>.r2.cloudflarestorage.com/my-bucketRestreignez les droits du fichier, puis chargez-le dans votre session :
chmod 600 /root/.restic-env set -a; . /root/.restic-env; set +aInitialiser le dépôt chiffré
restic initCette commande crée la structure du dépôt et scelle le chiffrement avec votre mot de passe ; les dépôts récents (format 2, depuis Restic 0.14.0) compressent aussi les données. Conservez ce mot de passe hors du VPS, dans un gestionnaire de mots de passe ou un coffre sur une autre machine : sans lui, aucune restauration n'est possible, même avec le bucket complet.
Lancer une première sauvegarde
Sauvegardez vos répertoires critiques, puis vos bases de données. Pour un dump, préférez
--stdin-from-commandà un tubepg_dump | restic backup --stdin: Restic ne peut pas savoir si un flux lu sur l'entrée standard est complet, et un dump qui échoue en route produirait un snapshot tronqué sans erreur. Avec--stdin-from-command, un code de sortie non nul de la commande annule la sauvegarde et aucun snapshot n'est créé.restic backup /etc /var/www /opt/docker-data restic backup --stdin-filename mydb.sql --stdin-from-command -- pg_dump -U postgres mydb restic snapshotsDéfinir une politique de rétention
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --pruneSept quotidiennes couvrent une semaine entière, de quoi repérer une corruption qui ne se manifeste qu'au bout de quelques jours. Quatre hebdomadaires ouvrent une fenêtre d'un mois pour un problème applicatif lent, des données qui disparaissent peu à peu. Six mensuelles permettent de revenir à un état d'avant une migration ratée. La passe
--pruneest indispensable :forgetseul retire les snapshots de la liste sans libérer l'espace, et la facture de stockage continue de croître.Vérifier l'intégrité : check, puis read-data
Ces commandes ne contrôlent pas la même chose :
restic check restic check --read-data-subset=10% restic check --read-datarestic checkvalide la structure du dépôt (snapshots, arbres, index, packs) sans lire le contenu des fichiers de données : rapide, il se lance après chaqueforget --prune.--read-datatélécharge et vérifie tous les packs, ce qui prend du temps et consomme de la bande passante sortante. Entre les deux,--read-data-subsetcontrôle une part aléatoire (10%, ou une taille comme5G) ou une tranche fixe (1/5à5/5, pour tout couvrir en cinq passages). Une vérification partielle chaque semaine et complète une fois par mois est un bon compromis.Écrire le script de sauvegarde et son service systemd
Regroupez les gestes dans un script. Il écrit d'abord un fichier sentinelle horodaté, qui servira au test de restauration, et s'arrête à la première erreur grâce à
set -eu:#!/bin/sh # /usr/local/bin/restic-backup.sh set -eu date +%s > /opt/restic-sentinel.txt restic backup /etc /var/www /opt/docker-data /opt/restic-sentinel.txt restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune restic checkLe service le lance avec les variables du fichier d'environnement, sans qu'aucun secret n'apparaisse dans la définition de l'unité :
# /etc/systemd/system/restic-backup.service [Unit] Description=Restic backup After=network-online.target Wants=network-online.target [Service] Type=oneshot EnvironmentFile=/root/.restic-env ExecStart=/usr/local/bin/restic-backup.shPlanifier avec un timer systemd
Le timer déclenche le service chaque nuit.
Persistent=truerattrape un passage manqué si le VPS était éteint à l'heure prévue, etRandomizedDelaySec=900étale le départ sur quinze minutes, utile quand plusieurs serveurs visent le même bucket :# /etc/systemd/system/restic-backup.timer [Unit] Description=Daily restic backup [Timer] OnCalendar=*-*-* 03:00:00 Persistent=true RandomizedDelaySec=900 [Install] WantedBy=timers.targetActivez-le puis vérifiez la prochaine échéance et les journaux du dernier passage :
chmod 700 /usr/local/bin/restic-backup.sh systemctl daemon-reload systemctl enable --now restic-backup.timer systemctl list-timers restic-backup.timer journalctl -u restic-backup.service --since todaySi vous préférez
cron, une ligne0 3 * * *qui charge le fichier d'environnement puis appelle le même script fait l'affaire, sans le rattrapage dePersistent=.Automatiser le test de restauration
Une sauvegarde jamais restaurée reste une hypothèse. Ce second script restaure le seul fichier sentinelle du dernier snapshot et le compare à l'original : si la sauvegarde de la nuit a échoué ou si le dépôt ne rend plus rien,
cmpéchoue et le service passe en étatfailed. Le test vise le snapshot le plus récent : si vous ajoutez des dumps--stdin-from-commandau script de sauvegarde, placez-les avant la sauvegarde des fichiers, qui doit rester la dernière.#!/bin/sh # /usr/local/bin/restic-restore-test.sh set -eu rm -rf /tmp/restic-test-restore restic restore latest --target /tmp/restic-test-restore --include /opt/restic-sentinel.txt cmp /tmp/restic-test-restore/opt/restic-sentinel.txt /opt/restic-sentinel.txtPlanifiez-le chaque semaine, après la sauvegarde de la nuit :
# /etc/systemd/system/restic-restore-test.service [Service] Type=oneshot EnvironmentFile=/root/.restic-env ExecStart=/usr/local/bin/restic-restore-test.sh # /etc/systemd/system/restic-restore-test.timer [Timer] OnCalendar=Sun 05:00:00 Persistent=true [Install] WantedBy=timers.targetActivez le timer avec
systemctl enable --now restic-restore-test.timer, et branchez l'étatfailedde ces deux services sur votre supervision. Une fois par trimestre, restaurez aussi un vrai répertoire, une base de données comprise, sur une machine de test.
Secrets Restic : un fichier isolé, jamais en dur dans l'unité
Ne placez jamais RESTIC_PASSWORD ni les clés S3 dans une ligne Environment= d'une unité systemd, dans un script versionné ou dans un Dockerfile : les variables déclarées dans l'unité sont lisibles par systemctl show. Le fichier /root/.restic-env en chmod 600, chargé par EnvironmentFile=, garde les secrets hors de la définition de l'unité. Pour aller plus loin, la directive LoadCredential= de systemd expose un secret dans un répertoire réservé au service ($CREDENTIALS_DIRECTORY) : Restic lit alors son mot de passe avec RESTIC_PASSWORD_FILE.
Dépannage : les erreurs courantes
restic init ou le premier backup échoue sur le bucket. Vérifiez d'abord que les variables sont chargées (echo $RESTIC_REPOSITORY), puis l'endpoint : sur B2, il doit correspondre à la région de votre compte, et l'endpoint d'AWS (s3.amazonaws.com) est une erreur fréquente. Une Application Key B2 restreinte à un seul bucket doit aussi porter la permission listAllBucketNames pour fonctionner avec les outils S3, et la clé maîtresse du compte ne marche pas avec l'API S3. Sur R2, le jeton doit avoir les droits de lecture et d'écriture sur les objets du bucket.
Le timer ne se déclenche pas. Trois commandes suffisent : systemctl status restic-backup.timer (actif ou non), systemctl list-timers --all | grep restic (prochaine échéance), journalctl -u restic-backup.service --since today (journal du dernier passage). Pour valider une expression OnCalendar, systemd-analyze calendar '*-*-* 03:00:00' doit afficher la prochaine date de déclenchement.
Le dépôt reste verrouillé. Une sauvegarde interrompue (redémarrage, coupure réseau) peut laisser un verrou : restic list locks le montre, restic unlock retire les verrous périmés. Assurez-vous avant qu'aucune autre opération Restic ne tourne.
restic check --read-data trop long. Sur un dépôt de plusieurs dizaines de Go, la lecture complète prend des heures et pèse sur le quota de sortie. Passez à --read-data-subset=10% ou à une tranche 1/4 chaque semaine, et réservez la lecture complète à une maintenance mensuelle.
Plan de reprise : combien de temps pour tout restaurer ?
La durée d'une restauration complète dépend du volume du dépôt, de la bande passante entre le VPS et le bucket, et de la politique de sortie du fournisseur. Sur R2, la sortie est gratuite : rien n'oblige à étaler une restauration. Sur B2, elle est gratuite jusqu'à trois fois le volume stocké en moyenne sur le mois ; au-delà, une restauration complète d'un gros dépôt est facturée.
Ne devinez pas ce temps, mesurez-le. restic stats donne la taille du dépôt ; restaurez ensuite un répertoire significatif (restic restore latest --target /tmp/test --include /etc) et chronométrez l'opération pour extrapoler. Deux pratiques raccourcissent la reprise : sauvegarder uniquement ce qui compte (ni caches, ni journaux, ni /tmp, ni volumes Docker abandonnés), et noter dans votre procédure l'ordre de remise en service, les bases de données d'abord, puis les applications qui en dépendent.
Protégez vos sauvegardes contre le ransomware en activant le mode "append-only" côté backend : déployez rest-server distant avec l'option --append-only, ou utilisez un bucket S3 avec une politique IAM interdisant les suppressions. Ainsi, même si votre VPS est compromis et que l'attaquant obtient les identifiants, il ne pourra ni effacer ni chiffrer vos snapshots existants. Combinez cela avec une exécution de restic forget --prune depuis une machine distincte disposant, elle, des droits de suppression.
