Sauvegarde de serveur : la règle 3-2-1 appliquée à un dédié

La règle 3-2-1 appliquée à un serveur dédié tient en trois obligations : trois copies des données, sur deux supports ou emplacements distincts, dont une hors du site. En pratique, cela signifie une sauvegarde locale pour revenir en arrière dans l’heure, une copie sur un second support pour survivre à une panne matérielle, et une copie externalisée pour survivre à la perte du serveur. Sur un dédié, ce dispositif coûte 15 à 40 € HT par mois en sus du socle d’infogérance, et demande un test de restauration par trimestre — une à deux heures de travail, pas une ligne dans un contrat.

La règle 3-2-1 en une phrase

Formulée par le photographe Peter Krogh en 2005 pour les archives numériques, la règle 3-2-1 est devenue le socle de toute politique de sauvegarde sérieuse. Elle se récite ainsi : trois copies au total (l’originale incluse), sur deux types de supports différents, dont une copie hors site.

Chaque chiffre corrige une erreur concrète. Le « 3 » protège contre la corruption d’une copie. Le « 2 » protège contre la défaillance d’un support : deux disques du même modèle, achetés le même jour, tombent souvent à quelques semaines d’intervalle. Le « 1 » protège contre la perte du lieu : incendie, vol, ou simple erreur de facturation qui éteint la machine.

Sur un dédié, un snapshot LVM sur le même volume physique n’est pas une copie : c’est un retour en arrière, qui ne survit ni à la perte du disque ni à un chiffrement du volume.

Du 3-2-1 au 3-2-1-1-0 : ce que le rançongiciel a changé

Depuis 2020, la variante 3-2-1-1-0 s’impose dans les documents de sécurité, et pour une raison simple : un rançongiciel qui s’exécute sur le serveur accède à tout ce que le serveur peut atteindre, y compris le NAS monté en NFS et le compartiment objet dont les clés traînent dans un fichier de configuration.

• Le « 1 » supplémentaire désigne une copie hors ligne ou immuable : bande démontée, disque débranché, ou stockage objet en mode « object lock » — la copie ne peut pas être modifiée ni supprimée pendant la durée de rétention choisie.
• Le « 0 » signifie zéro erreur de restauration vérifiée : une sauvegarde jamais restaurée n’est pas une sauvegarde, c’est une hypothèse.

C’est le seul point qui engage du temps humain plutôt que du stockage, et presque toujours celui qui saute : deux ans de sauvegardes jamais restaurées sont deux ans de fichiers dont personne ne connaît l’état.

Appliquer le 3-2-1 sur un serveur dédié, couche par couche

Chercher un outil unique qui « fait le 3-2-1 » est une erreur : on empile quatre couches, chacune répondant à un sinistre différent.

Couche	Sinistre couvert	Où vit la copie	Fréquence usuelle
Snapshot local (LVM, ZFS, btrfs)	Erreur humaine, mise à jour ratée, suppression de fichiers	Même machine, volume séparé	Avant chaque intervention
Sauvegarde vers un second support	Panne disque ou contrôleur, corruption du système de fichiers	Machine secondaire du parc	Quotidienne
Copie externalisée	Perte du serveur, incident datacenter, vol	Stockage objet d’un autre opérateur	Quotidienne, chiffrée
Copie immuable ou hors ligne	Rançongiciel, compromission du compte de sauvegarde	Compartiment à rétention verrouillée, disque démonté	Hebdomadaire à mensuelle

Deux principes gouvernent cet empilement : l’isolation des identifiants — le compte qui écrit ne doit pas pouvoir supprimer les copies existantes — et la séparation de l’opérateur, car une copie chez le même hébergeur et sur le même compte client ne survit pas à la fermeture du compte.

Ce que coûte réellement une sauvegarde de serveur dédié

Sur un dédié, la sauvegarde est une somme de lignes dont l’addition surprend parfois. Montants observés sur le marché français, pour 100 Go à 1 To.

Poste	Coût mensuel indicatif	Observations
Disque ou volume local supplémentaire	0 à 30 € HT	Souvent inclus dans l’offre dédiée ; ne compte pas comme copie à lui seul
Stockage objet hors site (100 Go à 1 To)	5 à 15 € HT	Facturé au volume stocké et au trafic sortant lors des restaurations
Logiciel de sauvegarde	0 à 40 € HT	restic, borg et rsync sont libres ; les solutions éditeur se facturent par machine ou par To
Service infogéré (politique, exécution, contrôle)	15 à 25 € HT	Inclut la surveillance des échecs et la vérification d’intégrité
Test de restauration trimestriel	1 à 2 h de main-d’œuvre	Sur machine de test, avec mesure du temps de reprise réel

Autrement dit : une politique 3-2-1 sérieuse sur un serveur dédié ajoute 15 à 40 € HT par mois au socle d’infogérance, lui-même à 120 € HT par mois et par serveur. Ceux qui annoncent la sauvegarde « incluse » à ce prix parlent presque toujours d’un snapshot local — la couche qui ne survit justement pas au sinistre qui compte.

