Tester les sauvegardes et préparer une restauration
Une sauvegarde est utile lorsqu’elle permet de récupérer un service et ses données dans des conditions connues. Une notification de copie réussie ne prouve ni l’intégrité du contenu ni le fonctionnement de l’application après reprise. Préparez un exercice limité, documenté et indépendant de la production.
Photo : Markus Spiske / Unsplash · Photographie de contexte ; aucune affiliation à FDS n’est sous-entendue.
Définir ce qui doit être rétabli
Listez les services essentiels : site, base de données, médias, documents, formulaires et messagerie liée au traitement des demandes. Pour chacun, identifiez la personne capable de valider le résultat et les dépendances nécessaires à son fonctionnement. Un fichier retrouvé ne suffit pas si sa lecture exige un logiciel ou une configuration indisponible.
Fixez deux objectifs propres à l’activité : le délai acceptable de retour au service et la quantité de données récentes que vous pouvez perdre. Ces objectifs doivent être discutés avec les personnes qui utilisent le service. Ils ne sont ni des moyennes de marché ni des garanties de votre hébergeur.
Distinguer synchronisation et sauvegarde
Une synchronisation peut propager une suppression ou une corruption. Vérifiez que votre solution conserve des versions récupérables et que les copies ne dépendent pas toutes du même compte ou du même support. Contrôlez aussi les données conservées par vos outils externes : leur export peut nécessiter une action distincte.
Documentez la fréquence et la durée de conservation en fonction du besoin. Protégez l’accès aux copies, et évitez que la compromission d’un administrateur suffise à supprimer les originaux et toutes les versions. L’organisation des protections dépend du service ; testez-la avec le responsable technique.
Restaurer dans un environnement isolé
Choisissez une copie et une destination de test qui ne remplace pas les données actives. Vérifiez auparavant la capacité à désactiver les courriels, paiements et automatisations sortantes. Une restauration de test ne doit pas déclencher d’actions réelles auprès de clients ou de partenaires.
Consignez la date de la copie, sa portée, les versions nécessaires, les opérations et la durée. Vérifiez qu’un utilisateur autorisé peut retrouver un document, naviguer dans les pages et effectuer un parcours d’essai. Contrôlez les pièces jointes et les fichiers récents, pas seulement la page d’accueil.
Définir une preuve de restauration réussie
Comparez le résultat aux critères établis avant le test : données présentes, fichiers lisibles, droits corrects et parcours essentiels fonctionnels. Un test qui dépasse le délai cible ou oublie une dépendance révèle un travail à réaliser, même si certaines pages répondent.
Écrivez un compte rendu indiquant les écarts et leurs responsables. Rejouez les points corrigés. Conservez la procédure dans un lieu accessible lorsque le service habituel est indisponible, avec des contacts de reprise vérifiés. N’y recopiez aucun secret ; indiquez le moyen autorisé de retrouver les accès.
Organiser la décision de reprise
Une restauration après incident doit tenir compte de la cause et de l’état du système. Reprendre une version sur une infrastructure encore compromise peut réintroduire le problème. Faites décider la reprise par le responsable désigné, en coordination avec les compétences nécessaires.
Prévoyez comment prévenir les utilisateurs concernés, vérifier le retour au service et traiter les demandes arrivées pendant l’interruption. Après l’exercice ou l’incident, ajustez la procédure et les objectifs. Refaites un test lorsque la structure des données, le fournisseur ou l’application change de manière importante.
Une fiche à conserver avec la décision
| Élément | Preuve |
|---|---|
| Périmètre | Services, données et dépendances à récupérer. |
| Objectifs | Délai cible et perte de données acceptable, validés par l’activité. |
| Exercice | Copie choisie, environnement isolé et parcours d’essai. |
| Résultat | Durée, données présentes, écarts, correctifs et décision de validation. |
Questions fréquentes
L’hébergeur sauvegarde déjà : faut-il tester ?
Oui. Vérifiez le périmètre prévu au contrat, la durée de conservation, les délais et les modalités de récupération. Un test confirme ce que vous pouvez réellement restaurer et ce qui reste à votre charge.
Une copie récente est-elle toujours la meilleure ?
Elle peut contenir le défaut ou la suppression que vous cherchez à corriger. Identifiez une version adaptée à l’incident et vérifiez son contenu dans un environnement isolé avant toute reprise.
Références
Cybermalveillance.gouv.fr · Sauvegardes
La grille pratique est une synthèse éditoriale à adapter à votre service. Elle ne constitue ni une certification ni un résultat d’audit.