Sauvegarde hors site : pourquoi elle est essentielle à toute stratégie de reprise après sinistre

Une sauvegarde n’est utile que si elle reste disponible lorsque le système d’origine ne peut plus être utilisé. Ce principe simple explique pourquoi la sauvegarde hors site doit faire partie de toute stratégie sérieuse de reprise après sinistre. Une seconde copie sur le même serveur, NAS ou rack peut aider en cas de suppression accidentelle, mais elle offre peu de protection lorsqu’un incendie, un vol, une inondation, un rançongiciel ou une compromission administrative touche l’ensemble de l’environnement.

La sauvegarde hors site crée une distance physique et logique entre les données de production et leur copie de récupération. Pour une entreprise, cette séparation peut faire la différence entre restaurer un serveur en quelques heures et le reconstruire à partir d’enregistrements incomplets sur plusieurs jours. Elle change également la manière dont une entreprise envisage sa stratégie de sauvegarde : non plus comme une simple tâche de copie de fichiers, mais comme un contrôle opérationnel qui soutient la continuité d’activité.

Cela concerne particulièrement les agences et les petites entreprises qui gèrent leurs propres serveurs web, applicatifs, de bases de données, de virtualisation ou destinés aux clients. Ces organisations ne disposent peut-être pas d’une grande équipe informatique, mais elles sont exposées aux mêmes modes de défaillance que les grandes entreprises. Si un serveur de production est sous le contrôle du client, ses sauvegardes doivent être protégées avec le même soin que le serveur lui-même.

Ce que signifie réellement la sauvegarde hors site

La sauvegarde hors site est une copie des données de l’entreprise stockée dans un emplacement physique différent de celui du système protégé. Cette copie peut se trouver dans un autre bâtiment, un autre centre de données ou un environnement de stockage dédié situé dans une autre région. L’important n’est pas simplement la distance mesurée en kilomètres. La sauvegarde doit être séparée de l’environnement de production afin qu’un même incident ne puisse pas facilement détruire, chiffrer ou supprimer les deux.

Un processus classique de sauvegarde serveur capture les données sélectionnées, l’état du système, les applications ou des images complètes de la machine selon une planification définie. La sauvegarde obtenue est transférée hors du site de production, généralement via une connexion chiffrée. Elle est ensuite conservée pendant une durée de rétention définie et rendue disponible pour la récupération lorsque cela est nécessaire.

Une bonne sauvegarde hors site possède plusieurs caractéristiques distinctes :

• Séparation géographique : la sauvegarde ne dépend pas des mêmes locaux, du même rack, de la même alimentation électrique ou du même stockage local que la production.
• Séparation des accès : les administrateurs ordinaires des serveurs ne peuvent pas automatiquement modifier ou supprimer toutes les copies de récupération.
• Confidentialité : les données sont chiffrées en transit et au repos, et le contrôle de la clé de déchiffrement est clairement défini.
• Rétention : les sauvegardes restent disponibles assez longtemps pour couvrir les erreurs opérationnelles, les découvertes tardives et les obligations réglementaires ou contractuelles.
• Récupérabilité : l’organisation sait comment récupérer les données et a vérifié que le système restauré est utilisable.

Ces caractéristiques sont liées, mais elles ne sont pas interchangeables. Une copie hors site qu’un administrateur peut supprimer avec les mêmes identifiants que ceux utilisés sur le serveur de production est géographiquement séparée, mais insuffisamment isolée. Une sauvegarde fortement chiffrée que personne ne peut déchiffrer est sécurisée dans un certain sens, mais inutile en cas de crise. Une longue durée de rétention ne compense pas une sauvegarde qui n’a jamais été restaurée et peut être incomplète.

Pourquoi une copie locale ne suffit pas

La sauvegarde locale reste utile. Elle peut fournir une voie de récupération rapide pour un fichier supprimé, une base de données endommagée ou un disque défaillant. Restaurer depuis un stockage situé dans le même bâtiment est souvent plus rapide que télécharger une image serveur volumineuse via une connexion Internet. Les copies locales peuvent donc constituer une couche importante d’une stratégie de sauvegarde plus large.

