Stratégie de sauvegarde : de la règle 3-2-1 à une restauration testée

Une copie seule ne rétablit pas un processus métier

Le lundi, un dossier de projet manque, mais la synchronisation a déjà propagé partout la suppression du week-end. Une autre entreprise conserve ses données, mais ne peut relancer sa gestion des stocks après une panne serveur, car le fichier de licence, la configuration de la base et l’accès administrateur manquent. Ces deux exemples montrent pourquoi une stratégie doit expliquer davantage que l’emplacement d’une copie.

Le résultat attendu est qu’un processus précis refonctionne avec un état des données acceptable dans un délai convenu. Une petite entreprise artisanale peut nécessiter une autre approche qu’un système de commandes actif en permanence. La planification économique commence par cette distinction.

Choisir la perte acceptable avant le calendrier de sauvegarde

Le Recovery Point Objective (RPO) limite dans le temps la perte de données acceptable. Un RPO de quatre heures exige un point récupérable vieux d’au plus quatre heures au moment de la panne. Le Recovery Time Objective (RTO) décrit le délai cible jusqu’à la reprise du service. Des sauvegardes nocturnes seules ne satisfont pas un RPO de quatre heures, et un téléchargement rapide ne prouve pas le respect du RTO.

L’équipe métier doit approuver ces objectifs. Ressaisir les commandes à partir des courriels peut compenser certaines données perdues, mais coûte toujours du temps de travail. L’attente de matériel, la disponibilité du prestataire et la validation métier finale font toutes partie de l’interruption réelle. Les exemples suivants illustrent la planification, sans être des recommandations universelles.

• Documents de projet : RPO de quatre heures, RTO d’un jour ouvré ; plusieurs points quotidiens et restauration ciblée de dossiers.
• Commandes en cours : RPO d’une heure, RTO de quatre heures ; protection de la base et environnement de récupération immédiatement disponible.
• Site public : RPO de 24 heures, RTO de huit heures ; protéger ensemble contenu, application, configuration et administration du domaine.

3-2-1 exige des copies réellement indépendantes

La règle classique signifie trois copies, production comprise, deux types de supports et une copie hors site. Examinez aussi les causes de défaillance communes. Deux répertoires sur un NAS ne constituent pas une protection indépendante. Un second compte cloud n’aide que si l’administrateur principal ne peut pas en modifier aussi la conservation et les données.

Une combinaison pratique comprend les données de production, une sauvegarde locale pour des restaurations rapides et une copie externe distincte contre la perte du site. Une copie hors ligne ou temporairement immuable limite davantage les modifications indésirables. RAID peut résister à certaines pannes de disques, mais ne fournit pas de versions historiques indépendantes.

L’immutabilité a des limites propres au produit. S3 Object Lock protège des versions d’objets précises pendant une durée définie, tandis que de nouvelles versions peuvent toujours être créées. Testez la conservation et alignez-la sur le budget de stockage et la procédure de récupération.

Fichiers, bases et services cloud nécessitent des méthodes différentes

Les documents nécessitent souvent une version passée précise. Une base de données exige la cohérence des modifications liées ; copier des fichiers ouverts à un instant arbitraire peut ne pas la garantir. Les sauvegardes conscientes de l’application coordonnent un point de récupération avec une application prise en charge. Vérifiez la prise en charge de la base concernée au lieu de supposer que la cohérence applicative est universelle.

Pour les services cloud, inventoriez comptes, permissions, conservation et exports. Corbeilles et historiques de versions peuvent aider, mais ne sont pas automatiquement des sauvegardes indépendantes. Déterminez si les données requises restent disponibles après la perte d’un compte ou l’expiration de l’historique. Un export n’est utile que si la destination peut l’importer.

Chiffrer tout le parcours de récupération

Incluez licences, croissance, copies externes, capacité de récupération, surveillance et temps d’exercice. Les fournisseurs peuvent facturer récupération, conservation minimale ou transfert. Une longue conservation ne réduit pas les coûts lorsque de grands volumes de nouvelles données arrivent chaque jour. Mesurez déduplication et compression avec les données réelles au lieu de supposer une réduction standard.

Ce calcul de bande passante est illustratif : transférer 1 To sur une connexion de 100 Mbit/s continuellement entièrement utilisable prend environ 22,2 heures en unités décimales, sans surcharge de protocole. Décompression, démarrage de la base et validation prennent du temps supplémentaire. Une récupération en quatre heures nécessite un chemin plus rapide ou des copies déjà proches de l’environnement de récupération.

Une proposition doit préciser les systèmes protégés et les exclusions, les copies, la conservation, les objectifs, un contact disponible, les accès documentés et la première restauration réussie chronométrée. Validez séparément la restauration d’éléments individuels et le redémarrage du service entier.

Effectuer un exercice au résultat vérifiable

Choisissez un processus complet mais gérable, comme la gestion des commandes. Restaurez un point choisi dans un environnement de test isolé et vérifiez connexion, recherche de commandes, récupération de documents et transaction de test sans conséquence. Empêchez les notifications ou commandes réelles d’atteindre les systèmes externes. Consignez le point de départ, les dépendances et le résultat attendu avant de commencer.

Mesurez plus que la copie : consignez le début de l’incident simulé, la disponibilité des identifiants, le démarrage de l’application, la fin des vérifications métier et l’horodatage des données récupérées. Comparez le temps et la perte réels aux RTO et RPO. Attribuez à chaque écart un responsable et une échéance au lieu d’ajuster le rapport pour paraître réussir. Retestez après des changements importants de base de données, de chiffrement ou d’hébergement.

Une alerte doit déclencher une action

Les tâches en échec ne sont qu’un signal parmi d’autres. Les sauvegardes absentes, les jeux de données inhabituellement petits, la croissance soutenue et les points de récupération plus anciens que la fenêtre convenue comptent aussi. Classez chaque alerte et transmettez-la à une personne capable d’agir pendant les horaires d’assistance contractuels.

Un système critique peut alerter quand le dernier point de récupération confirmé atteint un âge d’avertissement interne, laissant le temps d’enquêter et de vérifier d’autres copies avant de dépasser le RPO. Testez le canal de signalement et confirmez qu’un remplaçant reçoit les mêmes informations.

La passation fait partie de l’acceptation

Le plan de récupération doit rester accessible sans le serveur en panne ni le savoir d’une seule personne. Nommez les contacts, les produits et versions, l’ordre des dépendances et l’accès sécurisé aux clés et identifiants. Stockez les mots de passe dans un gestionnaire adapté avec accès d’urgence contrôlé, pas à découvert dans un manuel général.

Une seconde personne doit effectuer une restauration délimitée uniquement à partir de la documentation. Consignez les lacunes de connaissance. La fréquence des exercices suit le rythme des changements et la criticité : une revue annuelle documentée peut être un point de départ, tandis que des systèmes centraux fréquemment modifiés ou des objectifs manqués exigent des vérifications plus rapprochées.