- 3 copies, 2 supports, 1 copie hors site : la base historique, qui protège contre la panne et le sinistre physique.
- 1 copie immuable ou isolée : la protection contre le rançongiciel et l’administrateur compromis, qui ne peuvent ni la modifier ni la supprimer.
- 0 erreur : des sauvegardes vérifiées automatiquement et des restaurations testées, sans quoi la règle reste théorique.
- Le dimensionnement part des métiers : quelle perte de données acceptable (RPO) et quel délai de reprise (RTO) pour chaque application.
- Public
- Dirigeants, DSI, responsables d’infrastructure
- Niveau
- Tous niveaux
- Référentiels
- Recommandations ANSSI, guide d’hygiène informatique
- Hors périmètre
- Plan de continuité métier complet (PCA)
Pourquoi la sauvegarde classique ne suffit plus#
Pendant longtemps, une sauvegarde servait à se remettre d’une panne de disque, d’une erreur de manipulation ou d’un sinistre. Ces risques n’ont pas disparu, mais un autre est devenu dominant : l’attaque par rançongiciel. Les groupes criminels savent qu’une entreprise capable de restaurer ne paiera pas. Leur méthode est donc constante : obtenir des droits d’administration, repérer la console et les dépôts de sauvegarde, effacer ou chiffrer les copies, puis seulement lancer le chiffrement de la production.
Une sauvegarde joignable avec les mêmes identifiants que la production, sur le même réseau, ne résiste pas à ce scénario. C’est pour y répondre que la règle historique 3-2-1 a été complétée par deux exigences supplémentaires.
La règle 3-2-1-1-0, chiffre par chiffre#
| Chiffre | Exigence | Ce que cela protège |
|---|---|---|
| 3 | Trois copies des données : la production et deux sauvegardes | La perte d’une copie unique |
| 2 | Deux supports ou technologies différents (disques, objet, bande…) | La défaillance d’un type de support ou d’un logiciel |
| 1 | Une copie hors du site de production | L’incendie, le dégât des eaux, le vol, l’indisponibilité du site |
| 1 | Une copie immuable ou déconnectée | Le rançongiciel et l’administrateur compromis |
| 0 | Zéro erreur à la vérification et à la restauration | La sauvegarde corrompue ou inutilisable découverte trop tard |
Une copie immuable, concrètement
Une copie immuable ne peut être ni modifiée ni supprimée pendant une durée de rétention définie, y compris par un compte administrateur. Sur un stockage objet compatible S3, c’est le verrouillage d’objet (Object Lock) en mode conformité : tant que la rétention court, personne ne peut raccourcir la durée ni effacer les données. D’autres approches existent : dépôt Linux durci en écriture unique, bande éjectée de la librairie, copie hors ligne. L’important est qu’aucun identifiant de la production ne permette d’y toucher.
Zéro erreur, concrètement
Une sauvegarde « réussie » dans la console n’est pas une sauvegarde restaurable. Le zéro erreur combine trois contrôles : la vérification automatique de l’intégrité des points de sauvegarde, la restauration régulière de fichiers et de machines complètes dans un environnement isolé, et un exercice annuel de reprise sur un périmètre critique, avec mesure du temps réel de redémarrage.
Partir des métiers : RPO et RTO#
Avant de choisir des outils, il faut deux réponses par application, obtenues auprès des responsables métier :
- RPO (Recovery Point Objective) : la quantité maximale de données que l’on accepte de perdre, exprimée en temps. Un RPO de 24 heures autorise une sauvegarde par nuit ; un RPO de 15 minutes impose des sauvegardes fréquentes, de la journalisation ou de la réplication.
- RTO (Recovery Time Objective) : le délai maximal acceptable avant le redémarrage. Il conditionne l’emplacement des copies (une restauration locale est plus rapide), la capacité de calcul de reprise et le degré de préparation.
Ces deux valeurs, croisées avec le volume de données, déterminent la fréquence, la rétention et l’architecture. Elles évitent deux écueils fréquents : surprotéger des données secondaires et sous-protéger l’ERP ou la messagerie.
Une architecture type pour une PME ou une ETI#
- Production : serveurs, VM, partages de fichiers et applications SaaS comme Microsoft 365, qui doit être sauvegardé au même titre que le reste.
- Première sauvegarde, locale : un dépôt sur disques, séparé de la production (serveur dédié ou appliance), pour des restaurations rapides au quotidien.
- Deuxième sauvegarde, hors site et immuable : une copie automatique vers un stockage objet S3 avec verrouillage d’objet, dans un datacenter distant, sur une autre technologie que le dépôt local.
Cette organisation couvre les cinq chiffres de la règle : trois copies, deux technologies, une copie hors site, qui est aussi la copie immuable, et des tests planifiés sur les deux niveaux.
Fréquences, rétentions et tests : des repères#
| Élément | Repère courant | À ajuster selon |
|---|---|---|
| Fréquence des sauvegardes | Quotidienne, plus fréquente pour les bases et serveurs critiques | Le RPO de chaque application |
| Rétention locale | Deux à quatre semaines de points quotidiens | Le volume et la capacité du dépôt |
| Rétention hors site immuable | Au moins 30 jours, avec des points mensuels conservés plus longtemps | Les obligations légales et contractuelles |
| Vérification d’intégrité | Automatique, à chaque cycle | — |
| Test de restauration | Mensuel sur un échantillon, au moins semestriel sur une VM complète | La criticité et les changements d’infrastructure |
| Exercice de reprise | Annuel sur un périmètre critique, chronométré | Les exigences des assureurs et des clients |
La check-list pour vérifier votre dispositif#
- Toutes les données sont-elles couvertes, y compris Microsoft 365, les postes nomades et les applications SaaS ?
- Existe-t-il au moins une copie hors site et une copie qu’aucun compte de la production ne peut supprimer ?
- Les sauvegardes sont-elles chiffrées, et les clés conservées ailleurs ?
- Un incident de sauvegarde génère-t-il une alerte traitée, et par qui ?
- Quand a eu lieu la dernière restauration complète d’un serveur, et combien de temps a-t-elle pris ?
- La procédure de reprise est-elle documentée, accessible hors du système d’information, et connue de plusieurs personnes ?
Si l’une de ces questions reste sans réponse précise, le dispositif comporte un angle mort. C’est le point de départ d’une revue de résilience des sauvegardes.
Questions fréquentes#
La règle 3-2-1-1-0 est-elle une obligation réglementaire ?
Non, c’est une bonne pratique reconnue. Mais les exigences qui s’en rapprochent se multiplient : questionnaires des assureurs cyber, directive NIS 2 pour les entités concernées, exigences contractuelles de clients ou de donneurs d’ordre.
Le cloud remplace-t-il la sauvegarde locale ?
Il la complète. La copie hors site dans le cloud protège du sinistre et, si elle est immuable, du rançongiciel ; la copie locale permet des restaurations rapides du quotidien. Les deux répondent à des besoins différents.
Microsoft 365 est-il sauvegardé par Microsoft ?
Microsoft assure la disponibilité du service, pas la restauration de vos données au-delà des corbeilles et rétentions natives. Une sauvegarde indépendante de Microsoft 365 reste nécessaire pour couvrir suppressions, erreurs et attaques.
À quelle fréquence tester une restauration ?
Un échantillon chaque mois, une machine complète au moins deux fois par an, et un exercice de reprise annuel chronométré sur les applications critiques.