Le problème commence lorsque la copie locale est considérée comme l’intégralité du plan de reprise après sinistre. Les systèmes de production et les sauvegardes locales partagent souvent les mêmes risques :

Panne matérielle

Les disques tombent en panne, les baies RAID se dégradent et les appliances de sauvegarde peuvent présenter des défauts. Si les données de production et de sauvegarde reposent sur le même sous-système de stockage, un seul incident matériel peut affecter les deux. Même lorsque la sauvegarde se trouve sur un appareil local distinct, un problème électrique ou environnemental peut endommager le serveur de production et l’appareil qui contient ses données de récupération.

Vol et perte physique

Un serveur et son appliance de sauvegarde locale sont des cibles attractives lors d’un cambriolage. Les disques amovibles sont particulièrement faciles à emporter, et un attaquant n’a pas besoin de comprendre les données si le matériel peut être revendu ou retenu contre rançon. La perte physique soulève également des problèmes de confidentialité lorsque les sauvegardes ne sont pas correctement chiffrées.

Incendie, inondation et autres incidents touchant tout le site

Un incendie, une canalisation rompue, une violente tempête ou l’évacuation d’un bâtiment peuvent rendre indisponibles tous les appareils d’une salle serveur en même temps. Une sauvegarde locale peut être parfaitement saine tout en restant inaccessible lorsque les locaux ne peuvent pas être visités. La reprise après sinistre part du principe que le site principal lui-même peut être indisponible, et pas seulement qu’un disque est défaillant.

Rançongiciels et logiciels malveillants destructeurs

Les rançongiciels ciblent fréquemment les stockages attachés, les lecteurs réseau et les interfaces de gestion des sauvegardes. Si une sauvegarde locale est toujours montée et accessible avec un compte administrateur compromis, le logiciel malveillant peut la chiffrer ou la supprimer en même temps que les données de production. Une sauvegarde qui n’existe que comme une autre destination accessible en écriture dans le même environnement ne constitue pas une dernière ligne de défense fiable.

Administrateurs compromis et identifiants volés

Tous les incidents destructeurs ne commencent pas par un logiciel malveillant. Un mot de passe privilégié volé, un compte utilisé abusivement ou une commande accidentelle peut supprimer les données de production et leurs copies locales. Les sauvegardes doivent être protégées contre les mêmes identifiants et relations de confiance que ceux qui régissent les systèmes qu’elles protègent. Sinon, un attaquant qui contrôle le serveur peut également contrôler les options de récupération.

Lorsque l’on compare la sauvegarde locale et la sauvegarde hors site dans une stratégie de reprise après sinistre, la question pratique n’est pas de savoir si la sauvegarde locale est utile. Il faut déterminer si l’organisation possède au moins une copie qui reste hors de portée d’un incident touchant tout le site et d’un environnement de production compromis.

Comparaison des copies locales, hors site et dans le cloud

Les termes locale, hors site et dans le cloud décrivent différents aspects d’une conception de sauvegarde. Ils ne doivent pas être considérés comme des catégories mutuellement exclusives, et le simple fait d’utiliser le cloud ne prouve pas qu’une sauvegarde est isolée ou récupérable.

Sauvegarde locale

La sauvegarde locale est stockée à proximité du serveur protégé, par exemple sur un second disque, un NAS, un lecteur amovible ou une appliance de sauvegarde située dans les mêmes locaux. Son principal avantage est la rapidité. Une restauration locale peut être pratique lorsque l’entreprise a rapidement besoin d’un seul fichier ou d’une copie récente d’une base de données.

Ses faiblesses sont son exposition et sa dépendance. Les copies locales peuvent être affectées par un incendie, un vol, une inondation, des problèmes électriques, un rançongiciel ou une compromission d’administrateur. Elles peuvent également être oubliées lors d’un déménagement ou d’une mise à niveau matérielle. La sauvegarde locale doit être considérée comme une couche de récupération rapide, et non comme l’unique mécanisme de reprise après sinistre.

