Pourquoi les sauvegardes dédupliquées paraissent-elles plus petites que leur empreinte de restauration ?

Eva Wong est la rédactrice technique et bricoleuse résidente chez ZimaSpace. Geek depuis toujours, passionnée par les homelabs et les logiciels open source, elle se spécialise dans la traduction de concepts techniques complexes en guides accessibles et pratiques. Eva croit que l’auto-hébergement doit être amusant, pas intimidant. À travers ses tutoriels, elle donne à la communauté les moyens de démystifier les configurations matérielles, depuis la construction de leur premier NAS jusqu’à la maîtrise des conteneurs Docker.

Les sauvegardes dédupliquées paraissent plus petites, car les blocs répétés ne sont stockés qu’une seule fois, tandis qu’une restauration reconstruit chaque fichier logique et chaque copie indépendante.

Dix images de machines virtuelles peuvent partager plusieurs gigaoctets de blocs identiques du système d’exploitation dans un dépôt de sauvegarde. Leur restauration sur un système de fichiers ordinaire recrée dix espaces d’adressage, sauf si la destination prend également en charge le partage compatible, la gestion des fichiers creux ou la compression. La taille du dépôt et la capacité de restauration décrivent donc des représentations différentes, avec des règles d’allocation et une surcharge différentes sur le système de fichiers cible sélectionné de manière sécurisée.

La déduplication stocke une seule fois l’identité et la référence plusieurs fois

Le logiciel de sauvegarde divise les données en blocs, calcule leur empreinte et ne stocke que les blocs qui ne sont pas déjà présents. Les manifestes conservent les informations indiquant quels blocs appartiennent à chaque fichier et à chaque point de restauration. Le dépôt peut représenter de nombreuses copies logiques avec une seule charge utile physique accompagnée de références.

Une présentation de la déduplication des sauvegardes explique comment les copies redondantes sont éliminées du stockage des sauvegardes. L’économie dépend du contenu répété, et non simplement du nombre de fichiers.

La restauration inverse cette correspondance. Chaque fichier reçoit ses octets dans l’ordre à la destination demandée. Si la cible ne prend pas en charge le partage de blocs, les blocs répétés occupent à nouveau des extensions distinctes. La réduction des données était une propriété du dépôt, et non la garantie que chaque cible de restauration reste aussi compacte.

La compression, la gestion des fichiers creux et les métadonnées accentuent l’écart

La compression réduit le nombre d’octets stockés en fonction de l’entropie du contenu. Les fichiers creux omettent les longues régions de zéros, mais une option de restauration peut matérialiser ces espaces vides. Les unités d’allocation, les sommes de contrôle, les attributs étendus et les métadonnées du système de fichiers ajoutent une surcharge sur la destination que les récapitulatifs du dépôt peuvent exclure.

Une explication du stockage distingue les fichiers creux de la taille allouée : un fichier peut indiquer une grande longueur logique tout en utilisant moins de blocs physiques. Les outils de restauration doivent préserver explicitement les espaces vides pour conserver cette économie.

L’inverse peut également se produire. Une destination compressée ou un clone avec copie à l’écriture peut conserver les données restaurées dans un espace inférieur à leur taille logique. Il n’existe pas de multiplicateur universel permettant de convertir les octets du dépôt en octets restaurés, car la représentation, l’ensemble de rétention et le système de fichiers cible jouent tous un rôle.

Situations où la déduplication n’est pas la cause principale

L’explication ne tient pas lorsqu’un seul fichier non dupliqué augmente de manière inattendue. Le chiffrement, les médias déjà compressés, les formats d’exportation de bases de données ou une modification du provisionnement fin peuvent alors être prépondérants. Un catalogue de sauvegarde peut également n’afficher que les données uniques d’un périmètre donné, tandis que la restauration inclut plusieurs instantanés sélectionnés.

Une discussion technique sur le taux de déduplication souligne qu’il faut distinguer les tailles logiques et physiques lors de la présentation des taux de déduplication. Les taux dépourvus de périmètre peuvent induire en erreur lors de la planification de capacité.

Le mécanisme cesse également de s’appliquer si les empreintes ou le nombre de fichiers restaurés diffèrent de ceux de la sauvegarde sélectionnée. Le problème relève alors de la sélection ou de l’intégrité, et non d’une expansion attendue. Des octets de sauvegarde moins nombreux ne justifient pas de sous-dimensionner l’espace temporaire avant vérification.

Mesurez une restauration au lieu de faire confiance au ratio

Choisissez un ensemble de restauration représentatif et consignez les octets logiques sources, les octets uniques du dépôt, les octets compressés, les extensions creuses, le nombre de fichiers et l’unité d’allocation cible. Effectuez la restauration dans une destination isolée en utilisant à la fois des options de préservation des fichiers creux et les options par défaut, puis vérifiez les empreintes et l’espace alloué.

Utilisez un plan de stockage avec stockage de modèles partagé afin que la destination de test ne puisse pas saturer les services actifs. Conservez la rétention du dépôt et les paramètres de compression de la cible inchangés lors de la comparaison des exécutions.

Dimensionnez la récupération en fonction de la plus grande des deux valeurs suivantes : la sortie allouée mesurée et la taille logique du jeu de données augmentée d’une marge de fonctionnement, et non en fonction du nombre d’octets du dépôt dédupliqué. Si la préservation des fichiers creux modifie le résultat, documentez cette dépendance. Si l’identité ou le nombre de fichiers change, arrêtez-vous et corrigez la restauration avant d’optimiser la capacité.

Centre Tech & IA

Plus à lire

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.