La bonne question n'est pas « avez-vous des sauvegardes ? » : tout le monde répond oui. C'est : « quand avez-vous restauré pour la dernière fois, et qu'est-ce qui empêche un attaquant qui contrôle vos serveurs de détruire vos sauvegardes avec le reste ? ». À ces deux questions, l'immense majorité des PME répond mal. Voici la règle 3-2-1, ce qu'il faut lui ajouter en 2026, et l'architecture que nous opérons.
La règle 3-2-1, et pourquoi elle ne suffit plus
La règle est simple et n'a pas pris une ride dans son principe : 3 copies de vos données (la production comprise), sur 2 supports ou systèmes différents, dont 1 hors site. Elle protège contre la panne matérielle, l'erreur humaine, l'incendie. Mais elle a été formulée avant que le ransomware ne devienne une industrie, et le ransomware a changé une chose fondamentale : vos sauvegardes sont désormais la première cible, pas la dernière ligne de défense.
Un opérateur de ransomware compétent ne chiffre pas vos serveurs le jour où il entre. Il explore, récupère des identifiants, localise les sauvegardes, puis les détruit ou les chiffre d'abord. Si votre serveur de production connaît le mot de passe du NAS de sauvegarde, vos trois copies n'en font qu'une. D'où les deux ajouts modernes, parfois résumés « 3-2-1-1-0 » : 1 copie immuable ou hors ligne, et 0 erreur de restauration, c'est-à-dire des restaurations réellement testées.
L'immuabilité : une copie que personne ne peut modifier, pas même vous
Une sauvegarde immuable est une copie qu'aucun identifiant compromis ne permet d'altérer pendant sa période de rétention. Concrètement, ça se construit avec deux principes d'architecture :
- Le serveur de sauvegarde ne fait pas confiance aux machines qu'il sauvegarde. Chaque machine dépose ses sauvegardes avec un droit d'écriture seule (append-only) : elle peut ajouter, jamais effacer ni modifier. Un attaquant qui contrôle la production ne peut donc pas détruire l'historique : les suppressions et la rétention sont pilotées du côté du serveur de sauvegarde, avec d'autres identifiants.
- *La copie hors site se fait en mode pull, pas push. C'est le site distant qui vient tirer* les sauvegardes, avec ses propres accès en lecture. La chaîne de production ne détient aucun identifiant vers la copie hors site : elle ignore jusqu'à son existence. Compromettre la production ne donne aucun chemin vers la dernière ligne de défense.
Le test est simple : depuis un serveur de production compromis, avec tous ses secrets, peut-on détruire les sauvegardes ? Si la réponse n'est pas un « non » démontrable, vous n'avez pas de sauvegardes : vous avez des copies provisoires.
Notre architecture en production
Voici comment ces principes se matérialisent sur l'infrastructure que nous opérons pour nos clients, avec Proxmox Backup Server, dont nous avons déjà détaillé la déduplication et la rétention :
- Sauvegardes quotidiennes de chaque machine vers un serveur de sauvegarde dédié, hors du cluster de production, en append-only : la production écrit, elle n'efface rien.
- Un espace étanche par client (namespaces) : chaque locataire a ses accès, personne ne voit les données des autres, et le rayon d'explosion d'un identifiant compromis reste borné.
- Déduplication mesurée à 7,4× sur notre parc : conserver des semaines d'historique coûte une fraction du volume brut : la rétention longue cesse d'être un arbitrage financier.
- Miroir hors site en mode pull, sur un site géographiquement distinct, avec ses propres identifiants en lecture seule et une rétention indépendante.
- Chiffrement côté client pour les sauvegardes que nous hébergeons pour des tiers : nous stockons des blocs chiffrés dont nous ne détenons pas la clé.
Une sauvegarde non testée n'existe pas
Le « 0 » de 3-2-1-1-0 est le plus négligé. Les sauvegardes échouent en silence : un job qui plante depuis des semaines, un volume plein, une base exportée à chaud et incohérente. La seule preuve d'une sauvegarde, c'est une restauration réelle : machine complète remontée sur un hôte vierge, base de données rejouée, application démarrée et vérifiée. Nous le faisons périodiquement sur notre propre infrastructure, et le premier test a toujours quelque chose à apprendre : le nôtre a révélé des détails de procédure qu'aucune documentation théorique n'aurait attrapés.
Auditez vos sauvegardes en cinq questions
- Depuis un serveur de production compromis, peut-on effacer ou chiffrer les sauvegardes ? (append-only, identifiants séparés)
- La copie hors site est-elle jointe en push depuis la production, ou tirée en pull depuis le site distant ?
- Quand a eu lieu la dernière restauration complète réussie, et qui l'a constatée ?
- Qui est alerté quand un job de sauvegarde échoue, et l'alerte a-t-elle été testée en coupant volontairement un job ?
- Votre rétention couvre-t-elle un ransomware découvert tard ? (un attaquant peut attendre des semaines avant de chiffrer)
Cette architecture est comprise dans notre hébergement souverain et notre infogérance : sauvegardes quotidiennes, copie immuable, hors-site et tests de restauration. Si vous voulez passer les cinq questions ci-dessus sur votre propre dispositif, on peut le faire ensemble.
