Sauvegardes : la règle 3-2-1 expliquée avec un cas réel

On en parle tout le temps en cours, en stage, sur les forums, et même au détour d’un ticket de support : la sauvegarde.

Et pourtant, c’est souvent le dernier truc qu’on met vraiment au carré. Jusqu’au jour où.

Aujourd’hui je pose ça proprement, sans faire semblant que « tout se passe toujours bien » : la règle 3-2-1, expliquée simplement, avec un cas réel (et un peu douloureux) comme on en voit dans la vraie vie. Le genre de situation qui ressemble beaucoup à un TP… sauf que là, ce n’est pas noté, c’est ton entreprise qui prend.

La règle 3-2-1, c’est quoi exactement

La règle 3-2-1, c’est une manière simple de se souvenir d’un truc essentiel : une seule sauvegarde ne suffit pas. Une sauvegarde au même endroit que la prod ne suffit pas. Une sauvegarde sur le même type de stockage ne suffit pas non plus.

La règle dit :

• 3 copies de tes données (la prod + 2 copies)
• 2 supports différents (par exemple disque + cloud, ou NAS + bande, etc.)
• 1 copie hors site (physiquement ailleurs, ou au minimum dans un autre environnement, isolé)

Dit comme ça, ça a l’air évident. Mais dans les faits, on voit souvent des variantes du type : « on a un NAS, donc c’est bon », ou « on réplique sur un autre disque du serveur ». Et là, non. C’est mieux que rien, mais ce n’est pas une stratégie.

Pourquoi cette règle existe encore en 2026

Parce que les causes de perte de données, elles, n’ont pas disparu. Elles se sont multipliées.

• panne disque, contrôleur RAID, firmware qui fait n’importe quoi
• erreur humaine (suppression, écrasement, mauvais script, mauvais copier coller)
• ransomware
• sinistre (incendie, dégât des eaux, vol)
• corruption silencieuse (le truc le plus sournois, tu ne vois rien… jusqu’au restore)

Et surtout, un point qu’on sous estime : beaucoup d’incidents touchent à la fois la prod et la sauvegarde locale, car tout est dans le même périmètre d’administration, le même réseau, les mêmes droits, parfois même le même bâtiment.

Le cas réel : « on avait une sauvegarde… enfin on croyait »

Contexte. Petite structure, une trentaine de postes, un serveur Windows (AD, fichiers, deux ou trois applis métiers), un NAS Synology pour les sauvegardes. Classique.

Le plan, sur le papier :

• sauvegarde quotidienne du serveur vers le NAS
• snapshot sur le NAS
• réplication « plus tard » vers le cloud (prévu, pas fait)
• tests de restauration « quand on aura le temps »

Ça sent déjà le vécu.

Le jour J : tout bascule en 15 minutes

Un matin, un utilisateur ouvre une pièce jointe. Rien de spectaculaire, pas de gros message d’alerte. Deux heures après, les fichiers partagés commencent à changer d’extension. Puis les postes.

Le ransomware se propage. Et surtout, il atteint le serveur de fichiers via un compte qui avait trop de droits. Là aussi, classique.

Le service IT coupe le réseau. Trop tard pour une partie des données.

Et là, moment de soulagement : « on a des sauvegardes sur le NAS ». Donc on respire. Deux minutes.

Sauf que.

Le NAS était joint au domaine. Les sauvegardes étaient accessibles depuis le réseau interne. Et certains partages du NAS étaient mappés sur des postes (oui…). Résultat : le ransomware a aussi chiffré une partie des sauvegardes, et a supprimé des versions.

Les snapshots ? Ils existaient. Mais configurés avec une rétention trop courte. Et surtout, les identifiants d’administration du NAS étaient stockés dans un gestionnaire de mots de passe… accessible sur un poste compromis. Donc l’attaquant a pu aller plus loin.

À la fin, il restait :

• des sauvegardes incomplètes
• des sauvegardes chiffrées
• des points de restauration trop récents, déjà contaminés

Et pas de copie hors site.

Conclusion : restauration partielle, perte de données sur plusieurs jours, et reconstruction à la main de certains dossiers. Des factures, des documents RH, des exports d’appli métier. La joie.

Où la règle 3-2-1 aurait changé l’histoire

On reprend le même cas, mais avec une vraie mise en œuvre 3-2-1.

1) Les 3 copies : production + deux copies réelles

