Un backup jamais restauré n'est pas un backup : c'est une supposition. J'ai vu des dumps corrompus depuis des mois, des sauvegardes qui excluaient une table clé, des scripts qui tournaient dans le vide. On ne le découvre qu'au pire moment — sauf si on teste.
La seule preuve qu'un backup marche, c'est une restauration réussie sur un environnement vierge. Le reste, c'est de l'espoir.
La règle qui a fait ses preuves : 3 copies des données, sur 2 supports différents, dont 1 hors site. Une seule sauvegarde au même endroit que la prod ne protège de rien — un incident emporte les deux.
La sauvegarde est la partie facile. La partie qui sauve, c'est la restauration régulière sur une base vierge, vérifiée automatiquement. Si ce n'est pas automatisé, ce n'est pas fait.
Sur AWS, les snapshots RDS automatiques + la restauration point-in-time couvrent déjà beaucoup — mais teste quand même une restauration réelle une fois par trimestre.
Deux chiffres définissent ta stratégie. Le RPO : combien de données tu acceptes de perdre (l'âge du dernier backup). Le RTO : en combien de temps tu dois être de nouveau debout. Ils dictent la fréquence et le type de sauvegarde.
Comment je structure un projet qui grossit : quand le monorepo aide, quand il devient un poids.
Coder dans le terminal avec un agent : le mental model, les commandes qui comptent, et comment le garder sur les rails.