Sauvegardes d’un site en production : appliquer la règle 3-2-1 et tester la restauration

Une sauvegarde qui n’a jamais été restaurée n’est pas une sauvegarde : c’est une hypothèse. Beaucoup de sites en production reposent sur un unique dump nocturne posé sur le même serveur que les données qu’il protège, ce qui ne survit ni à une panne de disque, ni à un chiffrement par rançongiciel, ni à une fausse manipulation. Cet article pose une méthode éprouvée pour construire une stratégie de sauvegarde fiable et, surtout, pour prouver qu’elle fonctionne.

#La règle 3-2-1, et pourquoi elle tient encore

La règle 3-2-1 se résume en une phrase : trois copies des données, sur deux supports différents, dont une hors site. Elle a plus de vingt ans et reste la référence parce qu’elle ne protège pas contre un risque, mais contre une famille entière de risques.

La copie hors site est celle qu’on néglige le plus, et c’est précisément celle qui sauve lors d’un incendie de salle serveur ou d’un chiffrement malveillant qui atteint tout ce qui est monté localement. Une variante récente, dite 3-2-1-1-0, ajoute une copie immuable et un objectif de zéro erreur à la restauration testée.

#Choisir un outil : rsync, restic ou borg

Le choix de l’outil découle du besoin réel, pas de la mode. Trois familles couvrent l’essentiel des cas d’un site web.

Pour un site autohébergé qui doit envoyer ses données vers un stockage objet distant, restic offre le meilleur compromis : dépôt chiffré de bout en bout, déduplication qui limite la volumétrie, et prise en charge directe des backends S3. L’exemple qui suit initialise un dépôt puis sauvegarde les fichiers et une base de données.

# Variables d'environnement (a stocker hors du depot versionne)
export RESTIC_REPOSITORY="s3:s3.eu-west-3.amazonaws.com/mon-bucket-sauvegardes"
export RESTIC_PASSWORD_FILE="/root/.restic-pass"

# Initialisation, une seule fois
restic init

# Sauvegarde des fichiers du site
restic backup /var/www/monsite --tag fichiers

# Sauvegarde de la base : on evite le fichier intermediaire en clair
mysqldump --single-transaction monsite \
  | restic backup --stdin --stdin-filename monsite.sql --tag base

#Automatiser sans se croire à l’abri

Une sauvegarde manuelle n’est jamais faite le jour où elle compte. L’automatisation passe par une tâche planifiée, qu’il s’agisse d’une entrée cron ou d’un timer systemd, ce dernier ayant l’avantage de journaliser proprement et de rejouer une exécution manquée.

# /etc/systemd/system/backup.timer
[Unit]
Description=Sauvegarde quotidienne du site

[Timer]
OnCalendar=*-*-* 03:30:00
Persistent=true
RandomizedDelaySec=600

[Install]
WantedBy=timers.target

La politique de rétention se pilote côté restic, qui sait ne garder qu’un nombre choisi de points par jour, semaine et mois, puis purger le reste. Cette étape est indispensable : sans elle, le dépôt gonfle indéfiniment et la facture de stockage suit.

# Rotation : 7 quotidiennes, 4 hebdomadaires, 6 mensuelles
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

#Le test de restauration : la seule preuve qui compte

C’est l’étape que presque personne ne fait, et c’est la seule qui transforme une intention en garantie. Un dépôt qui n’a jamais été restauré peut être corrompu, incomplet, ou chiffré avec une clé qu’on a perdue, sans qu’aucun tableau de bord ne le signale.

Le jour de l’incident n’est pas le jour où l’on découvre que la restauration ne marche pas.

Le test se mène sur un environnement isolé, jamais en écrasant la production. L’objectif est double : vérifier que les données reviennent, et mesurer combien de temps cela prend, car ce délai est votre véritable point de reprise.

# Restauration d'un instantane precis vers un repertoire de controle
restic snapshots
restic restore 4a8f2c1b --target /tmp/restore-test

# Verification d'integrite du depot (a planifier aussi)
restic check --read-data-subset=5%

Une restauration mensuelle, notée dans un journal avec sa date et sa durée, vaut mille rapports de sauvegarde « au vert ». C’est aussi le moment de vérifier que la procédure est documentée assez clairement pour être exécutée par quelqu’un d’autre que son auteur, un soir de panne.

#Ce qu’il faut retenir

Une stratégie de sauvegarde solide tient en trois décisions : appliquer la règle 3-2-1 pour couvrir toutes les familles de risque, automatiser avec une rétention explicite pour ne pas dépendre de la discipline humaine, et tester la restauration régulièrement pour transformer l’hypothèse en certitude. Ces réflexes s’intègrent naturellement à une démarche plus large de gestion d’un serveur autohébergé et complètent le durcissement d’un socle côté sécurité.

Pour aller plus loin : la documentation officielle de restic, notamment les chapitres sur les politiques de rétention et la vérification des dépôts.