• copie 1 : les données en production (serveur)
• copie 2 : sauvegarde locale (NAS, dépôt backup)
• copie 3 : sauvegarde supplémentaire, idéalement immuable, ou au moins isolée

L’idée n’est pas « j’ai deux dossiers backup ». L’idée, c’est que la troisième copie doit survivre à un incident qui détruit ou chiffre la seconde.

2) Les 2 supports : éviter le monoculture

Si tout est sur du disque dans le même LAN, tu es vulnérable à plein de scénarios communs.

Exemples de « 2 supports » qui tiennent la route :

• NAS local + stockage cloud (S3 compatible, Azure, etc.)
• NAS local + bandes LTO
• disques externes tournants + cloud
• SAN + repository dédié + stockage objet immuable

Oui, la bande existe encore. Et oui, c’est lent. Mais pour certains contextes, c’est une arme anti ransomware redoutable.

3) Le 1 hors site : ce qui sauve quand tout le reste brûle

Hors site, ça veut dire : ailleurs. Pas « autre baie dans la même salle ».

Ça peut être :

• un cloud (avec versioning, verrouillage, immutabilité)
• un second site (même une petite salle serveur dans un autre bâtiment)
• un disque stocké physiquement ailleurs (rotation hebdo, par exemple)

Le hors site, c’est le dernier filet. Celui qui fait que tu ne négocies pas avec l’attaquant, et que tu ne pleures pas devant ton NAS.

Une version simple et réaliste d’une stratégie 3-2-1 pour un lab BTS SIO ou une PME

