Data Domain : Questions fréquentes sur la compression

Résumé: Cet article répond aux questions les plus fréquentes concernant la compression. Les Data Domain sont indépendants du type de données. Data Domain utilise des algorithmes de compression qui ne sauvegardent que des données uniques : les modèles dupliqués ou les sauvegardes multiples ne sont stockés qu’une seule fois. ...

Cet article concerne Cet article ne concerne pas Cet article n’est associé à aucun produit spécifique. Toutes les versions du produit ne sont pas identifiées dans cet article.
Consulter d’autres ressources

Instructions

Sommaire

|
 
Les taux de compression standard sont de 20:1 sur plusieurs semaines de sauvegardes quotidiennes et incrémentielles. Le type de données affecte le taux de compression : les fichiers image compressés, les bases de données et les archives compressées (telles que les fichiers .zip) ne se compressent pas correctement.
 

Les sauvegardes incrémentielles et complètes utilisent-elles le même espace disque ?

Idéalement, cela est vrai. En pratique, la sauvegarde complète utilise un peu plus d’espace que la sauvegarde incrémentielle pour les raisons suivantes. Ces raisons expliquent également pourquoi une sauvegarde complète sans modification des données consomme toujours une quantité positive d’espace.
  • Les métadonnées occupent environ 0,5 % de la taille logique de la sauvegarde. Supposons que :
    • La taille logique de l’intégralité est de 100 Go
    • La taille logique de l’incrément est de 2 Go
    • Les compressions incrémentielles à 1 Go
    • ... puis le full prend au moins 1,5 Go
  • Le moteur de compression DD réécrit certains segments de données dupliqués à des fins de performances. Plus la localisation des données liées aux changements est médiocre, plus le nombre de doublons écrits sera important. Les doublons sont ensuite récupérés par le nettoyage de la mémoire (GC) du système de fichiers. Dans certains cas, environ 2 % de la taille logique est réécrite en double. En supposant ce niveau de doublons, l’intégralité peut prendre 1 Go (compressé) + 0,5 Go (métadonnées) + 2 Go (doublons) = 3,5 Go. La quantité de doublons écrits peut être contrôlée via un paramètre système, mais nous ne réglons généralement pas ce paramètre sur le terrain.
  • La segmentation des données peut varier légèrement d’une sauvegarde à l’autre en fonction de l’ordre dans lequel le client NFS envoie les données. Cet ordre n’est pas déterministe. En général, l’algorithme de segmentation tolère les décalages et les réordres. Cependant, cela crée également des segments « forcés », qui sont sujets à des changements et à des réorganiser. En général, environ 0,2 % des segments sont forcés, de sorte que l’on peut s’attendre à une utilisation beaucoup plus importante de l’espace.
 

Pourquoi 'filesys show space' et 'filesys show compression' afficher des chiffres différents ?

  • 'filesys show space' fournit le taux de compression en fonction de la taille logique des données stockées et de l’espace disque utilisé au moment de l’exécution de la commande.
  • 'filesys show compression' fournit le taux de compression basé sur la façon dont chaque fichier a été compressé au moment de sa création.
  • 'filesys show compression' est principalement utilisé pour la prise en charge et le débogage. En présence de suppressions de fichiers, 'filesys show compression' surestime le taux de compression.
 
Par exemple, supposons que :
  • La première sauvegarde complète bénéficie d’une compression x2
  • Une sauvegarde complète ultérieure sans aucune modification des données est compressée par 200
  • La première sauvegarde complète est supprimée
La sortie de 'filesys show space' afficherait un taux de compression de 2x, tandis que 'filesys show compression' afficherait un taux de compression de 200x, car le seul fichier existant à ce jour avait un taux de compression de 200x lors de sa création.
 
Dans l’exemple ci-dessus, après la deuxième sauvegarde, 'filesys show space' montrerait un rapport cumulé d’environ 4x. Le rapport cumulé s’améliorerait asymptotiquement vers 200x si vous continuiez avec plus de sauvegardes sans suppression.
 
Il y a d’autres différences mineures. L’option 'filesys show compression' command :
  • Ne tient pas compte du gaspillage au niveau du conteneur, surestimant ainsi davantage le taux de compression
  • Ne tient pas compte de l’élimination des doublons par compression globale, sous-estimant ainsi le taux de compression
  • Peut fournir des informations par fichier ou par répertoire, tandis que 'filesys show space' est limité à l’ensemble du système
  • Fournit la répartition entre la compression globale et la compression locale, tandis que 'filesys show space' ne le fait pas
 

Pourquoi 'filesys show compression last 24 hours' ne correspond pas aux attentes pour VTL ?

Pour VTL, la sortie de commandes telles que 'filesys show compression last 24 hours' ne répond souvent pas aux attentes sur la base d’autres sources telles que 'system show performance'.
 
Le problème se pose en raison d’une particularité dans 'filesys show compression'. En général, il affiche les statistiques cumulées dans les fichiers sélectionnés. Le qualificateur « dernières 24 heures » sélectionne les fichiers qui ont été mis à jour au cours des dernières 24 heures. Les statistiques continuent de s’accumuler depuis que le fichier a été créé ou tronqué à une taille nulle. Ainsi, si un fichier a été ajouté au cours des dernières 24 heures, 'filesys show compression last 24 hours' affiche ses statistiques cumulées avant les dernières 24 heures.
 
