Concevoir une sauvegarde utile et tester réellement la restauration

Distinguer sauvegarde, synchronisation, export, réplication et archive

Une synchronisation propage des changements entre emplacements. Elle peut donc propager une suppression, un chiffrement malveillant ou une erreur. Un export extrait des données dans un format prévu ; il peut être précieux pour la réversibilité sans conserver toutes les versions ni permettre de reconstruire l’application. Une réplication maintient un état secondaire proche du courant ; elle améliore parfois la disponibilité mais ne remplace pas nécessairement un historique isolé.

Une archive conserve des éléments selon une finalité et une durée, souvent pour consultation ou preuve. Elle n’est pas conçue automatiquement pour une reprise rapide. Une sauvegarde conserve des copies destinées à restaurer un périmètre après perte, altération ou incident. Un même dispositif peut remplir plusieurs rôles, mais chaque rôle reçoit un objectif et un test propres.

Le vocabulaire commercial du fournisseur ne suffit pas. Vérifiez ce qui est copié, à quelle fréquence, pendant combien de temps, avec quels identifiants, dans quel format et par quelle procédure une version précise est restaurée. Une corbeille ou un historique court peut résoudre une erreur simple sans constituer une politique de sauvegarde complète.

Partir de l’activité à rétablir, pas du volume à copier

Choisissez un parcours critique : retrouver les dossiers du jour, réouvrir une application, rétablir une liste de missions, accéder aux pièces indispensables ou reconstruire un site. Décrivez le résultat minimal acceptable, les personnes concernées et les conséquences d’un état ancien ou partiel.

Fixez deux repères en langage métier. Le premier est la quantité maximale de travail ou de données qu’il serait acceptable de ressaisir après restauration. Le second est la durée pendant laquelle l’activité peut fonctionner en mode dégradé avant que le service restauré soit nécessaire. Ces repères orientent fréquence, ordre de reprise et moyens sans promettre un délai irréaliste.

Une donnée très volumineuse mais recréable peut être moins prioritaire qu’un petit registre unique. Une configuration, un modèle, un certificat, une documentation de schéma ou un média d’installation peuvent être indispensables même s’ils ne ressemblent pas à des données métier. L’ANSSI recommande justement de ne pas oublier configurations et éléments nécessaires à la reconstruction.

Construire le périmètre de sauvegarde objet par objet

Inventoriez les données structurées, fichiers, pièces jointes, configurations, versions logicielles, schémas, automatisations, clés publiques, procédures et dépendances. Pour chaque élément, nommez la source d’autorité, le propriétaire fonctionnel, la sensibilité, la fréquence de changement et la manière de vérifier une restauration.

Les secrets demandent un traitement séparé. Les copier sans politique augmente leur exposition ; ne pas prévoir leur récupération peut rendre le système inutilisable. Identifiez le coffre ou le mécanisme officiel, les personnes autorisées et la procédure de renouvellement. Ne placez jamais mots de passe, jetons ou codes de récupération dans un inventaire éditorial ou un fichier partagé ordinaire.

Définissez explicitement les exclusions : caches recréables, binaires publics vérifiables, données expirées ou doublons. Une exclusion reçoit un motif et une conséquence. L’équipe doit savoir si elle devra retélécharger, recalculer, ressaisir ou abandonner l’élément après incident.

Choisir fréquence, versions et rétention selon la perte acceptable

La fréquence dépend du rythme de modification et de la quantité de travail acceptable à refaire. Une base modifiée toute la journée et un référentiel trimestriel n’ont pas le même besoin. Mesurez le temps entre deux sauvegardes réussies et l’heure réelle du dernier état restaurable, pas seulement la planification affichée.

Conservez plusieurs points dans le temps afin de pouvoir revenir avant une corruption détectée tardivement. Une seule copie courante peut avoir remplacé le dernier état sain. Combinez si nécessaire des copies fréquentes, des points complets et des versions plus espacées, puis vérifiez que les dépendances entre elles restent compréhensibles.

