Je vais être honnête : jusqu'à il y a quelques jours, mon "plan de sauvegarde" tenait en une phrase - "si hawking crache, je pleure et je recommence".

hawking, c'est mon serveur chez OVH. Il fait tourner ce blog, mon VPN, une bonne trentaine de conteneurs Docker (Wazuh, Sygnet, DBFactory, du monitoring, et j'en passe), plusieurs bases Postgres et MariaDB, et les clés WireGuard qui me permettent de rejoindre mon réseau maison depuis n'importe où. Si ce serveur meurt un jour - disque mort, erreur de manip, ou simplement OVH qui a un mauvais jour - je perds tout ça d'un coup. Pareil pour mes deux Raspberry Pi à la maison, qui font tourner Home Assistant, du monitoring, et bientôt un petit cluster k3s.

Trois machines, zéro sauvegarde propre. Il était temps.

Le cahier des charges

Je voulais un truc simple à tenir dans la durée, pas une usine à gaz que j'abandonnerais au bout de trois semaines :

  • Chiffré de bout en bout - une sauvegarde qui traîne sur un disque USB ou dans le cloud sans chiffrement, c'est une fuite de données qui s'ignore.
  • Deux destinations - un disque USB branché sur un Raspberry Pi à la maison, et une copie chez pCloud pour le jour où la maison brûle (au sens propre).
  • Pas de double emploi - avec plusieurs machines qui sauvegardent tous les jours, je ne voulais pas voir mon disque se remplir en quelques semaines.
  • Automatique - une sauvegarde qu'on lance à la main, c'est une sauvegarde qu'on oublie de lancer.

L'outil : restic

J'ai regardé du côté de BorgBackup, qui est excellent aussi, mais j'ai fini par choisir restic. Trois raisons :

  1. Chiffrement systématique, dès le premier snapshot, sans option à activer.
  2. Déduplication par blocs : il découpe les fichiers en morceaux et ne stocke qu'une fois un bloc identique. Concrètement, mes trois machines peuvent sauvegarder la même config Docker de base tous les jours sans que ça pèse trois fois sur le disque.
  3. Il parle nativement SFTP et rclone - donc SSH vers un autre serveur, ou n'importe quel cloud pris en charge par rclone (pCloud, S3, Google Drive...), sans changer d'outil selon la destination.

Un seul binaire, pas de serveur à faire tourner, disponible en paquet Debian standard :

sudo apt-get install restic

L'architecture

Le disque USB est branché sur rasp001, un des deux Raspberry Pi à la maison. 4,6 To, largement de quoi voir venir.

hawking (OVH)  ----SFTP---->  rasp001:/mnt/usbdata/backups/restic-repos/hawking
rasp002        ----SFTP---->  rasp001:/mnt/usbdata/backups/restic-repos/rasp002
rasp001        --(local)-->   /mnt/usbdata/backups/restic-repos/rasp001

rasp001  ----rclone---->  pCloud (copie hors site)

Chaque machine a son propre dépôt restic. rasp001 est la seule à parler à pCloud - inutile de configurer rclone partout, autant centraliser.

Les bases de données : jamais de copie à chaud

Un piège classique : copier bêtement les fichiers d'une base Postgres ou MariaDB pendant qu'elle tourne. Le résultat est souvent inutilisable au moment de restaurer. La bonne pratique, c'est un vrai dump avant chaque sauvegarde :

docker exec ghost_mariadb sh -c 'mariadb-dump -uroot -p"$MYSQL_ROOT_PASSWORD" --single-transaction --routines "$MYSQL_DATABASE"' | gzip > /var/backups/ghost-db.sql.gz

restic sauvegarde ensuite ce fichier .sql.gz, qui se restaure sans surprise même des mois plus tard.

Le lancement, tous les jours, sans y penser

Un timer systemd sur chaque machine, pas d'Ansible ni de Semaphore pour ça - une sauvegarde quotidienne n'a pas besoin d'un chef d'orchestre, juste d'un cron qui tourne sur une machine allumée en permanence.