Je vais être très concret, façon « on pourrait le monter en TP au Tech Lab ». D’ailleurs si tu lis ça depuis BTS SIO2 SISR Tech Lab (le blog : https://sio1blog.blogspot.com/), tu peux t’en servir comme base de mini projet ou de doc d’exploitation.

Objectif : fichier serveur + AD + quelques VM

Copie 1 : production

• serveur ou hyperviseur (Proxmox, ESXi, Hyper-V)
• partages SMB, bases, VM

Copie 2 : sauvegarde locale

• un dépôt backup dédié (NAS ou serveur)
• outil : Veeam, UrBackup, Borg, Restic, Proxmox Backup Server, Nakivo, peu importe… mais config propre
• snapshots côté stockage si possible, mais pas comme unique protection

Copie 3 : hors site

• stockage objet compatible S3 (Backblaze B2, Wasabi, OVH, AWS) ou Azure Blob
• ou un second NAS dans un autre lieu + VPN + réplication
• idéalement : immutabilité (Object Lock, ou dépôt WORM)

Ce dernier point change tout. Une sauvegarde immuable, même si un compte admin est compromis, l’attaquant ne peut pas supprimer les sauvegardes récentes avant l’expiration.

Les détails qui font échouer une 3-2-1 sur le terrain

Tu peux avoir une architecture « qui ressemble » à du 3-2-1 et quand même te faire avoir. Voilà les pièges vus et revus.

Les sauvegardes accessibles depuis les postes

Si ton repository backup est monté en lecteur réseau sur des postes, ou accessible en écriture depuis trop d’endroits, tu tends la main au ransomware.

Un dépôt de sauvegarde, c’est un coffre. Pas un partage.

Les mêmes identifiants partout

Compte admin du domaine utilisé pour les jobs de sauvegarde. Même mot de passe sur plusieurs services. Ou pire, stocké sur un poste.

Solution : comptes de service dédiés, moindre privilège, segmentation, MFA pour l’accès console quand c’est possible.

Pas de test de restauration

Une sauvegarde non testée, ce n’est pas une sauvegarde. C’est une croyance.

À minima :

• test mensuel de restauration de fichiers
• test trimestriel de restauration complète d’une VM ou d’un serveur
• mesure du RTO et du RPO réels (pas ceux imaginés)

Rétention trop courte

« On garde 7 jours ». Ok. Et si la corruption ou le chiffrement a commencé il y a 10 jours, silencieusement ?

Il faut penser rétention en couches :

• quotidien : 14 à 30 jours
• hebdo : 8 à 12 semaines
• mensuel : 12 mois (selon obligations et besoins)

Oui, ça coûte du stockage. Mais ça coûte moins cher qu’une reprise à zéro.

Petit scénario de restauration : ce que j’aurais aimé voir dans le cas réel

Dans le cas réel plus haut, avec une vraie 3-2-1, la procédure aurait ressemblé à ça :

1. isolement réseau, analyse, nettoyage
2. inventaire : ce qui est touché, ce qui est sain
3. restauration du serveur de fichiers depuis la sauvegarde locale si elle est intacte
4. si la sauvegarde locale est compromise : bascule vers la copie hors site immuable
5. validation : scans, contrôles d’intégrité, ouverture des fichiers critiques
6. remise en service progressive

Ce n’est pas magique. Mais tu reprends la main.

Et surtout, tu n’es pas en train d’essayer de « réparer » des fichiers chiffrés à 3 h du matin. Parce que ça, c’est une pente.

Concrètement, par où commencer si tu as zéro plan

Si tu es étudiant SISR, ou jeune admin, ou même juste la personne « un peu à l’aise » qui a hérité de l’IT. Voilà une checklist courte.

• fais la liste des données critiques (et des applis)
• définis RPO et RTO, même grossièrement
• mets une sauvegarde locale automatisée, avec rétention
• ajoute une copie hors site (cloud ou second site)
• sépare les accès, limite les droits, évite que les postes voient le dépôt
• teste une restauration, puis documente la procédure

Et si tu veux un endroit pour retrouver des labs orientés systèmes, réseau, sécu, avec le ton du terrain, tu peux garder sous la main BTS SIO2 SISR Tech Lab sur https://sio1blog.blogspot.com/. Ce genre de sujet, c’est typiquement ce qu’on devrait pratiquer plus souvent, pas juste lire.

Conclusion : la règle 3-2-1, ce n’est pas une formule, c’est une habitude

La 3-2-1, ce n’est pas un slogan à mettre dans une politique de sauvegarde PDF que personne n’ouvre.

C’est une discipline. Une façon de penser : « qu’est ce qui se passe si cet élément tombe, et celui là aussi, et si en plus c’est volontaire ».

Le cas réel le montre bien : la sauvegarde locale seule donne une illusion de sécurité. Jusqu’au moment où elle tombe en même temps que la prod.

Alors oui, ça prend un peu de temps à mettre en place. Et oui, il faut tester. Mais le jour où ça tape, tu es content d’avoir été un peu parano avant.

Questions fréquemment posées

Qu'est-ce que la règle 3-2-1 en matière de sauvegarde ?

La règle 3-2-1 est une méthode simple pour sécuriser ses données : il faut avoir 3 copies des données (la production plus 2 copies), stockées sur 2 supports différents (par exemple disque dur et cloud), avec au moins 1 copie hors site, c'est-à-dire physiquement éloignée ou isolée du site principal.

Pourquoi une seule sauvegarde ne suffit-elle pas ?

Une seule sauvegarde ne suffit pas car elle peut être compromise par des pannes, erreurs humaines, ransomwares, sinistres ou corruptions silencieuses. De plus, si la sauvegarde est sur le même type de stockage ou au même endroit que la production, un incident peut affecter à la fois les données originales et leur sauvegarde.

Quels sont les risques courants qui menacent les données d'une entreprise en 2026 ?

Les risques incluent les pannes matérielles (disques, RAID), erreurs humaines (suppression accidentelle), attaques par ransomware, sinistres comme incendies ou dégâts des eaux, vols, ainsi que la corruption silencieuse des données qui peut passer inaperçue jusqu'à la restauration.

Pourquoi est-il important d'avoir une copie de sauvegarde hors site ?

Une copie hors site protège contre les sinistres locaux tels qu'incendies, inondations ou vols qui pourraient détruire à la fois les données de production et leurs sauvegardes locales. Elle garantit également une isolation physique ou réseau pour éviter la propagation d'attaques comme les ransomwares.

Quels sont les pièges courants dans une stratégie de sauvegarde mal appliquée ?

Les pièges fréquents sont de considérer qu'un NAS seul suffit comme sauvegarde, de répliquer sur un disque du même serveur sans diversification des supports, de ne pas tester régulièrement les restaurations, ou encore de garder des identifiants d'administration accessibles depuis des postes compromis.

Que montre l'exemple réel d'une entreprise victime d'un ransomware malgré ses sauvegardes ?

L'exemple illustre qu'avoir des sauvegardes n'est pas suffisant si elles ne respectent pas la règle 3-2-1 : ici le ransomware a chiffré aussi les sauvegardes accessibles sur le réseau, les snapshots avaient une rétention trop courte, et aucune copie hors site n'était disponible. Cela a conduit à une restauration partielle et une perte de plusieurs jours de données.