Vérifiez qu’une sauvegarde permet de reprendre le travail : environnement isolé, accès, contrôles métier et mesure du délai de restauration.
Le tableau de bord annonce que la sauvegarde s’est terminée. La prochaine vérification consiste à remettre les données et l’application en service dans un environnement de test. Vous saurez alors ce que votre équipe peut récupérer, avec quels accès et dans quel délai.
Cet exercice concerne aussi bien une application hébergée dans le cloud qu’un serveur local. Pour une PME dont plusieurs collaborateurs utilisent le même outil de gestion, le critère utile est la reprise d’un parcours de travail : retrouver un dossier, consulter ses pièces et effectuer une opération autorisée.
Définir le scénario de perte
Choisissez un incident précis. La suppression d’une table, l’indisponibilité d’un serveur et la perte d’un compte d’administration n’exigent pas la même procédure. Un premier exercice doit avoir un périmètre que l’équipe pourra vérifier jusqu’au bout.
Listez les dépendances de l’application : base de données, fichiers déposés, configuration, secrets, réseau et service d’identité. Précisez ce que la sauvegarde contient. Une copie de la base ne rétablit pas les documents stockés ailleurs.
Demandez au responsable métier combien de travail il peut accepter de ressaisir et combien de temps l’activité peut attendre. Ces besoins servent à définir la perte de données tolérée et le délai visé. Ils doivent être comparés avec ce que l’exercice démontre réellement.
Restaurer dans un environnement isolé
Préparez une destination distincte de la production. Vérifiez sa capacité et ses droits d’accès avant l’essai. Désactivez les envois d’emails, paiements, relances et autres effets externes : une copie de l’application peut retrouver ses tâches planifiées dès son démarrage.
Conservez les protections requises pour les données restaurées. L’environnement de test ne devient pas public parce qu’il est temporaire. N’envoyez pas une copie de la base à un prestataire sans avoir défini l’accès et le traitement prévus.
Pour Amazon S3, AWS distingue plusieurs mécanismes de protection dans son article sur une stratégie de sauvegarde résiliente. Le choix dépend notamment du type de perte à couvrir. Une fonction activée dans la console doit toujours être reliée à un scénario de récupération documenté.
Démarrer le chronomètre au bon moment
Mesurez le délai dès le début de la procédure convenue, en incluant la recherche de la bonne copie et l’obtention des accès. Démarrer la mesure seulement au lancement de la commande de restauration masquerait une partie du travail.
| Étape | Preuve à conserver |
|---|---|
| Sélection de la sauvegarde | Référence, date et périmètre |
| Préparation de la destination | Configuration utilisée et accès nécessaires |
| Restauration | Journal et durée de l’opération |
| Démarrage de l’application | Version du code et configuration |
| Contrôle métier | Scénarios exécutés et résultats |
| Clôture | Écarts, responsable et action corrective |
Dans un exemple fictif, la restauration technique dure vingt minutes, mais l’équipe passe quarante minutes à retrouver l’accès au stockage. Le compte rendu doit mentionner une heure avant même la validation métier. La correction prioritaire porte alors sur l’accès de secours autant que sur la vitesse de copie.
Contrôler ce que l’utilisateur retrouve
Choisissez des dossiers repères avant l’exercice, avec des références non sensibles dans le compte rendu. Vérifiez les pièces jointes et les relations entre données. Un nombre total de lignes identique ne démontre pas que les fichiers associés sont lisibles.
Testez un utilisateur ordinaire. Une application utilisable seulement avec le compte administrateur n’a pas retrouvé son fonctionnement habituel. Vérifiez aussi les droits : une restauration ne doit pas réactiver sans examen des comptes précédemment désactivés.
Pour la donnée récente, comparez la dernière opération récupérée avec la période que la sauvegarde devait couvrir. Si plusieurs systèmes échangent des informations, relevez leurs écarts. Une commande restaurée dans l’ERP peut déjà avoir été expédiée dans un autre outil ; la reprise doit éviter de déclencher l’expédition une seconde fois.
Corriger puis refaire les étapes en échec
Consignez chaque obstacle avec une action observable : stocker la procédure au bon endroit, rendre une clé de secours disponible à la personne autorisée ou ajouter un répertoire absent de la sauvegarde. « Améliorer la documentation » est trop vague pour vérifier la correction.
Refaites le contrôle concerné après modification. Prévoyez ensuite de nouveaux essais selon la criticité de l’application et après des changements importants d’architecture. Le coût comprend l’infrastructure temporaire, les éventuels transferts et le temps des personnes qui valident.
Avant une migration, intégrez cet exercice à votre audit DevOps et à votre plan de bascule cloud. Sky Vaults peut vous aider à cadrer ces opérations dans une prestation DevOps et cloud au Maroc. Présentez-nous l’application concernée et les contraintes de reprise de votre activité.