La rétention ne doit pas devenir une conservation indéfinie par défaut. Elle tient compte du besoin de reprise, des obligations applicables, des engagements de suppression et de la sensibilité. Lorsqu’une donnée source doit être supprimée, documentez comment les sauvegardes protégées cessent d’être utilisées en production et expirent selon le cycle prévu.

Utiliser 3-2-1 comme repère, pas comme formule magique

La CNIL et l’ANSSI présentent la règle 3-2-1 comme un repère : trois copies au total, sur deux supports ou technologies différents, dont une copie hors ligne. Cette diversité vise à éviter qu’un même incident détruise production et sauvegardes. Elle doit être adaptée au système, au risque et à la capacité réelle de restauration.

Deux dossiers sur le même disque ne constituent pas deux protections indépendantes. Deux espaces cloud administrés par le même compte peuvent partager une dépendance d’identité. Un support hors ligne n’est utile que s’il est effectivement déconnecté, protégé, renouvelé et lisible au moment du test.

Ajoutez la séparation géographique lorsque l’incendie, l’inondation, le vol ou l’indisponibilité d’un site pourraient atteindre toutes les copies. L’objectif n’est pas d’accumuler des copies sans propriétaire, mais de rendre leurs modes d’échec suffisamment différents.

Isoler la sauvegarde des comptes et systèmes de production

Une attaque ou une erreur menée avec un compte administrateur de production ne devrait pas pouvoir modifier toutes les sauvegardes. Utilisez des rôles dédiés, le moindre privilège, une authentification adaptée et des chemins d’administration séparés lorsque le risque le justifie. Les opérations de sauvegarde et de restauration sont des opérations sensibles, pas de simples copies utilisateur.

Vérifiez l’indépendance vis-à-vis de l’annuaire, du fournisseur, du domaine et du réseau de production. Si le compte principal est perdu, une personne autorisée doit savoir comment accéder au dispositif sans contourner la sécurité. Si le fournisseur devient indisponible, les formats et les clés nécessaires doivent rester identifiables.

Préparez une procédure d’isolation d’urgence du système de sauvegarde en cas de suspicion de compromission. Elle précise qui peut couper les flux, comment préserver les journaux et quand les opérations reprennent. Couper sans méthode peut protéger une copie mais aussi supprimer l’observabilité ou interrompre une sauvegarde saine.

Protéger les sauvegardes comme les données d’origine

Une sauvegarde peut concentrer des données anciennes, des pièces et des configurations plus larges que l’écran opérationnel. Appliquez des droits bornés, un stockage sûr, un chiffrement approprié et des transmissions protégées. Les personnes capables de restaurer ne doivent pas nécessairement pouvoir consulter librement tout le contenu.

Le chiffrement crée une dépendance : la clé, sa récupération et son renouvellement doivent être testés. Une clé placée uniquement sur le système perdu rend la copie inutilisable ; une clé jointe sans protection annule une part de la séparation. Documentez l’emplacement autorisé sans inscrire le secret dans la procédure publique.

Encadrez un prestataire par le contrat et les contrôles adaptés : périmètre, localisation, accès, sous-traitants, rétention, restitution, suppression et preuve de test. Le mot « sauvegarde gérée » ne dit pas à lui seul qui déclenche la restauration, combien de temps elle prend ni comment un incident de compte est traité.

Contrôler chaque exécution sans se contenter du statut réussi

Surveillez l’heure de début et de fin, le volume, le nombre d’objets, les erreurs, les exclusions et l’âge du dernier point restaurable. Une baisse soudaine de volume peut révéler une source non montée ; une hausse inhabituelle peut signaler duplication, chiffrement ou changement non prévu.

Un contrôle d’intégrité vérifie que les fichiers ou blocs ne sont pas altérés. Il ne prouve pas que l’application sait relire le schéma, que les relations sont cohérentes ni que la copie précède l’incident. Associez donc contrôle technique, comparaison métier et test de restauration.

Les alertes ont un destinataire, un délai de traitement et une escalade. Une notification envoyée à une boîte jamais consultée ne constitue pas un contrôle. Conservez un historique proportionné des exécutions et corrections sans y recopier les données sauvegardées.

