Sauvegarde 3-2-1-1-0 : peut-on restaurer ?

Une sauvegarde non testée est une hypothèse

Beaucoup d’entreprises pensent être protégées parce qu’un logiciel de sauvegarde tourne tous les soirs. Le jour d’un ransomware, elles découvrent parfois que les sauvegardes sont incomplètes, chiffrées elles aussi, trop anciennes ou impossibles à restaurer rapidement.

Ce que les chiffres 2025-2026 révèlent sur les restaurations

Les statistiques du secteur donnent une mesure précise de l’écart entre avoir une sauvegarde et pouvoir réellement s’en servir, et cet écart est plus large qu’on ne l’imagine généralement.

Indicateur	Donnée observée
Entreprises touchées par un ransomware sur 12 mois (CrowdStrike 2025)	78 %
Organisations n’ayant pas pu restaurer intégralement leurs données après attaque	39 %
Coût moyen d’interruption d’activité par incident	1,7 million de dollars

Le chiffre le plus parlant est le deuxième : avoir une sauvegarde n’est pas la même chose que pouvoir restaurer. Près de quatre organisations sur dix qui pensaient être protégées ont découvert, au pire moment possible, qu’elles ne pouvaient pas remettre la main sur l’intégralité de leurs données.

La règle 3-2-1-1-0 résume une bonne direction : plusieurs copies, plusieurs supports, une copie hors site, une copie isolée ou immuable, et zéro erreur lors des vérifications. Mais la règle ne suffit pas si elle n’est jamais mise à l’épreuve. La question décisive reste : avez-vous déjà restauré ?

Les points à vérifier

• Périmètre : serveurs, fichiers, bases de données, machines virtuelles, Microsoft 365, configurations réseau.
• Fréquence : l’intervalle entre deux sauvegardes correspond-il à la perte de données acceptable ?
• Isolation : les sauvegardes sont-elles protégées d’un compte administrateur compromis ? Les attaquants ciblent désormais activement les sauvegardes elles-mêmes, ce qui explique une bonne partie des échecs de restauration constatés après un incident.
• Immutabilité ou hors ligne : une copie peut-elle résister à un ransomware ?
• Tests : les restaurations sont-elles réalisées régulièrement ?
• Temps de reprise : combien de temps faut-il pour remettre le service en route ?
• Responsabilités : qui décide, qui restaure, qui communique ?

RTO et RPO : les deux chiffres à connaître

Le RPO indique la quantité de données que l’entreprise accepte de perdre. Si la sauvegarde est quotidienne, le RPO peut atteindre 24 heures.

Le RTO indique le délai acceptable avant reprise du service. Restaurer plusieurs téraoctets de données sur un matériel non préparé peut prendre bien plus longtemps que prévu, un facteur qui pèse directement dans le coût moyen d’1,7 million de dollars d’interruption d’activité mesuré par incident.

Sans ces deux chiffres, il est impossible de savoir si la sauvegarde répond vraiment au besoin métier.

Décoder la règle chiffre par chiffre

Chaque chiffre de la règle 3-2-1-1-0 répond à un mode de défaillance précis, ce qui aide à comprendre pourquoi aucun n’est superflu :

• 3 copies : l’original plus deux copies. Une seule copie ne survit jamais à une défaillance matérielle simultanée à une attaque.
• 2 supports différents : disque et cloud, par exemple, jamais deux disques identiques du même modèle susceptibles de tomber en panne pour la même raison au même moment.
• 1 copie hors site : géographiquement séparée, pour survivre à un sinistre physique (incendie, dégât des eaux, vol) qui toucherait le site principal.
• 1 copie isolée ou immuable : déconnectée du réseau ou rendue non modifiable pendant une période définie, la seule protection réelle contre un ransomware qui chiffre ou supprime activement les sauvegardes accessibles depuis le réseau compromis.
• 0 erreur : zéro anomalie détectée lors des vérifications de sauvegarde et des tests de restauration, le seul chiffre de la règle qui ne se configure pas techniquement mais se prouve par un test réel.

