Comment le découpage défini par le contenu réduit-il les données de sauvegarde en double ?

Le découpage défini par le contenu améliore la déduplication des sauvegardes en choisissant les limites des blocs à partir du contenu des fichiers, ce qui permet de réutiliser les régions inchangées après des insertions ou des suppressions.

Les sauvegardes incrémentielles contiennent souvent de gros fichiers dont la majeure partie reste inchangée entre les versions : images de disques virtuels, archives de courriels, bases de données copiées sous forme de fichiers, ensembles de projets et bibliothèques multimédias exportées. Si chaque bloc commence à un décalage fixe, l’insertion d’un petit en-tête au début peut décaler toutes les limites suivantes, même si les octets ultérieurs sont identiques. Le découpage défini par le contenu fait suivre la segmentation aux motifs locaux des octets plutôt qu’aux positions absolues, afin que la sauvegarde puisse se resynchroniser avec les anciens blocs après la région modifiée.

Des limites de taille fixe peuvent transformer une petite modification en nombreux nouveaux blocs

Un découpeur à taille fixe coupe le fichier à des positions telles que tous les 1 Mio, quel que soit le contenu des octets. Lorsque des octets sont insérés près du début, les flux ancien et nouveau sont décalés l’un par rapport à l’autre ; chaque bloc fixe suivant contient donc une combinaison différente d’octets, même si la quasi-totalité du contenu sous-jacent est restée identique.

Le découpage défini par le contenu a été développé pour la déduplication, car les points de coupe dérivés du contenu détectent une redondance que les décalages fixes peuvent manquer après des modifications locales. L’avantage n’est pas que le CDC prédit quels fichiers sont similaires ; il fournit au dédupliqueur une segmentation capable de résister au décalage des positions.

Si un fichier entier est remplacé par des octets sans rapport, aucun algorithme de découpage ne peut créer artificiellement du contenu en double. Le CDC est surtout utile lorsque les versions partagent de grandes régions d’octets inchangées, mais que ces régions ont été déplacées par rapport au début du fichier.

Une empreinte glissante recherche des points de coupe locaux dans le flux d’octets

Le CDC déplace une fenêtre sur les données d’entrée et met à jour une empreinte à mesure que des octets entrent dans cette fenêtre ou en sortent. Une limite est déclarée lorsque l’empreinte satisfait une condition configurée, sous réserve de règles de taille minimale et maximale des blocs qui empêchent la création de blocs minuscules ou énormes.

Le découpeur de Borg utilise une empreinte glissante du contenu afin que l’évaluation du prochain point de coupe potentiel ne nécessite pas de hacher à nouveau toute la fenêtre. Comme l’empreinte dépend des octets voisins, la même séquence locale peut déclencher la même coupe, même si son décalage absolu dans le fichier a changé.

L’empreinte glissante est donc un mécanisme de recherche des limites, et non l’identité finale des données de sauvegarde stockées. Considérer ces deux hachages comme interchangeables affaiblirait l’explication de l’endroit où la déduplication décide réellement de réutiliser les données.

Les tailles minimale, maximale et moyenne des blocs influencent également la recherche des limites. Elles déterminent la fréquence à laquelle les coupes potentielles sont examinées et la quantité de métadonnées que le dépôt doit gérer.

Le CDC se resynchronise après une modification au lieu de rester décalé indéfiniment

Après une insertion ou une suppression, la fenêtre glissante voit initialement des octets différents et produit des limites de blocs différentes autour de la modification. Dès qu’elle se déplace entièrement dans une région suffisamment longue et inchangée, elle peut retrouver les mêmes motifs de contenu locaux et recommencer à couper à des positions alignées sur celles de l’ancienne version.

Borg indique que les limites définies par le contenu peuvent rester stables par rapport au contenu inchangé, même lorsque des octets sont insérés ou supprimés ailleurs. Cette resynchronisation confine de nombreuses modifications à un petit nombre de nouveaux blocs au lieu d’invalider le reste du fichier.

Restic découpe lui aussi les fichiers en objets de longueur variable à l’aide d’une empreinte glissante, de sorte que les objets de longueur variable inchangés puissent être référencés à nouveau entre les instantanés. Le dépôt a toutefois besoin d’un index pour reconnaître les objets déjà stockés.

La distance de resynchronisation dépend des paramètres de découpage et du motif des octets modifiés ; le CDC ne garantit donc pas qu’un seul nouveau bloc apparaîtra pour chaque modification. Son avantage est une localité statistique : les modifications ont moins de chances de décaler toutes les limites suivantes.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

Un identifiant de bloc robuste détermine la réutilisation une fois la limite choisie

Trouver une limite indique seulement où se termine un bloc potentiel ; le dépôt doit encore déterminer si le contenu complet de ce bloc existe déjà. Cette seconde décision utilise un identifiant de contenu plus robuste ou un hachage authentifié calculé sur le bloc finalisé, puis recherche ce résultat dans l’index du dépôt.

Borg distingue explicitement le hachage utilisé pour déterminer les limites de l’identité cryptographique du bloc utilisée comme critère de déduplication. Restic référence également les objets stockés au moyen d’un hachage de contenu robuste, au lieu de considérer l’empreinte glissante comme la preuve que deux blocs sont identiques.

Cette conception en deux étapes clarifie le parcours de stockage : le hachage glissant choisit la segmentation potentielle ; le hachage de contenu identifie le bloc obtenu ; la recherche dans le dépôt décide s’il faut le stocker ou le réutiliser. Les économies de déduplication ne se produisent qu’au cours des deux dernières étapes, même si le CDC rend ces correspondances beaucoup plus susceptibles de résister aux modifications.

La taille des blocs et la transformation des données définissent le compromis entre calcul et économies

Des blocs moyens plus petits isolent les modifications avec davantage de précision, mais augmentent le nombre d’empreintes, d’entrées d’index, de recherches, d’objets de métadonnées et de références de stockage. Des blocs plus grands réduisent la surcharge d’indexation, mais permettent à une petite modification d’invalider une unité plus importante de données réutilisables.

FastCDC vise à réduire la surcharge processeur du hachage glissant tout en conservant une forte détection de la redondance, montrant que le découpage lui-même peut devenir un coût significatif avant même l’élimination des octets dupliqués. Les meilleurs paramètres équilibrent le travail de découpage, la taille de l’index et le profil de similarité de l’ensemble de sauvegardes.

La transformation effectuée avant le découpage peut également supprimer la similarité des octets dont dépend le CDC. Un chiffrement utilisant des valeurs uniques différentes, les formats qui réécrivent la majeure partie d’un fichier après une petite modification logique ou certaines méthodes de compression peuvent faire paraître deux versions logiquement similaires sans rapport l’une avec l’autre au niveau des octets.

L’analyse de ZimaSpace consacrée à la surcharge mémoire de l’index de déduplication examine l’autre aspect de ce compromis : une réutilisation plus fine nécessite davantage de métadonnées et de mémoire pour suivre ce qui existe déjà. Le CDC est utile lorsque l’espace de stockage récupéré dépasse le coût supplémentaire du découpage et de l’indexation, et pas simplement parce que les blocs de taille variable semblent plus sophistiqués.