La sauvegarde informatique est un pilier central de la résilience. En cas d’incident, il est vital de disposer d’une copie intègre, accessible et exploitable pour restaurer les données et reprendre l’activité dans des délais acceptables. Pour atteindre cet objectif, et répondre le cas échéant à des exigences réglementaires ou contractuelles, la stratégie de sauvegarde 3-2-1 constitue un socle éprouvé.
Une sauvegarde unique est un risque opérationnel
Une sauvegarde unique constitue un risque opérationnel direct. Une panne matérielle, une erreur de manipulation, une suppression accidentelle, une corruption logique ou un ransomware peuvent alors entraîner une perte totale ou durable d’information.
Sans sauvegarde exploitable, l’organisation peut subir :
- une interruption prolongée de ses activités ;
- une perte définitive de données critiques ;
- une désorganisation des équipes et des processus ;
- des retards de production ou de service ;
- un impact financier important ;
- une dégradation de la confiance des clients, partenaires ou autorités.
Une sauvegarde unique est souvent exposée au même risque que le reste du système d’information : environnement partagé, droits d’administration identiques, surface d’attaque similaire. Elle peut donc, elle aussi, être supprimée, chiffrée ou altérée en même temps que les données qu’elle est censée protéger.
La stratégie 3-2-1 : un socle de résilience
Pour réduire ce risque, la stratégie de sauvegarde 3-2-1 reste une référence simple et efficace.
3 copies des données
Le principe est de conserver les données de production ainsi qu’au moins deux copies de sauvegarde. L’objectif est d’éviter qu’un incident unique entraîne une perte définitive d’information.
Exemple opérationnel : une entreprise conserve ses données sur son serveur de production, réalise une sauvegarde quotidienne sur une appliance dédiée et réplique en plus une copie sur un stockage externalisé.
2 supports ou environnements différents
Les sauvegardes ne doivent pas toutes reposer sur la même technologie, le même équipement ou le même environnement logique. En diversifiant les supports ou les environnements, l’organisation limite le risque de défaillance commune.
Exemple opérationnel : une première sauvegarde est stockée sur un NAS interne dédié, tandis qu’une seconde est envoyée vers un coffre-fort numérique ou une infrastructure cloud distincte.
1 copie hors ligne ou hors site
Une copie doit être isolée du système principal, soit parce qu’elle est hors ligne, soit parce qu’elle est stockée sur un site ou un environnement séparé. Cette précaution permet de conserver un point de restauration même si le système de production est compromis.
Exemple opérationnel : une sauvegarde hebdomadaire est exportée sur un support déconnecté après écriture, ou stockée dans un environnement externalisé non accessible avec les comptes d’administration habituels.
La règle 3-2-1 ne garantit pas à elle seule la reprise, mais elle réduit fortement le risque de perte, de défaillance commune et de compromission simultanée des données de production et des sauvegardes.
Sauvegarde, reprise et continuité d’activité
La sauvegarde ne se confond ni avec la reprise ni avec la continuité d’activité. La sauvegarde consiste à conserver des copies de données ou de systèmes. La reprise vise à remettre en fonctionnement les applications, équipements, flux et services nécessaires. La continuité d’activité consiste à maintenir ou rétablir l’activité dans des conditions acceptables malgré l’incident.
Deux notions sont particulièrement importantes pour dimensionner une stratégie de sauvegarde :
RTO : Recovery Time Objective
Le RTO désigne le temps maximal acceptable d’interruption. Il répond à une question simple : combien de temps l’organisation peut-elle rester à l’arrêt avant que l’impact ne devienne critique ?
Exemple opérationnel : si le RTO d’un ERP est fixé à 4 heures, la restauration doit permettre une remise en service dans ce délai.
RPO : Recovery Point Objective
Le RPO désigne la perte de données maximale acceptable entre la dernière sauvegarde exploitable et l’incident. Il détermine donc la fréquence à laquelle les données doivent être sauvegardées.
Exemple opérationnel : si le RPO d’une base clients est de 1 heure, une sauvegarde quotidienne ne suffit pas. Il faut prévoir une fréquence compatible avec ce niveau d’exigence.
Autrement dit, disposer de sauvegardes ne suffit pas. Il faut aussi savoir quoi restaurer, dans quel ordre, avec quelles dépendances et dans quels délais.
Les bonnes questions à se poser
- Quelles sont les données, applications et services réellement critiques ?
- Quel RTO est acceptable pour chaque service essentiel ?
- Quel RPO est acceptable en cas d’incident ?
- Les sauvegardes sont-elles isolées du système principal ?
- Une copie est-elle réellement hors ligne ou hors site ?
- Les sauvegardes sont-elles protégées contre l’altération, la suppression et le chiffrement ?
- Les restaurations sont-elles testées régulièrement en conditions réelles ?
- La procédure est-elle documentée, connue et attribuée à des responsables identifiés ?
Conclusion
La sauvegarde reste l’une des mesures les plus fondamentales en cybersécurité et en résilience opérationnelle. Mais son efficacité ne dépend pas du simple fait d’avoir un outil ou une copie supplémentaire. Elle dépend de la capacité réelle à disposer de données intègres, disponibles, protégées et restaurables.
En matière de sauvegarde, la vraie question n’est donc pas de savoir si des copies existent, mais si l’organisation est capable de restaurer rapidement les données et services critiques lorsque l’incident survient.
