Sauvegarde de données : méthodes, règle 3-2-1 et restauration

Sauvegarde, synchronisation, RAID : ce n’est pas la même chose

Lundi 18 h, quelqu'un vide un dossier partagé de 40 Go sur le NAS. Le NAS est en RAID 6, deux disques peuvent lâcher sans perte de service. Ça ne change rien. La suppression est écrite sur tous les disques au même instant, et le dossier n'existe plus nulle part. Le RAID couvre la panne matérielle, pas l'erreur humaine, pas un rm -rf mal ciblé, pas un chiffrement malveillant.

Une sauvegarde suppose trois propriétés simultanées : une copie sur un support distinct, un historique de versions, et une restauration déjà vérifiée. Retirez l'une des trois et vous obtenez un autre outil, utile mais différent.

Le RAID a aussi ses limites propres. Sur un disque SATA grand public, le taux d'erreur de lecture non corrigible annoncé est de 1 secteur pour 10^14 bits lus, soit environ 12,5 To de lecture. Une reconstruction de grappe lit l'intégralité des disques survivants, souvent pendant des heures, exactement au moment où ils sont le plus sollicités.

• Synchronisation (OneDrive, Dropbox, Syncthing, rsync sans versionnage) : la suppression et le chiffrement se propagent à la copie, parfois en quelques secondes. La corbeille en ligne, souvent limitée à 30 jours, sert de seul filet.
• Réplication et RAID : disponibilité. Le service continue malgré un disque mort, et les données fautives sont répliquées telles quelles.
• Snapshot ZFS, Btrfs ou LVM : retour arrière quasi instantané, mais l'instantané vit sur le même pool que la donnée d'origine. Le pool disparaît, le snapshot avec.
• Archivage : conservation longue d'une donnée figée, pour une obligation légale ou un projet clos. Accès rare, souvent lent, coût au To très bas.
• Sauvegarde : copie indépendante, versionnée, restaurable sur un autre matériel que celui d'origine.

La règle 3-2-1 et ce qu’on lui a ajouté depuis

La formule vient du photographe Peter Krogh, dans The DAM Book publié en 2005, et elle a survécu à tous les changements de support depuis. Trois copies des données, sur deux types de supports différents, dont une hors site.

Trois copies signifie l'original plus deux sauvegardes, pas trois disques dans la même tour. Deux supports signifie deux technologies ou deux fournisseurs qui ne partagent pas le même mode de panne : un NAS et un stockage objet, un disque externe et une bande LTO. Hors site signifie assez loin pour survivre à l'incendie, au dégât des eaux et au cambriolage du local. Un disque USB laissé branché en permanence à côté du serveur coche une case sur trois.

Les éditeurs de sauvegarde ont étendu la règle en 3-2-1-1-0 après la vague de rançongiciels. Les deux chiffres ajoutés sont ceux qui coûtent le plus d'efforts et qui sauvent le plus souvent.

• 3 copies : l'original et deux sauvegardes réellement indépendantes.
• 2 supports : deux technologies ou deux prestataires distincts.
• 1 hors site : autre bâtiment, autre ville, ou stockage objet chez un tiers.
• 1 hors ligne ou immuable : bande éjectée du lecteur, disque débranché, objet sous verrou de rétention. C'est l'ajout imposé par les rançongiciels.
• 0 erreur : les données du dépôt sont vérifiées et une restauration test a réussi.

Complète, incrémentale, différentielle : ce que ça change à la restauration

Prenez 800 Go de données avec 5 Go modifiés par jour. En complète quotidienne, vous écrivez 5,6 To par semaine. Avec une complète le dimanche et des incrémentales les autres jours, vous écrivez environ 830 Go pour la même semaine. L'économie est réelle, la contrepartie aussi : la chaîne. Perdez l'incrément du mercredi et le jeudi devient inexploitable.

Les outils modernes à déduplication (restic, BorgBackup, Kopia, les moteurs incrémentaux permanents des solutions commerciales) suppriment ce compromis en présentant chaque exécution comme un instantané complet, tout en ne transférant que les blocs nouveaux. Une commande type avec restic : restic -r sftp:backup@nas.local:/srv/restic backup /var/www /etc --exclude-file=/etc/restic/exclude. Puis la rotation : restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --prune.

