Les sauvegardes ne sont pas simples : la complexité cachée des stratégies de restauration
En bref
- Une sauvegarde efficace exige bien plus que copier des fichiers ailleurs : il faut gérer des snapshots avec la bonne fréquence, déduplication, rotation GFS, et point-in-time recovery.
- La plupart des gens ne sauvegardent pas, ce qui peut être rationnel si le risque perçu est faible ; pour les autres, les tests de restauration sont essentiels.
- Les commentateurs ajoutent des couches supplémentaires souvent oubliées : consistency groups pour les bases de données, sparse files, ACLs, et la surveillance que la sauvegarde s'exécute vraiment.
Ce que dit la source
L'article démarre par un constat : la plupart des gens subiront une perte de données, mais peu sont préparés. L'auteur partage une anecdote personnelle (formatage accidentel d'un disque externe contenant les photos familiales) pour montrer que derrière chaque désastre se cache une série d'erreurs qu'on ne peut pas imputer à une seule personne. Il affirme qu'une sauvegarde vraie doit répondre à plusieurs exigences simultanées : être une copie ailleurs (prévention contre les défaillances matérielles), pouvoir remonter le temps (prévention contre les erreurs logicielles ou les ransomwares), et respecter un objectif de point de récupération (RPO) cohérent avec l'acceptabilité métier de la perte de données.
- Une simple copie miroir (RAID 1) n'est pas une sauvegarde : elle n'offre aucune protection contre les erreurs logicielles, la suppression accidentelle ou les ransomwares.
- Le compromis entre fréquence des snapshots et stockage se résout par une granularité changeante : snapshots quotidiens conservés 14 jours, hebdomadaires sur 7 semaines, mensuels sur 12 mois (GFS-rotated).
- La déduplication par hard links (approche rsnapshot) économise massivement du stockage en stockant une seule copie d'un fichier et en créant des références depuis chaque snapshot.
- Plusieurs outils populaires ressortent du fil : ZFS avec sanoid/syncoid, Restic + Backrest, rear (ReaR) pour Oracle Linux, ou clonage avec CCC (Carbon Copy Cloner).
- Une sauvegarde n'est utile que testée : l'article insiste sur l'importance des tests de restauration, et les commentateurs corrigent : c'est la restauration qu'on paie réellement, pas la sauvegarde.
Dans les commentaires
Débat partagé : le fil oscille entre accord technique (les complications sont réelles) et scepticisme pragmatique (la plupart n'en ont pas besoin, et ça va). Les commentateurs apportent des cas concrets d'erreurs graves (sauvegarde supprimant accidentellement la source, OneDrive avec termes de service changeants, cartes SD défaillantes) qui valident l'analyse, mais quelques-uns contestent l'universalité du principe en notant que 99 % des gens ne sauvegardent pas et que c'est probablement correct pour eux.
- Plusieurs commentateurs soulignent que derrière chaque défaillance de sauvegarde se cache une complexité rarement mentionnée : consistency groups (risque de snapshots incohérents quand plusieurs processus accèdent au stockage), ACLs, sparse files, symlinks.
- Objection majeure : l'article énonce une vérité universelle (« tout le monde perdra des données »), mais un commentateur remet en question sa validité empirique, arguant que pour 99 % des gens, ne pas sauvegarder est une décision rationnelle étant donné le risque réel et l'effort requis.
- Plusieurs retours d'expérience montrent que les sauvegardes elles-mêmes sont des activités à haut risque : un script errant peut supprimer la source pendant qu'on récupère de l'espace pour la nouvelle sauvegarde ; les processus automatisés peuvent être oubliés lors d'une migration système.
- Consensus sur la prévention : tester les restaurations n'est pas optionnel, et certains rappellent la maxime que dans le secteur de la sauvegarde, c'est la restauration qu'on paie, pas la sauvegarde elle-même.
Alternatives citées : ZFS (avec sanoid/syncoid), Restic (+ Backrest pour orchestration), rear (ReaR, pour bare metal recovery), Carbon Copy Cloner (CCC, pour clonage macOS), rsnapshot (déduplication par hard links), OneDrive (mentionné en contre-exemple négatif).
Notre lecture
L'article fait un travail pédagogique solide en dépliant la complexité réelle : une « bonne » sauvegarde n'est pas un produit clé en main, mais un assemblage de choix technologiques et de compromis (fréquence, rétention, déduplication, rotation, offsite). Pour une organisation avec un RPO défini et de vrais enjeux (service critique, données client), c'est important à digérer et à tester. Pour beaucoup d'individus ou de petites équipes, l'article valide que quelque chose (même imparfait) vaut mieux que rien. Le point aveugle que les commentateurs révèlent : la complexité opérationnelle et les couches cachées (consistency, ACLs, monitoring de la sauvegarde elle-même) suggèrent que la plupart des organisations qui croient avoir une sauvegarde solide ont probablement des failles. À surveiller et à tester si vous avez des données critiques.