Récupérer une base PostgreSQL à la minute près après une erreur humaine

Lundi 14 h 07, un script de migration passe en production. Il devait régulariser les paiements du week-end ; sa dernière requête a perdu sa clause WHERE à la relecture. Personne ne le voit. À 15 h 30, le rapprochement bancaire ne tombe plus : toutes les transactions portent un montant à zéro. Vous restaurez le dump de 2 h du matin, le service repart, et treize heures d'encaissements disparaissent avec la bêtise. Les deux premiers labs du parcours ont réglé le temps de remise en service. Celui-ci s'attaque à l'autre chiffre, celui que personne n'avait demandé : la quantité de données perdues. Avec une sauvegarde par jour, aucune restauration, aussi rapide soit-elle, ne descend sous 24 heures de pertes — ce qui n'a pas été sauvegardé n'existe plus. Il faut changer de mécanisme. Vous mettez en place l'archivage continu des journaux de transactions vers S3, puis vous le prouvez sur un incident que vous déclenchez vous-même : vous relancez le script fautif sur une base vivante, et vous la ramenez à la seconde d'avant. Un plan de reprise qu'on n'a jamais répété n'est pas un plan, c'est un espoir. La sandbox démarre avec la production en marche — une transaction toutes les deux secondes — le dump de 02 h 00 déjà sur S3, et l'archivage des WAL à construire.