Une sauvegarde jamais restaurée n'est qu'une hypothèse

L'affirmation

La couverture des sauvegardes est le mauvais indicateur. Le seul nombre qui décrit votre risque réel, c'est la durée de votre dernière restauration réussie et vérifiée dans un environnement neuf. Si vous ne pouvez pas énoncer ce nombre en minutes, vous n'avez pas de capacité de reprise : vous avez un dossier de fichiers que vous croyez utiles.

Deux nombres, définis correctement

La perte de données maximale admissible correspond à ce que vous acceptez de perdre, mesuré vers l'arrière depuis l'incident. La durée maximale d'interruption admissible correspond au temps d'arrêt que vous tolérez, mesuré vers l'avant. Des sauvegardes nocturnes à 2 h vous donnent jusqu'à 24 heures de perte. Une entreprise qui traite 60 commandes par jour et tombe en panne à 16 h vient d'en perdre environ 35, et aucune restauration soignée ne les ramènera.

Interrogés directement, la plupart des dirigeants répondent que perdre une journée de commandes est inacceptable. La plupart de ces mêmes entreprises n'ont qu'une sauvegarde nocturne. L'écart entre la tolérance déclarée et le comportement configuré, c'est exactement là que loge le risque.

Combler l'écart coûte moins cher qu'on ne le croit

Pour PostgreSQL, l'archivage continu fait passer votre perte admissible de quelques heures à la taille d'un segment de journal de transactions. Avec pgBackRest :

[global]
repo1-path=/var/lib/pgbackrest
repo1-retention-full=2
repo1-cipher-type=aes-256-cbc

[main]
pg1-path=/var/lib/postgresql/16/main
archive-async=y

Avec archive_mode = on et un archive_command pointant vers pgBackRest, une sauvegarde complète hebdomadaire, des incrémentales quotidiennes et l'archivage continu vous donnent une restauration à un instant précis, à la seconde près. Pour une base de 20 Go au volume d'écriture modéré, l'archive conservée dépasse rarement 100 Go, ce qui est une erreur d'arrondi sur du stockage objet.

La partie réellement difficile

Prendre des sauvegardes est facile. Les restaurer sous pression ne l'est pas, et la cause n'est presque jamais la base de données. C'est tout ce qui l'entoure : les variables d'environnement que personne n'a documentées, les identifiants de stockage qu'on a fait tourner, l'extension qui doit exister avant que la sauvegarde ne se charge, la durée de vie DNS qui impose 40 minutes de bascule quelle qu'ait été la vitesse de restauration.

Chacun de ces points se découvre à l'avance, et d'une seule manière. Restaurez pour de vrai.

Un test de restauration automatisé, cette semaine

L'objectif n'est pas un exercice parfait. C'est une tâche qui échoue bruyamment quand la sauvegarde cesse d'être restaurable.

#!/usr/bin/env bash
set -euo pipefail

DB="verify_$(date +%s)"
createdb "$DB"
trap 'dropdb --if-exists "$DB"' EXIT

pgbackrest --stanza=main --delta --db-path=/tmp/verify restore
pg_restore -d "$DB" /backups/latest.dump

ROWS=$(psql -tAX -d "$DB" -c "SELECT count(*) FROM orders WHERE created_at > now() - interval '2 days'")
[ "$ROWS" -gt 0 ] || { echo "ECHEC: aucune commande recente dans la copie"; exit 1; }

psql -tAX -d "$DB" -c "SELECT 1 FROM users LIMIT 1" > /dev/null
echo "OK: restauree et verifiee, $ROWS commandes recentes"

La requête de contrôle est la ligne importante. Une restauration qui se termine sans erreur mais produit une table orders vide est un échec, et une tâche qui ne vérifie que le code de sortie de pg_restore annoncera un succès. Choisissez deux ou trois requêtes dont vous savez interpréter le résultat, et faites échouer la tâche quand elles vous surprennent.

Chronométrez, puis publiez le chiffre

Mesurez la séquence complète, y compris les étapes qu'un script ne peut pas faire :

Cela donne une interruption réaliste de 35 à 105 minutes pour une base que la plupart des gens qualifient de petite. Si votre cible annoncée est de 15 minutes, il vous faut un serveur de secours tiède, pas une meilleure sauvegarde. Si 90 minutes conviennent, tout va bien — mais maintenant vous le savez, et la personne qui posera la question pendant l'incident le saura aussi.

Les trois règles

1. Les sauvegardes vivent dans un autre compte et une autre région que ce qu'elles protègent. Un rançongiciel qui atteint votre hôte atteint tout ce que cet hôte peut écrire.
2. Le test de restauration s'exécute selon un calendrier et alerte une personne quand il échoue, comme n'importe quelle autre alerte de production.
3. Une personne autre que celle qui a construit le système effectue une restauration, à partir de la documentation, une fois par an. Si elle n'y arrive pas, la documentation est fausse.

Tant que vous ne l'avez pas fait une fois, votre stratégie de sauvegarde est une hypothèse. Testez-la un mardi matin par choix, plutôt qu'à 3 h par contrainte.