Sauvegarde hors site

La sauvegarde hors site est stockée à l’écart du site de production et doit être protégée par des contrôles d’accès distincts. Elle est conçue pour les scénarios dans lesquels l’environnement local ne peut pas être considéré comme fiable ou ne peut pas être atteint. Un service hors site bien conçu peut également fournir aux petites organisations une méthode structurée pour gérer la rétention, le chiffrement et les procédures de récupération sans construire leur propre deuxième site.

La sauvegarde hors site peut être restaurée plus lentement qu’une copie locale, selon la bande passante disponible, le volume de données et la méthode de récupération. Ce compromis est acceptable lorsque l’alternative consiste à ne disposer d’aucune copie utilisable après un incident touchant tout le site. Le service doit être choisi en fonction du délai de récupération requis, et non évalué uniquement selon l’emplacement du stockage.

Sauvegarde dans le cloud

Une sauvegarde dans le cloud signifie que les données de sauvegarde sont stockées sur une infrastructure accessible via un réseau, souvent dans un centre de données exploité par un fournisseur. Elle peut être hors site, mais les deux termes ne sont pas identiques. Une sauvegarde cloud peut rester mal isolée si les identifiants de production permettent de la supprimer, si sa rétention peut être modifiée sans protection ou si toutes les copies se trouvent dans le même domaine de défaillance.

Lors de l’évaluation d’un service de sauvegarde cloud ou hébergé, demandez où les données sont stockées, qui peut y accéder, comment les clés de chiffrement sont gérées, si les sauvegardes sont immuables et comment la récupération est effectuée. Le cloud est un modèle de fourniture, pas une spécification de sécurité complète.

Comment l’approche 3-2-1 soutient la reprise après sinistre

L’approche 3-2-1 reste une base utile pour une stratégie de sauvegarde :

• 3 copies des données : la copie de production plus au moins deux copies de sauvegarde.
• 2 types de stockage ou supports différents : afin de réduire la dépendance à une seule technologie ou à un seul mode de défaillance.
• 1 copie hors site : pour se protéger contre la perte de l’emplacement principal.

Ce modèle est volontairement simple. Il encourage les organisations à éviter de placer toutes les copies sur le même serveur, la même baie de disques ou dans les mêmes locaux. Il laisse également la place à des contrôles plus avancés, tels que le stockage immuable, les copies hors ligne et des identités administratives distinctes.

Une interprétation moderne ajoute souvent un autre « 1 » : une copie doit être isolée ou immuable. L’immuabilité signifie que les données de sauvegarde ne peuvent pas être modifiées ou supprimées pendant une période de protection définie, même si un compte ou un serveur de production est compromis. Elle est particulièrement importante pour la résilience face aux rançongiciels et lors d’incidents où un attaquant tente d’effacer des preuves ou de supprimer des points de récupération.

L’immuabilité ne signifie pas que chaque sauvegarde est conservée indéfiniment. Elle s’applique généralement pendant la fenêtre de rétention configurée. Une fois cette période terminée, la sauvegarde peut expirer conformément à la politique. C’est pourquoi les paramètres de rétention doivent être définis avec soin et non laissés à une valeur par défaut choisie par commodité.

RPO et RTO : transformer les objectifs de récupération en décisions de sauvegarde

La fréquence des sauvegardes et la conception de la récupération doivent reposer sur les besoins de l’entreprise. Deux indicateurs aident à traduire ces besoins en décisions concrètes : l’objectif de point de récupération, ou RPO, et l’objectif de délai de récupération, ou RTO.

Objectif de point de récupération

Le RPO décrit la quantité de données récentes que l’entreprise peut se permettre de perdre après un incident. Un RPO de 24 heures peut signifier que l’organisation accepte de perdre une journée de transactions ou de mises à jour. Un RPO d’une heure nécessite une capture et un transfert plus fréquents. Un RPO mesuré en minutes peut exiger une architecture différente de celle de sauvegardes serveur planifiées classiques.