restic -r sftp:hermes-exec@rasp001:/mnt/usbdata/backups/restic-repos/hawking backup /etc /opt/stranix-git /var/lib/hermes
restic -r sftp:hermes-exec@rasp001:/mnt/usbdata/backups/restic-repos/hawking forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

La politique de rétention (forget) est ce qui évite que le disque se remplisse à l'infini : 7 sauvegardes quotidiennes, 4 hebdomadaires, 6 mensuelles. Au-delà, restic nettoie tout seul.

Et le routeur, alors ?

Pour tout ce qui est OpenWrt (mon routeur maison), j'ai laissé tomber restic - trop lourd pour un système aussi contraint. OpenWrt a son propre outil natif, sysupgrade -b, qui génère une archive complète de la config en une commande. Cette archive rejoint simplement le même disque USB à chaque run.

Un exemple concret : comment je reconstruis après un crash

Avoir des sauvegardes, c'est bien. Savoir vraiment les restaurer sous pression, un jour où tout va mal, c'est autre chose. Voici le scénario que j'ai testé à froid : hawking a disparu, je repars d'une machine Debian toute neuve et je dois relancer le blog.

1. Installer restic et retrouver le dépôt

sudo apt-get install restic
export RESTIC_REPOSITORY=sftp:hermes-exec@rasp001:/mnt/usbdata/backups/restic-repos/hawking
export RESTIC_PASSWORD_FILE=/root/.restic-password

2. Lister les snapshots disponibles

restic snapshots

ID        Time                 Host      Tags  Paths
a3f1c9e2  2026-09-15 03:00:11  hawking         /etc, /opt/stranix-git, /var/lib/hermes
d82e410b  2026-09-16 03:00:08  hawking         /etc, /opt/stranix-git, /var/lib/hermes

Je prends le plus récent - restic garde chaque jour comme un instantané complet et navigable, même si techniquement seuls les blocs modifiés sont stockés.

3. Restaurer les fichiers

restic restore latest --target /restore-hawking

Quelques minutes plus tard, /restore-hawking/opt/stranix-git contient exactement la configuration Docker du jour de la sauvegarde - je peux la remettre en place avec docker compose up -d comme si de rien n'était.

4. Réimporter la base du blog

Le dump MariaDB fait partie de cette même sauvegarde (c'est tout l'intérêt de dumper avant de sauvegarder plutôt que de copier les fichiers à chaud) :

gunzip -c /restore-hawking/var/backups/ghost-db.sql.gz | docker exec -i ghost_mariadb sh -c 'mariadb -uroot -p"$MYSQL_ROOT_PASSWORD" "$MYSQL_DATABASE"'
docker compose up -d ghost

Et voilà - le blog redémarre avec ses articles, ses commentaires et ses réglages tels qu'ils étaient à la dernière sauvegarde, pas plus vieux qu'une journée.

Ce test m'a pris vingt minutes, montre en main, sur une VM jetable. C'est vingt minutes bien investies : le jour où j'en aurai vraiment besoin, ce ne sera pas la première fois que j'essaie.

Ce que ça change

Aujourd'hui, si hawking meurt, si un Raspberry Pi rend l'âme, ou si les deux à la fois (touchons du bois), je peux reconstruire l'ensemble : la config Docker, les bases de données, le site, les clés SSH, la config du routeur - depuis un disque USB ou depuis pCloud si la maison n'existe plus.

Le vrai test, cela dit, ce n'est pas d'avoir des sauvegardes - c'est de les restaurer une fois pour de vrai, à froid, pour vérifier que ça marche vraiment. C'est la prochaine étape, et clairement pas la plus excitante, mais c'est celle qui compte le jour où on en a besoin.

Setup complet : un serveur OVH, deux Raspberry Pi à la maison, restic, rclone et beaucoup trop de café.