Un backup sans test de restore, c'est de la décoration

Une phrase, écrite en passant dans un commentaire, résume tout ce que j’ai à dire sur le sujet :

Ne pas oublier qu’une politique de backup sans test de restore régulier, c’est juste de la décoration : tu ne sais pas si ton backup marche tant que tu ne l’as pas restauré.

Le reste de cet article n’est que le déploiement de cette phrase.

Le seul test qui compte

Un backup qui n’a jamais été restauré n’est pas un backup, c’est une hypothèse. Le jour où vous en avez besoin est exactement le jour où vous ne pouvez pas vous permettre de découvrir que :

le dépôt est corrompu depuis six mois,
la passphrase de chiffrement vit dans la tête d’un ancien employé,
le script tourne depuis deux ans en échec silencieux parce que la destination a été renommée,
le restore prend quinze heures quand votre SLA en demande deux (j’ai vécu l’inverse dans ce post-mortem PowerDNS ).

Le test de restore a donc une cadence, pas une date au calendrier : à chaque changement majeur (nouvel outil, nouvelle destination, nouvelle rétention) et périodiquement sur l’existant. Et il teste le scénario complet : restore intégral sur une machine vierge, chronométré, avec vérification d’intégrité des données restaurées. Restaurer “juste un fichier” pour se rassurer, c’est tester le fil à coudre du parachute.

Git est déjà un backup (et un remote n’est qu’une URL)

Bon réflexe le mirroring : git est distribué par design, donc ton clone local est déjà un backup complet avec tout l’historique.

Et un remote, c’est juste une URL. Rien n’empêche d’en avoir plusieurs par repo :

git remote set-url --add origin git@forgejo.local:user/repo.git

Un git push part sur toutes les destinations d’un coup. Tu peux même configurer ça par branche ou par remote nommé : origin vers GitHub, backup vers ton Forgejo , archive vers un GitLab/Gitea/Gitolite self-hosté.

Côté automatisation, les hooks (pre-push, post-commit) permettent de déclencher ce que tu veux sans dépendre d’un service tiers : un post-push qui pousse vers un second remote ou qui déclenche un rsync, c’est trois lignes de shell.

Cette simplicité est la raison pour laquelle je réponds souvent “tu n’as même pas besoin d’un Forgejo pour avoir une stratégie solide”. Le mirroring git couvre le code source ; le reste du système demande mieux et c’est la suite.

Le reste du système : Restic, Borg, rsnapshot

Pour tout ce qui n’est pas un dépôt git, deux familles d’outils ont fait leurs preuves et j’en recommande une systématiquement :

Restic (souvent couplé à rclone pour les destinations cloud, le combo que j’utilise) : chiffrement natif, déduplication, snapshots, destinations multiples.
Borg (et son écosystème, y compris les snapshots associés) : la référence historique, déduplication agressive, compression.
Plakar (FR, à suivre) et pour l’ancien monde rsnapshot, qui reste honnêtement pas mal par rapport à un script rsync maison : rotations et hardlinks gérés proprement là où le script maison les simule.

Le point commun de tous : rétention définie, chiffrement et une commande restore qui a été exécutée au moins une fois. Si votre outil ne coche pas ces trois cases, le problème n’est pas l’outil, c’est la politique.

Les snapshots ne sont pas des backups

Précision de vocabulaire qui évite des drames : un snapshot Btrfs ou ZFS n’est pas un backup. Il vit sur le même stockage, la même machine, le même pool. Une panne disque, une surtension, un ransomware avec les droits d’écriture : le snapshot et les données partent ensemble.

Ce que les FS avec snapshots apportent quand même et c’est précieux : des datasets et des snapshots quasi instantanés, qui permettent de revenir en arrière sur une erreur logique (un rm -rf mal cadré, une migration ratée) sans restaurer toute la chaîne. C’est un filet de sécurité au niveau de l’instant, pas au niveau du site.

Donc : Btrfs ou ZFS pour les snapshots et les datasets sur le stockage primaire, Restic ou Borg pour la copie sur un autre support, avec rétention et chiffrement. Les deux couches ne remplacent rien l’une l’autre.

L’OS stable comme composante de la politique

Un détail qui n’est pas secondaire : la machine qui effectue les backups et celle qui les héberge doivent être ennuyeuses. Un bon Debian Stable ou une Ubuntu LTS, rien de plus récent, rien d’exotique. La réplication de votre politique de backup ne doit jamais dépendre d’une version fraîchement mise à jour.

Un système de fichiers qui se snapshot, un bon système de sauvegarde, un système d’exploitation stable pour le taf : les trois composantes, dans cet ordre de banalité.

Résumé

Une politique de backup sans test de restore régulier est de la décoration. Le test est intégral, chronométré, sur machine vierge et a une cadence.
Git est distribué : ton clone local est un backup complet, un remote n’est qu’une URL et git remote set-url --add donne le mirroring en une ligne. Les hooks automatisent sans service tiers.
Restic (+rclone) ou Borg pour le reste : chiffrement, déduplication, rétention. Rsnapshot au-dessus d’un script rsync maison.
Un snapshot Btrfs/ZFS n’est pas un backup : même stockage, même panne. C’est le retour arrière instantané, pas la copie distante.
L’OS qui backup est stable et ennuyeux : Debian Stable ou Ubuntu LTS.

[edit: 2026] L’implémentation Ansible de tout ceci: le rôle plakar .