Le RPO n’est pas simplement un paramètre dans une console de sauvegarde. Il dépend de la fréquence d’exécution des sauvegardes, de la réussite des tâches, de la vitesse de transfert des données et de la cohérence des données sources. Une sauvegarde de base de données effectuée alors que des transactions sont encore enregistrées peut ne pas fournir un point de récupération propre si l’application n’est pas gérée correctement.

Objectif de délai de récupération

Le RTO décrit la rapidité avec laquelle un service doit être restauré après une interruption. Une petite application interne peut tolérer une journée d’indisponibilité. Une agence qui héberge des applications clientes ou une entreprise qui traite des commandes peut avoir besoin d’une fenêtre de récupération beaucoup plus courte.

Le RTO influence le type de sauvegarde et le processus de récupération. Restaurer une image complète du serveur peut être plus rapide que reconstruire un système d’exploitation et réinstaller chaque application, mais cela nécessite tout de même une infrastructure de destination adaptée. Un service soumis à un RTO exigeant peut nécessiter une capacité de remplacement planifiée à l’avance, une documentation des changements DNS ou réseau et une procédure testée pour rétablir les dépendances dans le bon ordre.

Les RPO et RTO doivent être attribués à chaque service, et non estimés pour l’organisation dans son ensemble. Une base de données, un site web, un serveur de fichiers et un système de supervision interne peuvent avoir des priorités différentes. La liste de ces priorités aide une petite entreprise à concentrer ses efforts là où les interruptions et les pertes de données causeraient les dommages les plus importants.

La rétention fait partie de la conception de la récupération

La rétention détermine jusqu’à quelle date une organisation peut revenir pour récupérer ses données. Elle doit prendre en compte davantage que l’intervalle entre deux sauvegardes. Les entreprises découvrent souvent une corruption de données, des modifications non autorisées ou une suppression accidentelle plusieurs jours ou semaines après l’événement initial. Si le système de sauvegarde ne conserve que les dernières copies, chaque point de récupération peut contenir le même problème.

Une politique de rétention raisonnable prend en compte :

• Le temps pendant lequel une suppression accidentelle peut passer inaperçue.
• La durée pendant laquelle un logiciel malveillant peut rester dormant avant sa détection.
• Les exigences contractuelles, réglementaires ou des clients.
• L’ancienneté des données nécessaires à une enquête financière, opérationnelle ou juridique.
• Le coût de stockage et de transfert lié à la conservation d’anciens points de récupération.
• La nécessité éventuelle de disposer de points de récupération quotidiens, hebdomadaires ou mensuels différents.

La rétention doit également correspondre à la nature du serveur. Un serveur de développement peut nécessiter des points de récupération conservés peu de temps, tandis qu’une base de données de production ou un référentiel de projets clients peut exiger un historique plus long. La politique doit être rédigée dans un langage clair afin que la personne chargée de la récupération comprenne ce que fournissent réellement « 30 jours » ou « 12 mois ».

L’immuabilité rend la fenêtre de rétention plus utile, car elle empêche la modification des points de récupération pendant la période où ils sont nécessaires. Elle ne supprime toutefois pas le besoin de supervision. Une tâche de sauvegarde peut se terminer correctement sur le plan technique tout en excluant un volume requis, en utilisant une planification incorrecte ou en produisant des données impossibles à restaurer.

Chiffrement et question du détenteur de la clé

Les données hors site doivent être protégées contre la divulgation non autorisée autant que contre la destruction. Le chiffrement contribue à empêcher qu’un disque volé, un transfert intercepté ou un emplacement de stockage consulté de manière inappropriée n’expose des informations commerciales ou clients.

Le chiffrement soulève deux questions distinctes. Premièrement, les données sont-elles chiffrées pendant leur transfert du serveur du client vers l’emplacement de sauvegarde ? Deuxièmement, sont-elles chiffrées pendant leur stockage ? Les deux aspects sont importants. Le chiffrement en transit ne protège pas une sauvegarde stockée lisible par des opérateurs non autorisés, et le chiffrement au repos ne protège pas les données envoyées via une connexion non sécurisée.

