Une sauvegarde locale vaut mieux que l’absence de sauvegarde, mais elle ne constitue pas un plan de reprise complet. Si la sauvegarde se trouve sur le même serveur, la même baie de stockage, le même réseau ou dans les mêmes locaux que le système de production, le même incident peut toucher les données actives et leur copie de récupération.
Cela est particulièrement important lorsqu’un ransomware chiffre les fichiers accessibles, lorsqu’un disque tombe soudainement en panne, ou lorsqu’un incendie, une inondation, un vol, un incident électrique ou une erreur d’opérateur met un site entier hors service. L’entreprise peut toujours avoir techniquement une sauvegarde, mais pas nécessairement une sauvegarde utilisable.
Pour une agence ou une petite entreprise, il ne s’agit pas seulement d’un désagrément informatique. Une reprise échouée peut interrompre les e-mails, la comptabilité, les portails clients, la livraison des projets, les fichiers internes et les applications métier. Les clients peuvent subir des retards ou des services indisponibles avant même que l’entreprise ait identifié la cause.
Pourquoi une sauvegarde locale peut échouer avec le serveur principal
Une sauvegarde locale désigne généralement une copie stockée à proximité du système qu’elle protège. Il peut s’agir d’un second disque dans le même serveur, d’un lecteur de sauvegarde connecté au réseau, d’un NAS installé dans les bureaux ou d’une autre machine située dans la même salle serveur. Ces configurations peuvent faciliter les restaurations courantes et rapides. Elles n’offrent pas automatiquement une séparation face à un incident grave.
Les ransomwares peuvent atteindre davantage que les données de production
Les opérateurs de ransomwares ne s’arrêtent pas toujours au chiffrement du serveur principal. Après avoir obtenu des identifiants administrateur ou s’être déplacés sur le réseau, ils peuvent rechercher les partages de sauvegarde, les stockages connectés, les consoles de gestion et les anciens points de restauration. Si une sauvegarde locale est continuellement accessible avec les mêmes identifiants, elle peut être chiffrée, supprimée ou volontairement corrompue.
Certaines attaques ciblent également les logiciels de sauvegarde et leur configuration. L’objectif est clair : supprimer la capacité de restauration de l’organisation, puis accroître la pression pour payer. Une seconde copie qui est en ligne, accessible en écriture et visible depuis l’environnement compromis peut ne pas offrir une protection significative contre les ransomwares.
La suppression est aussi grave que le chiffrement. Un attaquant peut supprimer les points de restauration, vider les zones de récupération, désactiver les tâches planifiées ou modifier les paramètres de rétention. Un employé qui tente de contenir un incident peut également supprimer les mauvais fichiers ou déconnecter le stockage au mauvais moment. Une sauvegarde doit être protégée contre les modifications malveillantes comme accidentelles.
Les pannes matérielles et de disques ne respectent pas les calendriers de sauvegarde
Les disques durs, les SSD, les contrôleurs RAID, les blocs d’alimentation et les cartes mères des serveurs peuvent tomber en panne. Le RAID peut maintenir un serveur en fonctionnement après la défaillance d’un disque, mais le RAID n’est pas une sauvegarde : il réplique ou répartit les données sur le même système au lieu de créer une copie de récupération indépendante.
Un disque de sauvegarde local peut également tomber en panne, en particulier s’il fonctionne en continu dans le même environnement ou s’il n’a pas été surveillé et testé. Si le serveur et son stockage de sauvegarde partagent un contrôleur, une alimentation, une salle ou un système de refroidissement, une seule panne peut affecter les deux. Une tâche de sauvegarde qui signale une réussite peut malgré tout contenir des fichiers illisibles ou un état applicatif incomplet si les restaurations ne sont pas vérifiées.
Les incidents touchant les locaux suppriment toutes les copies proches
Le risque ne se limite pas aux cyberattaques. Un vol peut emporter les serveurs et les lecteurs de sauvegarde en même temps. Un incendie peut détruire un bureau ou une salle de centre de données. Une inondation peut endommager les équipements de plusieurs étages ou d’un bâtiment entier. Un incident électrique peut mettre hors service la production et le stockage local, tandis qu’une surtension peut endommager les deux.
Même si un périphérique de sauvegarde local survit, l’entreprise peut ne pas être en mesure d’y accéder. Le bâtiment peut être fermé, le réseau indisponible ou les personnes qui savent utiliser le système peuvent être elles-mêmes mobilisées par l’incident. La proximité physique est utile pour certaines restaurations rapides, mais elle devient une faiblesse lorsque la copie de récupération ne bénéficie d’aucune séparation géographique ou logique.
Les erreurs d’opérateur représentent un risque pour la récupération
Les erreurs humaines sont des causes fréquentes de perte de données : un répertoire est supprimé, une machine virtuelle est écrasée, une politique de rétention est modifiée, ou une tâche de sauvegarde est désactivée pendant une maintenance puis jamais réactivée. Les systèmes locaux permettent souvent à un administrateur disposant de larges autorisations de modifier à la fois les données de production et leur sauvegarde.
Une architecture récupérable part du principe que les utilisateurs commettront occasionnellement des erreurs. Elle utilise des contrôles d’accès distincts, une rétention protégée, des procédures claires et des tests de restauration, plutôt que de compter sur la mémoire d’un seul administrateur qui devrait se rappeler chaque étape sous pression.
Sauvegarde locale, sauvegarde hors site et reprise 3-2-1
Ces notions sont liées, mais elles ne sont pas interchangeables. Une entreprise peut disposer de plusieurs copies et conserver un plan de reprise fragile si toutes les copies dépendent du même serveur, du même compte, du même emplacement ou de la même alimentation électrique.
Sauvegarde locale
Une sauvegarde locale est stockée sur le même site ou la même infrastructure que le serveur protégé. Son principal avantage est la rapidité. Si un fichier est supprimé et que le serveur reste sain, une restauration depuis un stockage proche peut être plus rapide que la récupération des données par une connexion réseau vers un autre site.
Ses limites sont tout aussi concrètes :
- Elle peut être accessible à un ransomware utilisant des identifiants compromis.
- Elle peut être détruite ou volée avec le serveur principal.
- Elle peut dépendre de la même électricité, du même réseau, du même administrateur ou du même matériel.
- Elle peut donner un faux sentiment de sécurité si aucune restauration n’a été testée.
La sauvegarde locale peut constituer une couche utile, notamment pour les restaurations opérationnelles rapides. Elle ne doit pas être la seule couche. Une comparaison plus large des limites des sauvegardes locales et des risques liés à la reprise hors site met en évidence le point essentiel : une copie proche n’est pas automatiquement une copie indépendante.
Sauvegarde hors site
Une sauvegarde hors site est stockée à l’écart de l’environnement de production. La séparation peut être physique, logique ou les deux. Si le serveur du bureau est compromis, les données de récupération ne doivent pas être exposées par le même chemin d’accès habituel. Si les locaux sont endommagés, l’entreprise doit toujours pouvoir accéder à son dépôt de sauvegarde depuis un autre emplacement.
La protection hors site est la plus efficace lorsqu’elle comprend le chiffrement, un accès contrôlé, une rétention qui ne peut pas être réécrite facilement et un processus de récupération qui a été mis en pratique. L’emplacement ne suffit pas. Une copie stockée dans un autre bâtiment mais connectée avec des identifiants sans restriction peut rester vulnérable à une attaque réseau.
Une approche 3-2-1 réellement récupérable
Le principe 3-2-1 constitue une bonne base :
- 3 copies : conservez les données de production et au moins deux copies supplémentaires.
- 2 types de stockage ou d’environnements : évitez de placer toutes les copies sur le même type de système ou le même chemin d’accès.
- 1 copie hors site : assurez-vous qu’un incident touchant un site ne puisse pas supprimer toutes les options de récupération.
Pour renforcer la résistance aux ransomwares, ce modèle doit être plus détaillé. Au moins une copie de récupération doit être isolée des accès en écriture courants et protégée contre toute modification pendant sa période de rétention. C’est là que l’immuabilité prend tout son sens. Une sauvegarde immuable ne peut pas être modifiée ou supprimée dans le cadre des opérations normales pendant la période de rétention définie, ce qui réduit le risque qu’un attaquant ou un administrateur pressé efface l’historique de récupération.
L’immuabilité ne remplace ni le contrôle d’accès, ni le chiffrement, ni la supervision, ni les tests. Elle constitue un contrôle parmi d’autres dans une architecture de reprise. L’organisation doit également savoir comment s’authentifier, demander une récupération, obtenir les clés nécessaires et reconstruire les services qui dépendent des données.
Le chiffrement et la gestion des clés déterminent si la récupération est possible
Les données de sauvegarde peuvent contenir des dossiers clients, des factures, des contrats, des identifiants, des fichiers sources, des exportations d’e-mails et des informations personnelles. Les stocker hors site sans chiffrement crée un risque de confidentialité. Le chiffrement protège les données si les supports de stockage ou les canaux d’accès sont exposés.
Mais le chiffrement introduit une responsabilité concrète : quelqu’un doit contrôler la clé. Si un fournisseur détient la seule clé utilisable, le client peut avoir moins de contrôle indépendant sur l’accès à ses propres données de récupération. Si la clé est perdue, les données sauvegardées peuvent devenir définitivement illisibles même si le stockage est intact.
Avec Safenix, les sauvegardes sont chiffrées à l’aide d’une clé que Safenix ne détient jamais. Cette conception laisse la gestion de la clé au client au lieu de faire du fournisseur la seule autorité capable de déchiffrer les données. La clé doit donc être protégée, documentée et mise à la disposition des personnes autorisées lorsqu’une restauration est nécessaire. Une entreprise doit définir qui y a accès, où sont conservées les informations d’urgence relatives à la clé et comment l’accès est transmis si l’administrateur habituel n’est pas disponible.
La planification de la récupération doit répondre à ces questions avant un incident :
- Qui est autorisé à demander une restauration ?
- Qui peut accéder à la clé de chiffrement ?
- Comment les demandes sont-elles vérifiées pendant une crise ?
- Que se passe-t-il si l’administrateur principal est malade, injoignable ou touché par le même incident ?
- Les données restaurées peuvent-elles être utilisées par l’application ou nécessitent-elles une configuration et des identifiants supplémentaires ?
Une bonne gestion des clés équilibre sécurité et disponibilité. Conserver une clé sur le même serveur que la sauvegarde chiffrée annule l’objectif de séparation. La conserver dans la mémoire d’une seule personne crée un autre point de défaillance unique.
La rétention, le RPO et le RTO transforment la sauvegarde en plan de reprise
La rétention détermine jusqu’à quelle date vous pouvez revenir
La rétention est la période pendant laquelle les points de récupération sont conservés. Une courte fenêtre de rétention peut suffire pour une suppression accidentelle, mais être inutile si un ransomware reste indétecté pendant plusieurs semaines. Une période plus longue donne à l’organisation davantage de possibilités de trouver un point de restauration sain, notamment lorsqu’un attaquant a discrètement modifié des fichiers avant de déclencher le chiffrement.
La rétention doit refléter l’activité de l’entreprise. Une agence peut avoir besoin d’anciens fichiers de projets, de données de facturation et de livrables clients. Un petit commerce ou une société de services professionnels peut devoir conserver des documents financiers et réglementaires bien plus longtemps que les instantanés opérationnels quotidiens. L’essentiel est de prendre une décision délibérée plutôt que d’accepter une valeur par défaut qui n’a jamais été réévaluée.
Le RPO définit la perte de données acceptable
Le RPO, ou objectif de point de récupération, correspond à la durée maximale de données récentes que l’entreprise accepte de perdre. Si les sauvegardes sont exécutées une fois par jour, une panne de serveur peut entraîner la perte de presque une journée de travail. Si l’entreprise ne peut tolérer qu’une heure de perte, le calendrier de sauvegarde et la capacité réseau doivent permettre une protection plus fréquente.
Le RPO n’est pas seulement un paramètre technique. Il a un coût. Des sauvegardes plus fréquentes utilisent davantage de stockage, de bande passante et de temps de traitement. La cible appropriée dépend de la valeur et du rythme de modification des données, ainsi que des conséquences de leur reconstitution manuelle.
Le RTO définit la durée d’interruption acceptable
Le RTO, ou objectif de temps de reprise, indique dans quel délai un service doit être de nouveau disponible après un incident. Restaurer quelques fichiers et reconstruire un serveur entier sont deux tâches différentes. Un RTO doit prendre en compte le transfert des données, le déchiffrement, l’installation du système d’exploitation, l’installation des applications, l’activation des licences, les changements DNS, les accès utilisateurs et la validation.
Une entreprise qui promet un rétablissement rapide du service doit comprendre ses dépendances. Le serveur peut dépendre d’une base de données, d’un service d’annuaire, d’un relais e-mail, d’une règle de pare-feu, d’une licence logicielle, d’une API externe ou d’une configuration spécialisée qui ne figure pas dans les données de sauvegarde. Une sauvegarde peut restaurer parfaitement les fichiers tout en laissant l’application indisponible.
Les tests de restauration font la différence entre une copie et une capacité de récupération
La réussite d’une tâche de sauvegarde prouve seulement qu’un processus s’est achevé conformément au logiciel utilisé. Elle ne prouve pas que les fichiers nécessaires sont présents, que la sauvegarde est cohérente ou que l’entreprise peut fonctionner après la restauration.
Les tests de restauration doivent être planifiés à différents niveaux :
- Récupération de fichiers : restaurez des documents individuels, des boîtes e-mail ou des répertoires de projets.
- Récupération du système : restaurez un serveur complet ou une machine virtuelle sur une infrastructure adaptée.
- Récupération applicative : vérifiez que les bases de données, les services, les autorisations et la configuration fonctionnent ensemble.
- Validation métier : demandez aux utilisateurs d’effectuer des tâches réalistes et vérifiez que les données sont complètes.
Les tests doivent consigner la durée de chaque étape, les identifiants nécessaires et les étapes qui dépendent d’une personne précise. La procédure doit être mise à jour après les modifications de serveur, les mises à niveau logicielles, les refontes du réseau et les changements de responsabilités au sein du personnel.
Les sauvegardes hors site protégées, avec chiffrement, récupération après ransomware, rétention et tests de restauration, peuvent être évaluées dans le cadre d’un service de sauvegarde et de récupération Safenix plus global. La question pertinente n’est pas simplement de savoir quelle quantité de stockage est incluse. Il faut déterminer si l’architecture réduit le nombre de décisions qu’une petite équipe doit prendre pendant un événement perturbateur, tout en préservant le contrôle du client sur les données protégées.
Comment une agence ou une petite entreprise peut continuer à fonctionner
Lorsque le serveur principal est indisponible, la récupération doit commencer par une hiérarchisation plutôt que par la panique. Identifiez les services qui permettent à l’entreprise de poursuivre son activité et ceux qui peuvent attendre. Un ordre pratique peut être le suivant :
- Confirmer l’incident et isoler les systèmes touchés sans détruire les éléments de preuve ni les options de récupération.
- Choisir un point de récupération sain en fonction du RPO et du moment probable de la compromission.
- Restaurer le serveur ou l’application les plus importants dans un environnement contrôlé.
- Vérifier les données, les accès utilisateurs et les flux de travail critiques avant de reconnecter largement le service.
- Fournir au personnel et aux clients une procédure temporaire claire.
Les opérations temporaires peuvent s’appuyer sur un accès en lecture seule aux informations essentielles, des canaux de communication alternatifs, un suivi manuel des commandes ou des tickets, ou une offre de services réduite. Le plan doit préciser qui communique avec les clients, qui approuve les solutions de contournement et comment les nouvelles transactions sont rapprochées après le retour des systèmes.
Pour une agence, cela peut signifier donner la priorité aux fichiers de projets, aux communications clients, au suivi du temps et à la facturation. Pour une petite entreprise, il peut s’agir de restaurer les commandes, les données de stock, les rendez-vous, les systèmes financiers ou le support client. L’objectif n’est pas toujours de restaurer tous les serveurs en même temps. Il consiste à rétablir en priorité les services qui réduisent l’impact sur les clients et protègent la trésorerie.
Les dépendances liées à la récupération doivent être documentées séparément de la sauvegarde elle-même. Conservez un inventaire des rôles des serveurs, des informations réseau, des responsables des applications, des licences, des enregistrements DNS, des contacts essentiels et des modalités de gestion des clés. Ne supposez pas que la personne qui a configuré le serveur sera disponible lors d’un incendie, d’une attaque par ransomware ou d’une maladie soudaine.
Le coût d’une dépendance exclusive à la sauvegarde locale
Une stratégie reposant uniquement sur le local semble peu coûteuse, car elle peut utiliser des disques et du matériel existants. Le coût caché apparaît lors d’une panne. Le personnel peut passer des jours à déterminer ce qui a survécu, à trouver une copie saine, à reconstruire les systèmes et à recréer les informations manquantes. Le matériel d’urgence, l’assistance spécialisée, les heures supplémentaires et les ventes perdues peuvent rapidement dépasser le coût d’une protection hors site adaptée.
Les temps d’arrêt affectent également la confiance. Les clients peuvent manquer des échéances, perdre l’accès à des livrables ou se demander si leurs informations confidentielles ont été protégées. L’entreprise peut devoir expliquer l’incident, enquêter sur une éventuelle exposition, prévenir les parties concernées et négocier des délais supplémentaires. Même lorsque les données sont finalement récupérées, l’impact opérationnel et réputationnel peut subsister.
La sauvegarde de serveurs hors site ne garantit pas que chaque incident se déroulera sans difficulté. Elle permet de réduire le nombre d’événements qui se transforment en perte définitive de données et d’offrir à l’entreprise une voie clairement définie vers la reprise du service. Sa valeur vient de la combinaison de la séparation, du chiffrement, de la gestion des clés sous le contrôle du client, de la rétention immuable, d’objectifs RPO et RTO adaptés et de tests de restauration réguliers.
Construisez votre résilience autour des serveurs que vous contrôlez
Safenix s’adresse aux entreprises qui protègent des serveurs sous leur contrôle, qu’ils prennent en charge une agence, un petit bureau ou une application destinée aux clients. Le périmètre est important : il ne s’agit pas de sauvegarder un site web hébergé sur une offre mutualisée, lorsque le client ne contrôle ni le serveur sous-jacent ni le processus de sauvegarde. Un site en hébergement mutualisé doit être évalué au regard des propres dispositifs de sauvegarde et de récupération de l’hébergeur.
Pour un serveur contrôlé, commencez par cartographier les données et les services qui en dépendent. Identifiez ensuite ce qu’une sauvegarde locale peut couvrir, ce qui doit être stocké hors site, combien de temps les points de récupération doivent rester immuables, qui contrôle la clé de chiffrement et comment une restauration sera testée. Documentez les premières heures d’une interruption avec autant de soin que le calendrier de sauvegarde lui-même.
Une copie locale peut vous aider à récupérer rapidement après une petite erreur. Une copie hors site isolée, chiffrée et immuable vous donne de meilleures chances de récupérer lorsque le problème vient du serveur, du réseau, des locaux ou d’un attaquant. Cette distinction constitue le fondement d’une protection pratique contre les ransomwares et d’une reprise après sinistre efficace.