Type	Ce qui est copié	Fenêtre de sauvegarde	Ce qu'il faut pour restaurer
Complète	La totalité du périmètre, à chaque exécution	La plus longue	Une seule sauvegarde
Différentielle	Tout ce qui a changé depuis la dernière complète	Croît de jour en jour	La complète + la dernière différentielle
Incrémentale	Ce qui a changé depuis la sauvegarde précédente, quelle qu'elle soit	La plus courte	La complète + toute la chaîne d'incréments
Incrémentale permanente (restic, Borg, Veeam)	Blocs dédupliqués, jamais transférés deux fois	Courte et stable dans le temps	Le dépôt reconstitue directement l'instantané demandé

Par où passent les données : réseau, ports et chiffrement

Le choix du transport détermine ce qu'un attaquant présent sur le poste source peut atteindre. Un partage SMB monté en écriture est aussi ouvert à un rançongiciel qu'à votre script de sauvegarde. Un dépôt SSH avec commande forcée en mode ajout seul, non.

Chiffrez côté client, avant l'envoi, plutôt que de compter sur le chiffrement au repos du prestataire. restic et Borg chiffrent le dépôt en AES-256 avec authentification des données, donc l'hébergeur ne voit qu'un tas de blocs opaques. La clé ou la phrase de passe doit être conservée hors du périmètre sauvegardé : un secret stocké uniquement sur le serveur que vous sauvegardez disparaît avec lui.

Comptez la première sauvegarde en heures, pas en minutes. 1 To sur un lien à 200 Mb/s en émission demande environ 11 heures à débit constant, et votre lien n'est pas constant. Pour un gros amorçage, expédier un disque chiffré au datacentre reste souvent plus rapide.