La propriété de la clé est tout aussi importante. Si le fournisseur détient l’unique clé de déchiffrement, le client peut avoir un contrôle limité sur la confidentialité. Si le client contrôle la clé et que le fournisseur ne la détient jamais, l’exposition est réduite, mais la responsabilité devient plus importante : le client doit protéger la clé et veiller à ce que le personnel autorisé à effectuer une récupération puisse l’utiliser lorsque cela est nécessaire.

Cela crée un équilibre pratique. Le contrôle de la clé peut renforcer la séparation entre le service de sauvegarde et les données protégées, mais une clé perdue peut rendre la récupération impossible. La gestion des clés doit donc être documentée, les accès doivent être restreints et une procédure de récupération doit expliquer comment l’équipe autorisée obtiendra et utilisera la clé en cas d’urgence. Le chiffrement ne remplace pas la planification opérationnelle.

Pourquoi l’immuabilité et l’isolation transforment la récupération après un rançongiciel

La récupération après une attaque par rançongiciel ne consiste pas seulement à disposer d’une copie récente. Il faut disposer d’une copie qu’un attaquant n’a pas pu chiffrer ou supprimer après avoir pris le contrôle de l’environnement de production.

L’isolation limite les chemins qu’un attaquant peut utiliser pour atteindre les données de sauvegarde. Parmi les mesures utiles figurent des identifiants distincts, un accès réseau restreint, des interfaces de gestion limitées et un stockage qui n’est pas continuellement accessible en écriture depuis le serveur protégé. Ces contrôles réduisent le risque qu’un compte administrateur compromis affecte toutes les couches du système de récupération.

L’immuabilité ajoute une règle qui empêche la modification des objets de sauvegarde pendant une période définie. Si un attaquant tente de supprimer des points de récupération récents, la politique de stockage peut les conserver jusqu’à l’expiration de la période de rétention. L’organisation dispose ainsi du temps nécessaire pour identifier l’incident, le contenir et sélectionner un point de récupération sain.

Aucun de ces contrôles ne garantit à lui seul une récupération réussie. Un attaquant peut compromettre la source avant la création de la sauvegarde, ou l’organisation peut découvrir que la sauvegarde excluait une application critique. Les tests de récupération sont donc indispensables. Une entreprise doit connaître les points de récupération disponibles, savoir comment y accéder, comment fournir la clé de chiffrement et comment valider le serveur restauré avant de le reconnecter à la production.

Ce que cela signifie pour les agences et les petites entreprises

Les agences et les petites entreprises gèrent souvent leur infrastructure avec des effectifs limités. Une seule personne peut s’occuper des projets clients, des mises à jour des serveurs, des accès utilisateurs, de la supervision et des alertes de sauvegarde. L’environnement technique peut inclure un panneau de contrôle d’hébergement, des machines virtuelles, des bases de données, des référentiels de code, des partages de fichiers et plusieurs services destinés aux clients.

Cette concentration des responsabilités crée des risques concrets. Une tâche de sauvegarde peut être configurée une fois puis oubliée. Les alertes peuvent être envoyées à une ancienne boîte aux lettres. Un ancien prestataire peut avoir conservé un accès. Un NAS local peut être plein. Une image serveur peut exister, mais personne ne sait peut-être si elle peut être restaurée sur un matériel de remplacement.

La sauvegarde hors site aide en séparant la copie de récupération de l’administration quotidienne du serveur. Elle ne supprime pas le besoin d’une gestion compétente, mais elle peut réduire le nombre de points uniques de défaillance. Elle fournit également à une agence une réponse plus crédible lorsqu’un client demande comment son application, sa base de données ou ses données de projet seraient récupérées après un incident grave.

