Tester une sauvegarde en restaurant le parcours complet
Vérifiez ensemble base de données, fichiers et accès. Un exemple chiffré distingue l’écart de données du délai de reprise.
Un message de sauvegarde réussie indique qu’une tâche s’est terminée. Pour savoir si votre équipe pourra reprendre le travail, restaurez puis testez un parcours métier complet. Incluez les fichiers, les droits et les connexions nécessaires.
Définir un essai sans effet sur la production
Utilisez un environnement de test séparé et des données artificielles. Désactivez les envois de courriels, paiements et autres actions réelles. Ne restaurez pas une sauvegarde sur la production pour faire un essai. Les clés et identifiants nécessaires doivent être accessibles selon la procédure de reprise prévue, sans être copiés dans le compte rendu.
Cet exemple fictif porte sur une application de commandes. Objectifs choisis : au plus 60 minutes d’écart de données, le Recovery Point Objective ou RPO, et 120 minutes au maximum avant le retour d’un service utilisable, le Recovery Time Objective ou RTO. Ce sont des objectifs d’exemple, pas des engagements de service. AWS recommande de les fixer selon l’impact métier.
Une chronologie détaillée
Heure | Événement de l’exemple |
|---|---|
09:25 | État cohérent des données, dont la commande de test T-17 et sa pièce jointe |
09:30 | Fin de la sauvegarde contenant cet état |
10:00 | Panne supposée ; début du chronométrage |
10:40 | Base de données techniquement restaurée |
10:50 | Connexion possible ; pièces jointes encore absentes |
11:05 | Pièces jointes, droits et parcours complet de commande testés avec succès |
L’écart de données vérifié est de 35 minutes, de 09:25 à 10:00. La reprise dure 65 minutes, de 10:00 à 11:05. L’exemple respecte donc les deux objectifs. La fin d’une sauvegarde à 09:30 ne signifie pas que son contenu est à jour jusqu’à cette heure.
À 10:40, le test n’est pas encore réussi. Une base active sans les pièces jointes nécessaires ne permet pas le parcours convenu. La connexion à 10:50 ne suffit pas non plus.
Démontrer la reprise du travail
Vérifiez les lignes attendues de T-17 et ouvrez sa pièce jointe. Connectez-vous avec un rôle utilisateur ordinaire prévu : il doit voir les commandes autorisées, sans accéder aux espaces protégés hors de ses droits. Créez ensuite une commande de test et menez-la jusqu’à l’étape finale prévue. Les transmissions externes visent uniquement des systèmes de test.
Le compte rendu indique d’abord « Pièce jointe absente ; test échoué ». Après correction et nouvel essai : « T-17 complète ; rôles vérifiés ; nouvelle commande de test terminée ». Notez l’état des données sauvegardées et les heures réelles. Une coche sans résultat ne dira pas, plus tard, ce qui a été rétabli.
Choisir la correction à partir du résultat
Des fichiers absents imposent de revoir le périmètre sauvegardé. Une clé manquante exige d’organiser sa disponibilité contrôlée dans le plan de reprise. Si le délai est trop long, trouvez le véritable point de blocage et répétez les étapes concernées. Des sauvegardes plus fréquentes n’accélèrent pas, à elles seules, un import lent.
Les durées de l’exemple ne remplacent pas vos mesures. Répétez l’essai complet notamment après un changement de stockage, de chiffrement, de rôles ou de procédure. Conservez un résultat compréhensible pour disposer d’un point de comparaison au prochain essai.
Sources
À lire aussi
Tous les articles
Cloud & exploitation avec ASES
Hébergement, déploiement, maintenance et suivi