Minuit. Un DELETE sans WHERE sur la table commandes. L'admin ouvre le ticket « restore backup ». À 2 h, le dump MySQL refuse de s'importer — charset incompatible. À 4 h, les fichiers media manquent : ils étaient sur un volume non snapshoté. À 6 h, le client apprend que personne n'avait jamais fait l'exercice.
Tester une restauration n'est pas de la paranoia. C'est la seule preuve que votre stratégie de sauvegarde fonctionne hors PowerPoint.
Deux scénarios minimum à simuler
Scénario A — Erreur humaine ciblée. Une table ou un répertoire supprimé. Objectif : restore partiel en moins de votre RTO, sans tout reconstruire.
Scénario B — Compromission ou ransomware. Production suspecte. Objectif : rebuild sur infra vierge depuis une copie immuable datée d'avant l'intrusion — pas la dernière sauvegarde.
| Scénario | Question testée | Succès mesurable |
|---|---|---|
| Table DROP | Dump partiel / PITR | Site commandes OK, données cohérentes |
| Ransomware | Copie immuable J-5 | Pas de malware, secrets rotés |
| Mauvais deploy | Rollback code + DB alignée | Version N-1 fonctionnelle |
| Perte datacenter | Restore hors site | DNS basculé, RTO tenu |
Si vous ne testez qu'un scénario, testez le pire — pas le plus confortable.
Sandbox : reproduire sans risque
Machine isolée — VPS jetable, Docker compose local, VM offline.
Données anonymisées si RGPD — masquez emails et PII pour les tests fréquents ; gardez un test annuel sur copie fidèle en environnement fermé.
Checklist ordonnée — DNS de test, import DB, sync fichiers, variables d'environnement, workers, cache flush, smoke test login + paiement.
Chronométrez chaque étape. Votre RTO théorique de 2 h qui devient 8 h en pratique est l'information la plus précieuse de l'exercice.
Ce que l'exercice révèle presque toujours
- Credentials backup expirés ou 2FA bloquant le restore automatisé.
- Dumps vides ou 0 octet passés inaperçus.
- Version MySQL restore incompatible avec dump source.
.envmanquant — l'app démarre mais n'envoie plus de mails.- Ordre inverse : site up, images 404 car objet storage non resync.
Notez chaque écart dans un runbook daté. C'est votre capital pour la vraie crise.
Mesurer et améliorer
Fixez des KPI simples :
- Temps total vs RTO cible.
- Données perdues simulées vs RPO cible.
- Nombre d'étapes manuelles — candidate à l'automatisation.
- Tickets ouverts pendant l'exercice — formation manquante ?
Partagez un compte-rendu court à l'équipe. Un échec en sandbox vaut de l'or ; un échec en production vaut un client perdu.
Le sommet : le backup « vérifié » par l'hébergeur n'est pas votre restore
C'est la ligne que les SLA marketing effacent. Exigez un exercice interne ; ne déléguez pas la compétence restore.
Décider et avancer sans angle mort
- Planifiez le prochain test dans le calendrier (date fixe, pas « quand on aura le temps »).
- Préparez sandbox + jeu de données représentatif.
- Jouez scénarios A et B avec chronomètre.
- Corrigez le pipeline backup avant de clôturer.
- Comparez hébergeurs sur facilité de restore via annuaire.
Voir aussi preuve de restauration pour documenter l'exercice vis-à-vis des clients ou auditeurs.
Questions fréquentes
À quelle fréquence tester une restauration ?
Minimum trimestriel pour un site critique ; semestriel pour un vitrine. Retestez après changement majeur d'infra ou de backup.
Faut-il restaurer en production ?
Non. Sandbox isolée. L'exercice mesure le processus, pas la dispo live.
Que faire si la restauration échoue ?
Documentez la cause, corrigez le pipeline, retestez dans la semaine avec preuve.
Restauration partielle ou complète ?
Les deux selon scénario : table supprimée = partiel ; ransomware = rebuild complet depuis copie saine ancienne.
Un backup non restauré en sandbox n'est pas une assurance. C'est une hypothèse — et les hypothèses éclatent toujours un mardi nuit.