Pour les entreprises qui exécutent des serveurs de production, la première étape consiste à identifier ce qui doit être restauré et dans quel ordre. Une application web peut dépendre d’une base de données, d’un stockage objet, d’enregistrements DNS, de secrets, de certificats et d’intégrations externes. Une sauvegarde qui ne restaure que les fichiers web ne restaurera peut-être pas le service. Le plan de récupération doit documenter ces dépendances et distinguer la récupération des données de la récupération complète du service.

Safenix est conçu pour les serveurs contrôlés par le client. Il fournit une sauvegarde hors site pour les serveurs professionnels, avec des données stockées en Allemagne, chiffrées à l’aide d’une clé que Safenix ne détient jamais, et immuables pendant toute la durée de la fenêtre de rétention configurée. Il ne s’agit pas d’un plan de sauvegarde pour un site web exécuté sur un hébergement mutualisé. Le client doit contrôler le serveur protégé ; un compte d’hébergement mutualisé n’offre pas le même niveau d’accès au serveur ni le même contrôle des sauvegardes.

Évaluer un service de sauvegarde hors site

Le bon service doit correspondre aux systèmes, aux objectifs de récupération et aux responsabilités de l’entreprise. Le prix compte, mais un faible coût de stockage n’est d’aucune utilité si la récupération n’est pas claire ou si le modèle d’accès du fournisseur compromet l’isolation.

Lors de l’évaluation des solutions de sauvegarde hors site pour les serveurs contrôlés par l’entreprise, de la rétention et des tests de récupération, demandez comment le service répond aux RPO et RTO requis, où les données sont stockées, qui contrôle les clés de chiffrement et comment la rétention immuable est appliquée. Vérifiez que le service est conçu pour les serveurs effectivement administrés par l’entreprise, plutôt que de supposer qu’un site en hébergement mutualisé peut être intégré de la même manière.

Courte liste de contrôle

• Périmètre : le service peut-il protéger les systèmes d’exploitation, applications, bases de données et volumes de données importants ?
• Emplacement : l’emplacement du stockage est-il clairement défini et offre-t-il une séparation réelle du site de production ?
• Chiffrement : les données sont-elles chiffrées en transit et au repos ? Qui crée, contrôle et protège la clé de déchiffrement ?
• Isolation : un administrateur du serveur compromis peut-il supprimer ou modifier toutes les sauvegardes ?
• Immuabilité : les points de récupération sont-ils immuables pendant toute la fenêtre de rétention configurée ?
• Rétention : la politique peut-elle couvrir les découvertes tardives, les exigences des clients et le RPO de l’organisation ?
• Récupération : comment les fichiers, bases de données et serveurs complets sont-ils restaurés, et quelle infrastructure est nécessaire ?
• Tests : l’entreprise peut-elle effectuer un test de restauration sans attendre un incident réel ?
• Exploitation : qui reçoit les alertes d’échec, les examine et agit lorsqu’une tâche de sauvegarde ne se termine pas ?
• Responsabilités : quelles tâches incombent au fournisseur et lesquelles restent à la charge du client ?

Planifier le premier test de récupération

Un premier test de récupération n’a pas besoin de prendre la forme d’un exercice spectaculaire de sinistre touchant tout le site. Il doit être contrôlé, documenté et représentatif d’un besoin réel de l’entreprise. L’objectif est de prouver que l’organisation peut transformer une sauvegarde en données utilisables ou en serveur fonctionnel.

1. Choisissez un scénario réaliste. Par exemple, sélectionnez la suppression accidentelle d’un dossier critique, la corruption d’une base de données ou la perte d’un serveur de production.
2. Définissez le résultat attendu. Indiquez le point de récupération qui sera utilisé, les données qui doivent être présentes et le délai dans lequel le test doit être terminé.
3. Vérifiez les accès et les clés. Assurez-vous que l’opérateur de récupération autorisé peut accéder au service de sauvegarde et dispose de la clé de chiffrement requise selon la procédure documentée.
4. Utilisez une destination isolée. Restaurez les données sur un serveur ou un environnement de test qui ne peut pas écraser la production ni exposer inutilement les données récupérées.
5. Validez davantage que la présence des fichiers. Vérifiez les permissions, la cohérence de la base de données, le démarrage de l’application, la configuration, les dépendances et des parcours utilisateurs représentatifs.
6. Mesurez le résultat. Notez le temps nécessaire pour localiser le point de récupération, transférer les données, terminer la restauration et rendre le service utilisable.
7. Documentez les problèmes et mettez le plan à jour. Corrigez les identifiants manquants, les instructions ambiguës, les restrictions réseau, le matériel incompatible ou les hypothèses irréalistes.

