Test de restauration : vérifiez vos sauvegardes à l'avance

Une sauvegarde que vous n'avez jamais restaurée n'est pas une sauvegarde — c'est un espoir. Un test de restauration prend une heure par trimestre et transforme l'espoir en fait vérifié.

Ce qu'il faut vérifier

Trois questions auxquelles vous devez répondre avant tout incident :

1. L'exhaustivité. La sauvegarde contient-elle tout le nécessaire pour démarrer : données, paramètres, clés, certificats, planification.
2. La lisibilité. L'archive s'ouvre-t-elle, le dump de la base de données se restaure-t-il sans erreur.
3. Le temps. Combien d'heures prendra une restauration complète. Vous devez connaître ce chiffre à l'avance, et non le découvrir sous pression.

Comment mener l'exercice

L'option la plus honnête est sur une machine distincte, pas sur celle de production. Prenez un VDS-1 pendant un mois, restaurez dessus à partir de zéro et chronométrez.

export RESTIC_REPOSITORY="sftp:backup@backup.example.com:/srv/restic"
export RESTIC_PASSWORD_FILE=/root/.restic-pass

restic snapshots
restic restore latest --target /restore
ls -la /restore

Restaurez la base de données :

docker compose up -d db
gunzip -c /restore/var/backups/db.sql.gz | docker compose exec -T db psql -U postgres app
docker compose exec -T db psql -U postgres app -c "select count(*) from users;"

Lancez l'application et ouvrez-la dans un navigateur — c'est l'étape finale. Tant que la page ne s'ouvre pas, la restauration n'a pas eu lieu.

Une option plus légère, elle aussi utile : restaurez uniquement la base de données dans un conteneur séparé sur la même machine et assurez-vous que les données sont présentes et à jour.

Vérifiez non seulement que le dépaquetage a réussi, mais aussi la date des données. Une sauvegarde créée de manière fiable mais qui n'inclut plus le répertoire nécessaire depuis un mois paraît parfaitement normale dans la liste des snapshots. Comparez le nombre d'enregistrements dans les tables et les horodatages des derniers fichiers.

Ce qui ressort généralement

• Le fichier .env est oublié. Les données sont là, mais pas les mots de passe pour y accéder.
• Les certificats sont oubliés. Le site démarre mais ne répond pas en HTTPS.
• La planification est oubliée. Tout fonctionne, mais les sauvegardes ne sont plus créées — et vous ne le découvrez qu'un mois plus tard.
• L'ordre de démarrage n'est pas consigné. L'application démarre avant la base de données et plante.
• Le mot de passe du dépôt n'existait que sur la machine perdue. Les sauvegardes existent, mais vous n'y avez plus accès.
• La restauration prend dix heures, pas deux. Bande passante du récepteur ou baie de disques, voir vitesse du disque.

Consignez la procédure

À partir de l'exercice, rédigez une courte instruction et conservez-la hors de la machine :

1. Commandez une machine de gamme identique ou supérieure — le provisionnement prend environ une minute.
2. Installez Docker et restaurez /opt/myapp depuis la sauvegarde.
3. Restaurez le dump de la base de données, vérifiez le nombre d'enregistrements.
4. Restaurez /etc/nginx et les certificats, lancez le serveur web.
5. Faites pointer le domaine vers la nouvelle adresse.
6. Restaurez la planification depuis crontab.txt.
7. Vérifiez : le site s'ouvre, la connexion fonctionne, les sauvegardes sont de nouveau créées.

Le point 5 est le plus sous-estimé. Les enregistrements DNS ne se mettent pas à jour instantanément, et vous devez abaisser le TTL de l'enregistrement à 300 secondes à l'avance si vous envisagez une migration.

À quelle fréquence

Une fois par trimestre pour les services de production, une fois tous les six mois pour tout le reste. Et toujours après un changement majeur : une nouvelle base de données, un nouveau service, un déplacement de répertoires. Inscrivez l'exercice au calendrier, sinon il n'aura jamais lieu.

Ce qui doit figurer dans la sauvegarde — ce qu'il faut sauvegarder exactement. Où la stocker — sauvegardes hors site. Si un incident s'est déjà produit — données perdues.