Exécuter un drill de restauration PITR PostgreSQL chaque semaine (voici notre runbook)

Une sauvegarde qui n'a jamais été restaurée est un espoir, pas une sauvegarde. Chaque base Postgres managée que nous exploitons passe par un drill hebdomadaire de point-in-time recovery (PITR), automatisé de bout en bout, avec le résultat publié dans votre rapport de santé mensuel.

Ce que fait réellement le drill

1. Choisir un timestamp aléatoire dans les 7 derniers jours de rétention WAL.
2. Provisionner une instance sandbox dans une classe d'instance moins chère que la prod.
3. Restaurer la dernière base backup dans la sandbox.
4. Rejouer les WAL jusqu'au timestamp choisi.
5. Lancer une sonde d'intégrité — diff de schéma contre la prod, delta de row-count dans une tolérance, une poignée de checks SQL d'intégrité.
6. Démonter la sandbox. ~5 minutes de compute facturées. Reporter succès ou échec.

Ce qu'il attrape

Les quatre choses que ce drill attrape et que les alertes « la sauvegarde a tourné » n'attrapent pas :

• Les sauvegardes qui passent silencieusement de WAL+base à « juste des snapshots » parce que quelqu'un a changé la policy de rétention
• Les gaps WAL causés par des échecs archive_command que personne n'a remarqués parce que la DB continue de tourner
• Le drift de permissions qui laisse les sauvegardes se faire mais bloque le rôle de restauration de les lire
• La rotation de clés de chiffrement qui a inutilisé les snapshots plus anciens

Ce que nous n'automatisons pas

Nous n'automatisons pas la déclaration de désastre. Le runbook exige explicitement qu'un humain décide nous faisons une vraie restauration, pas le drill. Ce garde-fou nous a sauvés plus d'une fois de « l'automation s'emballe et restaure la prod à hier ».

Le runbook complet sur Medium contient le Terraform que nous utilisons pour faire tourner la sandbox, le Bash qui compare les schémas, et les règles d'alerte qui escaladent quand le drill échoue deux fois de suite.