Le test de restauration

Un test simple vaut mieux qu’une promesse théorique. Choisissez un serveur, une base ou un dossier critique. Restaurez-le dans un environnement isolé. Vérifiez les droits, l’intégrité des fichiers, la cohérence applicative et le temps réel nécessaire.

Documentez ensuite les écarts : sauvegarde trop lente, dépendance oubliée, mot de passe manquant, procédure non écrite, espace insuffisant. Chaque test rend l’entreprise plus robuste, et réduit la probabilité de rejoindre les 39 % d’organisations qui découvrent trop tard qu’elles ne peuvent pas restaurer intégralement leurs données. Un test qui échoue en environnement contrôlé, sans pression ni urgence, est une bonne nouvelle : il révèle un problème corrigeable avant qu’un vrai incident ne le transforme en crise.

Une sauvegarde est un sujet de direction

La sauvegarde n’est pas seulement un outil IT. Elle protège le chiffre d’affaires, la réputation et la continuité d’activité, avec un coût d’incident qui se chiffre facilement en dizaines, voire en centaines de milliers d’euros pour une PME. Elle doit être comprise par la direction, budgétée et testée.

Le cloud n’est pas une sauvegarde en soi

Une idée reçue tenace veut qu’une donnée dans le cloud soit, par nature, à l’abri. C’est faux. Une sauvegarde hébergée dans le cloud mais connectée en permanence au réseau reste accessible tant que les identifiants ne sont pas compromis. Si un attaquant obtient des droits d’administration suffisants, il peut atteindre ces sauvegardes comme il atteindrait un disque local, et les chiffrer ou les supprimer avant de déclencher son ransomware. Le cloud déplace la donnée, il ne l’isole pas automatiquement.

Ce qui protège n’est pas l’emplacement, mais deux propriétés précises : l’immutabilité, qui rend une copie non modifiable pendant une durée définie, et l’isolation, qui la déconnecte physiquement ou logiquement du réseau. Une sauvegarde cloud immuable est une excellente protection ; une simple synchronisation vers le cloud, connectée en continu, n’en est pas une. La distinction est technique, mais elle fait toute la différence le jour d’une attaque.

Qui fait quoi le jour de l’incident

La restauration n’est pas qu’une affaire technique, c’est aussi une question d’organisation, et c’est souvent là que tout se joue. Le jour d’un ransomware, sous le stress, une équipe qui n’a jamais défini les rôles perd un temps précieux à se demander qui décide d’isoler les systèmes, qui lance la restauration, qui prévient les clients et la direction, qui contacte l’assureur ou les autorités. Ce temps perdu se paie directement en heures d’interruption.

Un plan clair, écrit et connu à l’avance, change radicalement la donne. Il n’a pas besoin d’être un document épais : quelques pages suffisent à répartir les responsabilités, lister les contacts d’urgence et décrire l’ordre des opérations. L’essentiel est qu’il existe avant l’incident, pas qu’on l’improvise pendant. Un test de restauration est d’ailleurs l’occasion idéale de vérifier que ce plan tient debout.

Restaurer, la seule preuve qui compte

Tout, dans une stratégie de sauvegarde, se ramène à une question unique : avez-vous déjà restauré ? La règle 3-2-1-1-0 pose de bonnes fondations, mais elle ne vaut que si un test réel vient la confirmer, idéalement plusieurs fois par an et sur un périmètre représentatif. Un test qui échoue dans le calme d’un environnement contrôlé est une chance : il révèle un défaut corrigeable avant qu’un vrai incident ne le transforme en catastrophe.

OLHYN peut intégrer ce sujet dans un audit du système d’information ou un projet de migration de virtualisation. Mieux vaut découvrir les limites de ses sauvegardes lors d’un test que le jour d’une attaque.

Sources : Solutions Numériques, Ransomware 2025 : 78 % des entreprises touchées selon CrowdStrike · CrowdStrike, 2025 Ransomware Report · NIST SP 800-34 Rev. 1, Contingency Planning Guide