Checklist de test de restauration d’un site événementiel
La présence d’une sauvegarde ne prouve pas que le site peut être remis en service. Avant l’ouverture de la billetterie, restaurez une copie à l’écart du site public et vérifiez le parcours visiteur. Écartez les vraies données des participants et les paiements réels.
La rédaction de Boletolibre
Publié
1. Définir le périmètre et les objectifs
Notez l’horodatage et le fuseau de la sauvegarde, les responsables et le parcours essentiel. Le RTO est l’interruption maximale acceptable ; le RPO est la perte de données maximale acceptable exprimée en durée. Fixez vos propres seuils et mesurez le résultat réel. Une sauvegarde réussie seule ne suffit pas.[3][2]
| À noter | Exemple |
|---|---|
| Parcours essentiel | Page → inscription ou billets → confirmation sûre |
| Point de reprise | Date, heure, fuseau et lieu de la copie |
| RTO et RPO cibles | Limites approuvées par l’équipe |
| Environnement | Essai isolé, sans modifier le DNS public |
2. Inventorier ce que contient la copie
Vérifiez séparément pages et base de données, fichiers et médias, configuration et secrets. Une sauvegarde de la base WordPress, par exemple, ne comprend pas fichiers, thèmes, extensions, téléversements ni fichier de configuration. Les données d’une billetterie ou messagerie externe relèvent de leur propre plan.[4]
- Nommer la source et le responsable de chaque composant.
- Documenter DNS et certificat sans basculer la production.
- Marquer « non testé » tout service externe hors de l’exercice.
3. Restaurer sans effet réel
- Préparer un site de test restreint et noter l’heure de départ.
- Désactiver ou rediriger e-mails, webhooks, mesures et paiements réels ; utiliser des données fictives.
- Restaurer fichiers, base, médias et configuration ; noter les étapes manuelles.
- Laisser intacts le site et le DNS publics.
La checklist de référence propose un environnement isolé et le contrôle des fichiers, de la base, des formulaires et des intégrations.[1]
4. Vérifier le parcours visiteur
| Contrôle | Preuve |
|---|---|
| Page événement | Date, lieu, prix et règles conformes au point restauré |
| Médias et liens | Images, téléchargements et lien billets |
| Inscription | Envoi fictif vers un espace de test seulement |
| Achat et confirmation | Mode test, sans débit ni message réel |
| Administration | Connexion autorisée et modification bénigne |
Pour chaque contrôle, noter réussi, échoué ou non testé. Une page d’accueil visible ne prouve pas que les inscriptions fonctionnent.
5. Mesurer et refaire si nécessaire
Arrêtez le chronomètre quand le parcours convenu fonctionne. Comparez la durée au RTO et l’ancienneté des données au RPO. Assignez chaque échec critique et une date de nouvel essai.[2][3]
| Compte rendu | Valeur |
|---|---|
| Date, responsable, espace | ________ |
| Copie et point de reprise | ________ |
| RTO cible / durée réelle | ________ / ________ |
| RPO cible / écart réel | ________ / ________ |
| Échecs, responsable, nouvel essai | ________ |
Conservez ce compte rendu hors du site restauré et répétez après tout changement majeur.
Sources et lectures complémentaires
- Website Backup Restore Testing Checklistmybox.com · Consulté
- Perform periodic recovery testingAWS Well-Architected Framework · Consulté
- Define recovery objectives for downtime and data lossAWS Well-Architected Framework · Consulté
- Backing up your databaseWordPress Developer Resources · Consulté