De nos jours, les logiciels de sauvegarde sont confrontés à des volumes de données de plus en plus importants. Afin d’optimiser les processus de sauvegarde, différentes stratégies ont été imaginées au fil des années. Nous allons les présenter rapidement, avant vous présenter la sauvegarde avec les mécanismes de Content Defined Chunking.
La sauvegarde dite « incrémentielle » consiste à ne sauvegarder que les fichiers qui ont changé depuis la dernière sauvegarde.
Ce mécanisme de sauvegarde permet de ne pas avoir à sauvegarde l’entièreté des données à chaque sauvegarde. Toutefois, l’inconvénient est évidemment que lors du moindre changement d’un fichier, celui-ci doit être intégralement re-sauvegardé.
La sauvegarde en mode « bloc » consiste à ne sauvegarder que les blocs de données qui ont changé depuis la dernière sauvegarde : un bloc étant une morceau (de taille fixe ou variable) d’un fichier, par exemple en décomposant un fichier en des blocs équivalent de 1 Mo.
Ce mécanisme fonctionne bien et permet une véritable optimisation de la bande passante par rapport à la sauvegarde incrémentielle, si les parties modifiées du fichier se trouvent sur seulement quelques blocs. Mais si on ajoute un octet au début du fichier, alors tous les blocs seront modifiés et on revient à de la sauvegarde incrémentielle.
La sauvegarde avec déduplication à la cible (en post-process) supprime les données redondantes après leur écriture sur le stockage de sauvegarde, les données dupliquées sont supprimées et remplacées par un pointeur vers la première itération du bloc.
Elle permet d’optimiser l’espace de sauvegarde, mais n’optimise pas le nombre de blocs à sauvegarder et donc la consommation de bande passante.
La déduplication à la source qui évite l’écriture de blocs de sauvegarde en double depuis le serveur à sauvegarder et les remplace par un pointeur vers leur première version dans le même ensemble de sauvegarde.
Cette méthode de sauvegarde est basée sur des méthodes de hachage de fichiers.
Puis vient enfin la sauvegarde avec des mécanismes de déduplication de type « Content Defined Chunking ».
Cette sauvegarde utilise des mécanismes de blocs variables et se basent sur du « hachage roulant ». Elle permet ainsi de reconnaître à nouveau les mêmes morceaux lorsqu’ils sont déplacés ou légèrement modifiés.
Quels sont les besoins couverts par ces mécanismes de déduplication ?
Les besoins de déduplication sont multiples, en voici quelques exemples :
Selon des études recherches de déduplication réalisées par Microsoft (Meyer et Bolosky, 2012 , El-Shimi et al., 2012 ), et EMC ( Wallace et al., 2012 , Shilane et al., 2012 ), plus de 50% jusqu’à 85% des données seraient redondantes dans une infrastructure conséquente et pourraient être dédupliquées.
En revanche, les impacts de ces solutions de déduplication à la source peuvent être conséquents :
Les limites sur la déduplication basée sur des blocs de taille fixe ou variable ont été contournées avec les mécanismes de Content Defined Chunking.
Terme que l’on pourrait traduire littéralement par « Fragmentation optimisée d’un contenu ».
L’idée générale est de savoir :
Note : un « motif » est un schéma de données qui se répète, un bloc de petite taille (par exemple de taille de 1 Mo).
Pour ce faire, les sauvegardes de données avec « Content Defined Chunking » utilisent alors des mécanismes de « Hachage Roulant » (ou glissant) qui permet d’essayer de trouver ces motifs en glissant dans le fichier.
Le hachage roulant est une fonction de hachage où l’entrée (par exemple un fichier) est hachée dans une fenêtre (de plusieurs octets) qui se déplace à travers l’entrée (le fichier) pour trouver des blocs de données qui sont déjà sauvegardés (les motifs).
Toute l’intelligence (et l’optimisation) de ces algorithmes consiste à utiliser le moins de ressources techniques (CPU/RAM/IO) pour trouver ces blocs de données.
Historiquement, les premières implémentations de Content Defined Chunking ont utilisé l’algorithme de Rabin-Karp (1987) et ont été optimisées par de nombreux travaux de R&D (empreinte de Rabin, fastCDP, …).
Nous vous conseillons d’explorer les ressources ci-dessus citées si le sujet vous intéresse en profondeur.
Restic est une solution de sauvegarde utilisant les deux mécanismes présentés dans cet article. Nous vous proposons un article approfondissant le sujet de cette solution de sauvegarde.
76 rue Denfert-Rochereau
69004 Lyon
Tel : 04.28.29.79.01
© 2014–2022 NUABEE. TOUS DROITS RÉSERVÉS.
Cookie | Durée | Description |
---|---|---|
cookielawinfo-checkbox-analytics | 11 months | This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Analytics". |
cookielawinfo-checkbox-functional | 11 months | The cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Functional". |
cookielawinfo-checkbox-necessary | 11 months | This cookie is set by GDPR Cookie Consent plugin. The cookies is used to store the user consent for the cookies in the category "Necessary". |
cookielawinfo-checkbox-others | 11 months | This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Other. |
cookielawinfo-checkbox-performance | 11 months | This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Performance". |
viewed_cookie_policy | 11 months | The cookie is set by the GDPR Cookie Consent plugin and is used to store whether or not user has consented to the use of cookies. It does not store any personal data. |