Les cinq erreurs qui annulent une sauvegarde

1. Sauvegarder sur le disque sauvegardé. Un répertoire /backup sur le même volume que les données disparaît avec le volume. C’est la forme la plus répandue de fausse sauvegarde.
2. Laisser le NAS monté en permanence. Un partage NFS ou SMB monté sur le serveur est accessible en écriture au processus compromis. La copie est chiffrée avec l’original, dans la même nuit.
3. Copier une base de données à chaud. Copier les fichiers d’InnoDB ou de PostgreSQL pendant les écritures produit un état incohérent qui ne se voit qu’à la restauration. Il faut un dump logique ou un snapshot de volume pris après gel des écritures.
4. Ne pas versionner. Une sauvegarde qui écrase la précédente à chaque exécution propage la corruption : si le fichier est chiffré lundi et sauvegardé lundi soir, il ne reste aucune version saine. La rétention doit conserver plusieurs générations, dont une antérieure à l’incident.
5. Ne pas surveiller l’échec du job. Un cron qui échoue à 3 h du matin ne réveille personne. Chaque job doit produire un indicateur vérifié par la supervision, avec alerte au deuxième échec consécutif — sinon le silence est pris pour du succès.

Aucune de ces erreurs ne se voit sur un tableau de bord : elles se voient à la restauration. C’est la seule preuve d’existence d’une sauvegarde.

Restauration : le seul test qui compte

Un test utile ne vérifie pas que l’archive s’ouvre : il reconstruit le service et mesure le temps que cela prend. Cinq étapes :

• Restaurer sur une machine vierge, jamais sur le serveur de production — sinon le test devient un incident.
• Chronométrer le téléchargement, la décompression et la remise en route.
• Vérifier les données applicatives, pas seulement les fichiers : une table de commandes, une collection, un index de recherche.
• Tester une restauration sélective — récupérer une seule table ou un seul répertoire, cas le plus fréquent en pratique après une erreur humaine.
• Consigner le résultat : date, durée, anomalies, version restaurée. Un test non écrit n’a pas eu lieu.

Garder la sauvegarde sur le serveur ou l’externaliser ?

Payer du stockage ou porter le risque : trois critères tranchent.

• La criticité de la donnée. Un site vitrine sans commande peut vivre avec une copie locale et un export mensuel hors site. Une base de facturation, non.
• La capacité de restauration interne. Externaliser ne sert à rien si personne ne sait relancer une machine : la copie hors site sans procédure de reprise déplace le problème, elle ne le résout pas.
• Le cadre réglementaire. Des données personnelles ou comptables imposent une copie hors site et une politique de conservation écrite : l’article 32 du RGPD exige de pouvoir rétablir la disponibilité des données.

Sur un dédié, la combinaison la plus économique reste un snapshot local fréquent, un dump quotidien vers une machine secondaire et une copie chiffrée chez un autre opérateur, avec trente jours de rétention et une génération immuable par semaine.

Ouvrir la vidéo dans un nouvel onglet

Questions fréquentes

La règle 3-2-1 est-elle une obligation légale ? Pas en tant que telle : aucun texte ne nomme la règle. Mais le RGPD impose de pouvoir rétablir les données après un incident, et la 3-2-1 est la façon la plus simple de le démontrer.

Combien de temps faut-il conserver les sauvegardes ? La durée découle de l’usage : trente versions quotidiennes couvrent la majorité des erreurs humaines, douze mensuelles couvrent les corruptions lentes, et les pièces comptables relèvent d’une conservation légale de dix ans.

Faut-il sauvegarder le serveur entier ou seulement les données ? Les deux, à des fréquences différentes : une image système hebdomadaire pour reconstruire une machine identique sans réinstallation, un dump quotidien pour les données. L’image complète chaque jour coûte plus cher pour le même résultat.

Une sauvegarde chiffrée suffit-elle ? Le chiffrement protège la copie en transit et au repos, à une condition : que la clé ne soit pas stockée sur le serveur sauvegardé. Une clé dans /etc ou dans une variable d’environnement part avec la machine compromise, et la sauvegarde devient lisible par l’attaquant. La clé doit vivre ailleurs : coffre de secrets ou machine d’administration.

Un devis chiffré pour votre serveur, pas une promesse

Nous auditons la politique existante en trois points : ce qui est sauvegardé, où vit chaque copie, et quand la dernière restauration a été testée. Le rapport liste les couches manquantes, leur coût et le temps de reprise mesuré au test suivant ; l’audit est inclus si le serveur est déjà infogéré.

Pour aller plus loin sur les briques concernées : la prise en charge complète du serveur dédié, la haute disponibilité et la réplication, et le durcissement SSH qui empêche justement l’accès utilisé par les rançongiciels. La grille tarifaire détaille chaque ligne, options de sauvegarde comprises.

Voir cette vidéo sur sa page de lecture