Une sauvegarde est une copie de données stockée sur un support distinct de l’original, destinée à permettre une restauration en cas de perte. Cette définition paraît simple, mais elle masque un problème courant : beaucoup d’entreprises disposent de sauvegardes qu’elles n’ont jamais tenté de restaurer. Or, une copie qui ne se restaure pas n’est pas une sauvegarde, c’est un fichier inutile qui occupe de l’espace de stockage.
Restauration non testée : la fausse sécurité des sauvegardes dormantes
La plupart des guides sur la protection des données se concentrent sur la création de copies et sur la règle 3-2-1 (trois copies, deux supports différents, un hors site). Ces recommandations sont pertinentes, mais elles laissent de côté une étape critique : le test de restauration.
Lire également : L'authentification à double facteur devient la norme dans les entreprises
Un fichier de sauvegarde peut être corrompu, incomplet ou incompatible avec la version actuelle du système cible. Sans vérification régulière, ces défauts restent invisibles jusqu’au jour du sinistre. À ce moment, le temps joue contre l’entreprise, et découvrir que la copie est inexploitable aggrave la situation au lieu de la résoudre.
Tester une restauration signifie reconstituer un jeu de données dans un environnement contrôlé, vérifier l’intégrité des fichiers récupérés et mesurer le temps nécessaire à l’opération. Ce test révèle trois informations concrètes :
A lire également : Les ransomwares ciblent de plus en plus les petites entreprises françaises
- La copie contient bien toutes les données attendues, sans corruption ni fichier tronqué.
- Le délai de restauration correspond au temps d’interruption que l’organisation peut tolérer.
- La procédure est documentée et reproductible par une autre personne que celle qui l’a configurée.
Un test de restauration trimestriel suffit à détecter la majorité des défauts avant qu’ils ne deviennent un problème opérationnel. Certaines structures automatisent ce contrôle, d’autres le planifient manuellement. L’approche importe moins que la régularité.
RPO et RTO : deux indicateurs pour calibrer la fréquence de sauvegarde
Appliquer une même fréquence de sauvegarde à l’ensemble du système d’information est une erreur fréquente. Toutes les données n’ont pas la même criticité, et toutes les interruptions n’ont pas le même coût. Deux indicateurs permettent de calibrer la stratégie.
Le RPO (Recovery Point Objective)
Le RPO désigne la quantité maximale de données qu’une entreprise accepte de perdre en cas de sinistre. Un RPO de quatre heures signifie que la dernière sauvegarde exploitable ne doit jamais dater de plus de quatre heures. Pour une base de données transactionnelle, un RPO court impose des sauvegardes très fréquentes, voire continues. Pour des archives documentaires peu modifiées, un RPO d’une journée peut convenir.
Le RTO (Recovery Time Objective)
Le RTO fixe le délai maximal acceptable entre le sinistre et la reprise des opérations. Un RTO court exige que les copies soient rapidement accessibles, sur un support performant et dans un format directement exploitable. Un stockage sur bande magnétique déportée offre une bonne protection physique, mais allonge le RTO par rapport à une restauration depuis un stockage cloud local.
Croiser RPO et RTO pour chaque catégorie de données permet de répartir les ressources de sauvegarde là où elles ont le plus d’impact, au lieu de tout sauvegarder au même rythme.
Sauvegardes des environnements SaaS et Microsoft 365 : un angle mort fréquent
Une croyance répandue veut que les données hébergées dans des services cloud comme Microsoft 365 soient automatiquement protégées par le fournisseur. La réalité est plus nuancée. Les plateformes SaaS assurent la disponibilité de l’infrastructure, pas la récupération granulaire de vos fichiers supprimés ou corrompus.
La rétention native de Microsoft 365, par exemple, propose des corbeilles et des périodes de conservation limitées dans le temps. Passé ce délai, un fichier supprimé par erreur ou par un acte malveillant devient irrécupérable sans sauvegarde tierce. La même logique s’applique à la plupart des applications cloud professionnelles.
Mettre en place une solution de sauvegarde dédiée pour les environnements SaaS ajoute une couche de protection indépendante du fournisseur. Cette copie externe permet de restaurer des éléments précis (un courriel, un document, un dossier partagé) sans dépendre des politiques de rétention de la plateforme.
Gouvernance des sauvegardes : passer de la copie automatique à la gestion opérationnelle
Configurer une tâche de sauvegarde automatique ne suffit pas à garantir la protection des données dans la durée. Plusieurs sources récentes insistent sur la nécessité de structurer la gouvernance autour de responsabilités claires.
- Désigner un responsable identifié qui surveille les rapports de sauvegarde et traite les échecs signalés.
- Documenter chaque procédure de restauration pour qu’elle soit exécutable par une personne qui n’a pas configuré le système.
- Contrôler les accès aux copies de sauvegarde afin d’éviter qu’un ransomware ou une erreur humaine ne les compromette en même temps que les données de production.
- Journaliser les restaurations effectuées, y compris les tests, pour disposer d’un historique vérifiable.
Cette approche transforme la sauvegarde en processus de gestion opérationnelle des risques plutôt qu’en simple réflexe technique. La différence se mesure le jour où un incident survient : une organisation qui gouverne ses sauvegardes connaît son RTO réel, sait qui intervient et dispose d’une procédure rodée.
Le maillon le plus fragile d’une stratégie de sauvegarde n’est généralement pas le support de stockage ni le logiciel utilisé. C’est l’absence de vérification. Une sauvegarde régulière, testée et documentée reste la protection la plus fiable contre la perte de données critiques.
