Il y a une question que presque tout le monde pose en souscrivant des sauvegardes : si mon serveur occupe 200 Go et que je veux garder trente copies quotidiennes, ai-je besoin de six téraoctets ? La réponse est non, et comprendre pourquoi change complètement la façon de concevoir votre politique de rétention.
L’idée, sans jargon
Un système de sauvegarde moderne ne stocke pas des fichiers entiers : il découpe les données en petits blocs, calcule une empreinte de chaque bloc et ne stocke que les blocs qu’il n’avait pas déjà. Quand un bloc se répète, au lieu de le dupliquer, il pointe vers celui qui existe déjà.
La conséquence est directe. Sur un serveur typique, seule une infime fraction des données change d’une sauvegarde à la suivante : quelques journaux système, la base de données, quelques fichiers neufs. Le système d’exploitation, les bibliothèques, le code applicatif et la plupart des documents sont identiques, donc ils ne sont pas réécrits.
Les chiffres réels
Sur notre infrastructure, un serveur de 200 Go avec une activité normale laisse environ 2 à 5 Go de blocs nouveaux par sauvegarde quotidienne. Trente copies n’occupent pas 6 To : elles occupent de l’ordre de 250 à 350 Go au total, copie initiale complète incluse.
Et il existe un second effet encore plus visible : la déduplication fonctionne entre serveurs différents. Si vous exploitez dix machines sur le même Debian, le système de base est stocké une seule fois pour les dix. Sur un parc homogène, cela multiplie l’économie.
Ce que cela vous permet
Voici le côté pratique. Comme l’historique coûte peu, vous pouvez vous offrir une longue rétention sans faire exploser le budget. Et une longue rétention, c’est exactement ce qui vous sauve dans les deux scénarios les plus douloureux : le rançongiciel présent depuis des semaines, et l’erreur de données que personne n’a vue avant la clôture mensuelle.
Avec sept jours d’historique, ces deux cas finissent mal. Avec trente ou quatre-vingt-dix, vous avez où revenir.
Les limites honnêtes
La déduplication n’est pas magique, et il faut savoir quand elle n’aide pas :
- Les données déjà compressées ou chiffrées (vidéo, images, archives zip) dédupliquent à peine, car chaque version est totalement différente au niveau bloc.
- Les bases de données très actives réécrivent beaucoup : leur taux de changement réel est supérieur à celui d’un serveur web statique.
- La première sauvegarde est complète et ne bénéficie de rien. C’est la seule qui soit longue.
La contrepartie que personne ne mentionne
Comme les blocs sont partagés, un bloc corrompu affecterait toutes les sauvegardes qui le référencent. C’est pourquoi un système sérieux effectue une vérification périodique d’intégrité : il relit les blocs stockés, contrôle les empreintes et alerte si quelque chose ne concorde pas.
Si vous évaluez un service de sauvegarde, demandez s’il vérifie l’intégrité du dépôt et à quelle fréquence. C’est la question qui distingue un dépôt de sauvegardes d’un tas de fichiers.
Comment nous l’appliquons
Nos services de sauvegarde utilisent la déduplication par blocs avec vérification d’intégrité programmée. C’est pour cela que nous pouvons proposer de longues rétentions à des prix raisonnables, et que le panneau affiche les blocs nouveaux de chaque sauvegarde : c’est la métrique qui indique vraiment si vos données changent et si le système fonctionne toujours.