Écrire une procédure de restauration avant l’incident

La procédure indique le scénario, le point de restauration choisi, l’autorité de décision, l’environnement cible, l’ordre des dépendances et les contrôles de sortie. Elle distingue une récupération de fichier, une base complète, une application, un compte administrateur et un site entier.

Préparez l’espace disponible, les versions compatibles, les clés, les comptes et le réseau. Définissez comment empêcher une restauration de test d’envoyer des messages, déclencher des paiements, écraser la production ou exposer des données à des personnes non autorisées. L’environnement d’essai reste borné et protégé.

Le retour en production n’est pas l’étape immédiate après l’extraction. Vérifiez d’abord intégrité, relations, dates, rôles, fichiers, parcours essentiels et absence de déclencheurs indésirables. La personne métier confirme que l’état est compréhensible et utilisable, pas seulement que le service répond.

1. Choisir un scénario et une date de sauvegarde cohérents.
2. Identifier le décideur, l’opérateur et le contrôleur métier.
3. Préparer un environnement isolé et compatible.
4. Restaurer selon l’ordre documenté des dépendances.
5. Vérifier manifeste, intégrité, schéma, relations et fichiers.
6. Rejouer un parcours réel de lecture, correction et export.
7. Mesurer durée, écarts, actions manuelles et données perdues.
8. Nettoyer l’essai et mettre à jour procédure, périmètre et fréquence.

Conduire un test borné et reproductible

Commencez par un périmètre représentatif : un dossier simple, un dossier ancien, une relation multiple, une pièce jointe, un rôle, une valeur absente et un cas corrigé après sauvegarde. Le test doit détecter les pertes silencieuses, pas seulement afficher une page d’accueil.

Mesurez le temps depuis la décision jusqu’au parcours utilisable, en séparant attente, transfert, reconstruction et validation. Notez les prérequis découverts, les interventions du fournisseur et les opérations non documentées. Un délai observé sur un petit échantillon n’est pas automatiquement celui d’une reprise complète.

Conservez un compte rendu court : version de la procédure, point restauré, environnement, contrôles, résultat, écarts, responsable et prochaine action. Ne joignez pas de secrets ni de données personnelles réelles si des données synthétiques suffisent à tester le mécanisme.

Après une compromission, restaurer depuis une source de confiance

Une sauvegarde peut contenir le logiciel vulnérable, la configuration compromise ou le fichier malveillant à l’origine de l’incident. Restaurer le point le plus récent sans investigation peut réintroduire le problème. Préservez les preuves utiles, obtenez l’appui compétent et choisissez un point en fonction de la chronologie connue.

Reconstruisez les composants exécutables depuis des sources officielles et vérifiables lorsque le scénario l’exige. Mettez à jour les configurations, corrigez la cause, renouvelez les secrets exposés et analysez les données restaurées avant de reconnecter le système. Le retour nominal est une décision contrôlée, pas la fin automatique d’une copie.

Maintenez un mode dégradé sécurisé pendant la restauration. Les actions prises hors système sont journalisées avec des identifiants et seront rapprochées après reprise. N’ouvrez pas deux sources d’autorité modifiables sans règle de réconciliation.

Poser les bonnes questions à un service SaaS ou cloud

Demandez qui sauvegarde quoi : données du client, fichiers, configuration, journaux, comptes et métadonnées. Vérifiez fréquence, rétention, isolation, régions, chiffrement, restauration unitaire ou complète et procédure en cas de suppression par un administrateur. Les réponses peuvent varier selon l’offre souscrite.

Distinguez la résilience du fournisseur de votre capacité de récupération. Un service peut répliquer son infrastructure sans fournir au client un retour à une version choisie. À l’inverse, un export client peut compléter la politique sans reconstruire seul tout le service.

Testez un export et une restauration pendant l’essai ou à intervalle défini. Vérifiez aussi la fermeture du compte : délai d’accès, restitution, effacement, conservation résiduelle et preuve disponible. Intégrez les limites au coût complet et au plan de sortie.

Concilier restauration, minimisation et suppression