Transport	Port par défaut	Remarque
rsync ou sftp via SSH	22/TCP	Chiffré de bout en bout, facile à filtrer et à restreindre par clé
Démon rsync (rsync://)	873/TCP	En clair par défaut, à réserver au LAN ou à un tunnel
SMB / CIFS	445/TCP	Un partage monté en écriture est atteignable par tout processus du poste
NFS	2049/TCP	Contrôle par export et par IP, root_squash conseillé
iSCSI	3260/TCP	Le volume apparaît comme un disque local, donc chiffrable comme tel
S3 et compatibles	443/TCP	HTTPS, clé d'accès dédiée, verrou d'objet disponible

Rançongiciel : une sauvegarde joignable est une sauvegarde perdue

Le code malveillant chiffre tout ce que l'utilisateur peut écrire. Si le NAS est monté en Z: avec les droits en écriture, la sauvegarde part avec le reste. Sous Windows, la première action de nombreuses familles est vssadmin delete shadows /all, qui efface les clichés instantanés du volume avant même de commencer le chiffrement.

La parade tient en deux idées. Inverser le sens du flux : c'est le serveur de sauvegarde qui va chercher les données avec un compte en lecture seule sur la source, et la source ne détient aucun identifiant vers le dépôt. Rendre la rétention non révocable : même un compte compromis ne peut pas raccourcir la durée de conservation.

Calez la rétention sur le délai de découverte, pas sur la place disque. Un intrus qui reste discret trois semaines avant de déclencher le chiffrement rend une rétention de sept jours totalement inutile.

• Stockage objet avec verrou de rétention (S3 Object Lock en mode conformité) : l'objet ne peut être ni écrasé ni supprimé avant l'échéance, y compris par le compte propriétaire.
• Dépôt en ajout seul : borg serve --append-only côté serveur, ou le serveur REST de restic lancé avec --append-only. Le client peut écrire de nouvelles données, jamais effacer les anciennes.
• Copie hors ligne : bande LTO éjectée après le job, disque de rotation débranché. Une LTO-9 stocke 18 To natifs, 45 To annoncés en compressé.
• Snapshots ZFS envoyés par zfs send vers une machine dédiée qui n'accepte aucune connexion entrante depuis le parc de production.
• Compte de sauvegarde séparé du domaine, avec authentification à deux facteurs sur la console du prestataire.

Tester la restauration, mesurer RPO et RTO

Deux indicateurs suffisent à cadrer une stratégie. Le RPO est la quantité de travail que vous acceptez de perdre, c'est-à-dire l'écart maximal entre deux sauvegardes. Le RTO est le délai admissible avant remise en service. Sauvegarde à 2 h du matin, panne à 17 h : votre RPO réel est de 15 heures de production perdue, quel que soit le contrat signé.

Un piège fréquent concerne les bases de données. Copier à chaud les fichiers d'un moteur InnoDB ou PostgreSQL avec cp ou rsync produit une copie incohérente qui refuse de démarrer au pire moment. Passez par mysqldump --single-transaction --routines --triggers, par pg_dump -Fc, ou par un snapshot pris après mise en quiescence via VSS ou l'API du moteur.

Restaurer un fichier texte ne prouve rien sur une base de 400 Go. Programmez une restauration réelle deux fois par an au minimum, chronomètre en main, sur du matériel qui n'est pas le serveur d'origine, et notez le temps obtenu : c'est votre RTO mesuré, pas celui de la plaquette.

Sur le plan réglementaire, l'article 32.1.c du RGPD impose la capacité à rétablir la disponibilité des données à caractère personnel et l'accès à celles-ci dans des délais appropriés en cas d'incident physique ou technique, et le point d) une procédure de test et d'évaluation régulière. Le texte ne fixe ni fréquence ni durée chiffrée : vous choisissez, vous documentez, vous prouvez.

• Vérifier l'intégrité du dépôt sans tout relire : restic check --read-data-subset=10% une fois par semaine, la totalité une fois par trimestre.
• Contrôler les empreintes d'une restauration partielle : sha256sum -c sur un lot de fichiers témoins.
• Recharger réellement le dump SQL dans une instance vide et lancer une requête métier connue.
• Démarrer la VM restaurée dans un réseau isolé et vérifier que le service répond.
• Surveiller l'absence de sauvegarde autant que l'échec : un job silencieux qui n'a plus tourné depuis 40 jours ne remonte aucune alerte s'il n'y a pas de supervision sur la date du dernier instantané.

Questions fréquentes

Un NAS en RAID est-il une sauvegarde ?

Non. Le RAID protège de la défaillance d'un ou deux disques et maintient le service, rien de plus. Une suppression, un chiffrement par rançongiciel, un incendie ou une surtension sur l'alimentation touchent tous les disques de la grappe simultanément. Le NAS peut héberger une sauvegarde, à condition qu'il reçoive des copies versionnées d'un autre système et qu'il ne soit pas monté en écriture permanente sur les postes.

Google Drive, OneDrive ou Dropbox suffisent-ils comme sauvegarde ?

Ce sont des services de synchronisation. Un fichier supprimé ou chiffré localement voit sa modification propagée au cloud, souvent en quelques secondes. Ils conservent bien un historique de versions et une corbeille, généralement limitée à 30 jours selon l'offre, ce qui dépanne pour une erreur isolée mais ne couvre ni une corruption découverte tardivement ni la fermeture du compte. Ils comptent comme la copie hors site du 3-2-1, pas comme la stratégie entière.

Combien de temps faut-il conserver les sauvegardes ?

Une rotation classique de type grand-père, père, fils garde 7 sauvegardes quotidiennes, 4 hebdomadaires et 12 mensuelles, ce qui couvre un an avec 23 points de restauration. Le vrai critère est le délai pendant lequel une corruption peut passer inaperçue dans votre contexte, auquel s'ajoutent les durées légales de conservation propres à vos documents comptables ou contractuels.

Faut-il chiffrer une sauvegarde, et où garder la clé ?

Oui, dès qu'elle sort de vos locaux ou qu'elle transite sur un réseau que vous ne maîtrisez pas. Le chiffrement côté client, tel que le pratiquent restic ou Borg en AES-256, garantit que l'hébergeur ne manipule que des blocs opaques. La clé ne doit jamais résider uniquement sur la machine sauvegardée : gestionnaire de secrets externe, coffre-fort d'entreprise, ou copie papier en armoire fermée avec un deuxième exemplaire chez une personne de confiance.

À quelle fréquence tester la restauration ?

Deux restaurations complètes par an constituent un plancher raisonnable pour un système de production, avec des restaurations partielles mensuelles pour vérifier la chaîne. Ajoutez un test après tout changement structurel : migration de serveur, changement d'outil, nouvelle version majeure du moteur de base de données. Notez la durée obtenue, elle vaut plus que n'importe quelle estimation théorique.

Testez vos connaissances

À lire aussi

chiffrement · cloud · confidentialite des donnees · anti malware