Après une restauration technique réussie, effectuez une vérification métier. Les bonnes personnes peuvent-elles accéder au système récupéré ? Les données clients sont-elles lisibles ? Les tâches planifiées, les intégrations et les certificats fonctionnent-ils ? Les données restaurées correspondent-elles au moment requis ? Un serveur qui démarre n’est pas nécessairement un service qui a été rétabli.

Intégrer la sauvegarde hors site à la continuité d’activité

La continuité d’activité dépend de bien plus que du stockage des données dans un autre emplacement. Elle exige une séquence de décisions approuvée pour poursuivre les opérations essentielles lorsque l’infrastructure habituelle est indisponible. La sauvegarde hors site fournit l’un des éléments fondamentaux : une copie de récupération séparée de l’événement qui affecte la production.

Le processus doit relier les paramètres techniques de sauvegarde aux priorités métier. Identifiez les services critiques, attribuez des RPO et RTO, définissez la rétention en fonction du risque de découverte tardive et documentez les personnes habilitées à autoriser une récupération. Ajoutez les coordonnées, l’inventaire des serveurs, les dépendances et l’emplacement des instructions relatives aux clés de chiffrement. Conservez la documentation accessible lorsque l’environnement principal est hors service.

Réexaminez le plan après les changements importants. Une nouvelle base de données, un volume de stockage plus important, la migration d’une application ou une modification d’un contrat client peut changer les besoins en durée de sauvegarde et en rétention. Les changements de personnel peuvent également modifier les personnes capables d’intervenir. Une stratégie de sauvegarde adaptée à l’entreprise il y a deux ans ne répond peut-être plus à sa charge actuelle.

La conception la plus solide combine généralement une récupération locale rapide avec une copie hors site isolée. Le stockage local peut gérer rapidement les incidents courants, tandis qu’une sauvegarde hors site immuable protège contre les événements auxquels le stockage local ne peut pas survivre. Des tests de restauration réguliers relient ensuite ces deux couches à un processus de récupération concret.

Une norme pratique pour la sauvegarde des serveurs

Pour un serveur contrôlé par une entreprise, une configuration fiable doit répondre clairement à cinq questions :

• Quelle quantité de données récentes l’entreprise peut-elle se permettre de perdre ?
• Dans quel délai chaque service important doit-il être rétabli ?
• Où la copie de récupération est-elle stockée et le même incident peut-il l’affecter ?
• Un administrateur compromis peut-il la modifier ou la détruire ?
• Quand le dernier test de restauration réussi a-t-il eu lieu et qu’a-t-il démontré ?

Si les réponses restent vagues, l’entreprise dispose peut-être de sauvegardes sans disposer d’une véritable reprise après sinistre. La sauvegarde hors site répond au problème de l’emplacement, mais l’isolation, le chiffrement, la rétention et les tests déterminent si la copie sera digne de confiance lorsque la pression sera maximale.

Pour les agences et les petites entreprises, ce niveau de préparation n’est pas excessif. Un seul serveur de production peut prendre en charge un portail client, une boutique en ligne, un processus interne ou une application génératrice de revenus. Le protéger signifie se préparer aux erreurs courantes comme aux sinistres rares. Une copie locale peut accélérer la récupération, mais une copie hors site, chiffrée et immuable fournit à l’entreprise une voie réaliste pour reprendre son activité lorsque l’environnement local a été compromis ou perdu.