Tout le monde a des « backups ». Presque personne n'a testé une restauration. Le jour où la base est corrompue, la seule question qui compte : combien de temps, et combien de données perdues ? Voici comment sauvegarder pour de vrai.
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.
Un bon système de backup se juge à une seule chose : une restauration testée, récente et documentée. Applique le 3-2-1, automatise le dump ET son test de restauration, fixe ton RPO/RTO — et le jour de l'incident devient une formalité, pas une catastrophe.
AWS — Backup & Restore ↗