Les fichiers de sauvegarde dans les environnements non VTL ne sont écrits qu’une seule fois, de sorte qu’il y a peu de différence entre les fichiers mis à jour et les fichiers créés. Avec VTL, les sauvegardes peuvent être ajoutées aux fichiers sur bande existants. Prenons l’exemple d’une bande de 100 Go remplie jusqu’à 50 Go. Si 10 Go de données ont été ajoutés à cette bande au cours des dernières 24 heures, 'filesys show compression last 24 hours' afficherait les « octets d’origine » du fichier écrits à 60 Go.
 

Comment le taux de compression cumulé est-il calculé ?

Les taux de compression individuels ne s’additionnent pas de manière linéaire.
 
Supposons que le taux de compression soit de 2x sur la première sauvegarde complète et que celui de la deuxième sauvegarde complète soit de 20x. La compression cumulative n’est pas (2 + 20) / 2 = 11xMais 2 / (1/2 + 1/20) = 3.64x.
 
En général, les taux de compression plus faibles ont plus d’impact que les taux élevés sur le taux de compression cumulé.
 
Supposons que l’option ith La sauvegarde a une taille logique si et taux de compression ci. Ensuite, le taux de compression cumulé pour k Les sauvegardes peuvent être calculées comme suit : 
C = (total logical size)/(total space used)
total logical size = s1 + s2 + .. + sk
total space used = s1/c1 + s2/c2 + ... + sk/ck
 
Souvent, les tailles logiques sont à peu près les mêmes. Dans ce cas, le calcul ci-dessus se simplifie comme suit :
C = k / (1/c1 + 1/c2 + ... + 1/ck)
 
Par exemple, si :
  • La première sauvegarde complète bénéficie d’un taux de compression x3
  • Chaque sauvegarde complète suivante bénéficie d’une compression de 30x
  • La période de rétention est de 30 jours

L’utilisateur voit une compression cumulée de 30 / (1/3 + 29/30), ou 23x.

 

Comment la compression Data Domain fonctionne-t-elle ?

Nous répondons en détail à cette question dans un article séparé : Comprendre la compression Data Domain
 

Data Domain prend-il en charge le multiplexage ?

Les données multiplexées de l’application de sauvegarde entraînent une déduplication globale très médiocre. Pour plus d’informations, consultez cet article : Data Domain : Multiplexage dans un logiciel de sauvegarde
 

Avec la réplication de répertoire 1-to-1, pourquoi le réplica affiche-t-il une meilleure compression globale ?

En général, cela est dû à des variations dans le niveau des segments dupliqués écrits sur le système :
  • Les données stockées à la source ont été dédupliquées une seule fois, par rapport aux données précédentes stockées à la source.
  • Les données envoyées sur le réseau ont été dédupliquées une seule fois, par rapport aux données stockées sur le réplica.
  • Les données stockées sur la réplique ont été dédupliquées deux fois, une première fois lorsque les données ont été envoyées sur le câble, et une seconde fois lorsque les données reçues sont écrites sur le réplica.
Le processus de déduplication laisse quelques doublons, et donc les données qui ont été dédupliquées plusieurs fois ont moins de doublons. Les données stockées à la source et envoyées sur le réseau sont dédupliquées une seule fois. Elles sont donc à peu près identiques, en supposant que les données stockées à la source sont similaires à celles stockées sur le réplica. Les données stockées sur le réplica sont dédupliquées deux fois, de sorte qu’elles sont mieux compressées.
 
Le nettoyage du système de fichiers supprime la plupart des doublons. Ainsi, après avoir effectué un nettoyage sur la source et le réplica, la quantité de données stockée devrait être approximativement égale.
 

Quel est le changement dans la compression lors de l’utilisation de lz, gzfastet gz Paramètres de compression locale ?

Utilisez la commande suivante pour modifier l’algorithme de compression local utilisé dans un Data Domain :
filesys option set compression {none | lz | gzfast | gz}
 
Remarque : Le système de fichiers doit être arrêté avant de modifier le type de compression local. Il peut ensuite être redémarré immédiatement après que l’option de compression a été définie.
 
En général, l’ordre de compression est le suivant :
lz < gzfast < gz
 
Saisissez Comp. attendue. Charge processeur
aucune 1 x 0x
Lz 2 fois 1 x
gzfast 2,5 fois 2 fois
Gz 3x 5 fois plus important
 
La différence est à peu près la suivante :
  • lz to gzfast offre ~15 % de compression en plus et consomme 2 fois plus de processeur
  • lz to gz offre ~30 % de compression en plus et consomme 5 fois plus de processeur
  • gzfast to gz Offre ~10 à 15 % de compression en plus
Notez que la modification de la compression locale affecte d’abord les nouvelles données écrites sur le Data Domain après la modification. Les anciennes données conservent leur format de compression précédent jusqu’au cycle de nettoyage suivant. Le prochain cycle de nettoyage copie toutes les anciennes données dans le nouveau format de compression. Cela entraîne une exécution beaucoup plus longue du nettoyage et une augmentation des ressources processeur nécessaires.
 
Si le système dispose déjà d’un processeur faible, en particulier si les sauvegardes et la réplication s’exécutent simultanément, cela peut ralentir les sauvegardes et. Le client peut vouloir planifier explicitement une période spécifique pour effectuer cette conversion.

Informations supplémentaires

Références en matière de connaissances :

Produits concernés

Data Domain

Produits

Data Domain
Propriétés de l’article
Numéro d’article: 000022100
Type d’article: How To
Dernière modification: 24 avr. 2026
Version:  12
Trouvez des réponses à vos questions auprès d’autres utilisateurs Dell
Services de support
Vérifiez si votre appareil est couvert par les services de support.