Une sauvegarde n’autorise pas à conserver toute donnée indéfiniment. Définissez une rétention liée à la reprise, protégez l’accès et empêchez l’usage courant d’une copie ancienne. Lorsqu’une donnée a été rectifiée ou supprimée en production, elle ne doit pas réapparaître silencieusement après restauration.

Préparez un journal des changements postérieurs au point restauré ou une procédure de réapplication des suppressions et corrections. Cette procédure doit rester limitée : elle ne devient pas une seconde base opérationnelle contenant toutes les anciennes valeurs.

Testez aussi l’effacement des supports arrivés en fin de vie et la clôture des emplacements temporaires créés pendant une restauration. Les copies de test reçoivent une durée, des droits et une destruction vérifiée.

Attribuer les rôles et éviter le responsable unique

Le propriétaire métier définit les données et parcours essentiels. L’administrateur met en œuvre et surveille. Le responsable sécurité qualifie les protections selon l’organisation. Un contrôleur différent vérifie le résultat du test. Dans une petite structure, une personne peut cumuler des rôles, mais les décisions restent distinguées.

Prévoyez un relais autorisé pour l’absence ou le départ de l’administrateur principal. La récupération ne doit pas dépendre d’un téléphone personnel, d’une boîte inaccessible ou d’une connaissance non écrite. Testez la procédure de délégation sans partager un compte nominatif.

Les prestataires interviennent dans un périmètre contractuel et traçable. Leur présence ne retire pas à l’organisation la décision sur les priorités, la validation métier et les données acceptées comme restaurées.

Trois cas concrets

Cas 1 : un tableur partagé conserve l’unique planning. L’historique du service permet de revenir quelques jours, mais l’équipe ajoute un export versionné chiffré sur un support distinct et teste l’ouverture avec un autre poste. Elle documente aussi les décisions prises entre l’export et l’incident.

Cas 2 : une application SaaS réplique ses bases, mais le contrat ne permet pas au client de choisir un point de restauration. L’organisation conserve un export documenté de ses objets et fichiers, puis vérifie qu’elle sait relire les identifiants et relations. Cet export soutient la sortie ; il n’est pas présenté comme reconstruction complète du SaaS.

Cas 3 : après un rançongiciel, la copie de la veille pourrait contenir la compromission. L’équipe isole le système, préserve les éléments nécessaires à l’analyse, choisit une source saine, reconstruit les composants depuis des binaires officiels, restaure les données contrôlées et rapproche ensuite les opérations du mode dégradé.

Checklist d’une sauvegarde réellement exploitable

• Parcours essentiel, perte acceptable et durée de reprise décrits.
• Données, fichiers, configuration, identités et dépendances inventoriés.
• Synchronisation, export, réplication, archive et sauvegarde distingués.
• Fréquence, versions, rétention et exclusions justifiées.
• Copies réparties sur des modes d’échec différents.
• Au moins une copie hors ligne et une séparation géographique évaluées.
• Comptes, accès, clés et transmissions protégés.
• Exécutions surveillées avec destinataire des alertes.
• Procédure de restauration écrite avant l’incident.
• Test borné réalisé jusqu’au parcours métier utilisable.
• Durée, écarts et prochaine correction consignés.
• Suppression, fin de vie et nettoyage des tests prévus.

Place de DOHM et limites

DOHM présente une méthode de conception et de vérification. Le site ne sauvegarde aucune donnée du lecteur, n’accède à aucun système, ne certifie aucun fournisseur et ne déclenche aucune restauration. Chaque application du portefeuille reste autonome et responsable de ses propres données, rôles et mécanismes de reprise.

La profondeur du dispositif dépend des risques, contrats, obligations, volumes et ressources. Un système critique ou compromis nécessite une expertise appropriée. Cette page ne fournit ni audit de cybersécurité, ni garantie de reprise, ni conseil juridique individuel.

Révision éditoriale : 20 septembre 2026. Les recommandations officielles ANSSI, CNIL, MonServiceSécurisé et SGDSN ont été contrôlées à cette date. Leur version courante et le contexte réel priment avant mise en œuvre.