Data Domain: Häufig gestellte Fragen zur Komprimierung

Zusammenfassung: In diesem Artikel werden die häufigsten Fragen zur Komprimierung beantwortet. Data Domains sind unabhängig vom Datentyp. Data Domain verwendet Komprimierungsalgorithmen, die nur eindeutige Daten sichern – duplizierte Muster oder mehrere Backups werden nur einmal gespeichert. ...

Dieser Artikel gilt für Dieser Artikel gilt nicht für Dieser Artikel ist nicht an ein bestimmtes Produkt gebunden. In diesem Artikel werden nicht alle Produktversionen aufgeführt.
Andere Ressourcen ansehen

Weisungen

Inhaltsverzeichnis

|
 
Die typischen Komprimierungsraten liegen bei 20:1 über viele Wochen täglicher und inkrementeller Backups. Der Datentyp wirkt sich auf das Komprimierungsverhältnis aus: Komprimierte Image-Dateien, Datenbanken und komprimierte Archive (z. B. .zip-Dateien) lassen sich nicht gut komprimieren.
 

Wird bei inkrementellen und kompletten Backups derselbe Speicherplatz verwendet?

Idealerweise wäre dies der Fall. In der Praxis verwendet das komplette Backup aus den folgenden Gründen etwas mehr Speicherplatz als das inkrementelle Backup. Diese Gründe erklären auch, warum ein komplettes Backup, nachdem keine Änderungen an den Daten vorgenommen wurden, immer noch eine positive Menge an Speicherplatz belegt.
  • Die Metadaten nehmen etwa 0,5 % der logischen Größe des Backups ein. Nehmen wir an, dass:
    • Die logische Größe der vollständigen Datei beträgt 100 GB.
    • Die logische Größe des inkrementellen Volumes beträgt 2 GB
    • Die inkrementelle Komprimierung erfolgt auf 1 GB.
    • ... dann benötigt die volle mindestens 1,5 GB
  • Die DD-Komprimierungs-Engine schreibt einige doppelte Datensegmente zur Leistungssteigerung neu. Je schlechter die Datenlokalität der Änderungen ist, desto mehr Duplikate werden geschrieben. Die Duplikate werden später durch die automatische Speicherbereinigung (GC) des Dateisystems zurückgewonnen. In einigen Fällen werden ca. 2% der logischen Größe als Duplikat umgeschrieben. Unter der Annahme dieser Menge an Duplikaten kann die vollständige Erstellung 1 GB (komprimiert) + 0,5 GB (Metadaten) + 2 GB (Duplikate) = 3,5 GB in Anspruch nehmen. Die Anzahl der geschriebenen Duplikate kann über einen Systemparameter gesteuert werden. Diesen Parameter stellen wir aber in der Regel nicht vor Ort ein.
  • Die Datensegmentierung kann je nach Reihenfolge, in der der NFS-Client die Daten sendet, von Backup zu Backup leicht variieren. Diese Reihenfolge ist nicht deterministisch. Im Allgemeinen toleriert der Segmentierungsalgorithmus Verschiebungen und Neuordnungen. Es werden jedoch auch einige "erzwungene" Segmente erstellt, die anfällig für Verschiebungen und Neuanordnungen sind. In der Regel werden ca. 0,2 % der Segmente erzwungen, so dass mit einem deutlich höheren Speicherplatzverbrauch zu rechnen ist.
 

Warum tun Sie 'filesys show space' und 'filesys show compression' verschiedene Nummern anzeigen?

  • 'filesys show space' gibt das Komprimierungsverhältnis basierend auf der logischen Größe der gespeicherten Daten und dem Speicherplatz an, der zum Zeitpunkt der Ausführung des Befehls verwendet wird.
  • 'filesys show compression' gibt das Komprimierungsverhältnis basierend darauf an, wie jede Datei zum Zeitpunkt ihrer Erstellung komprimiert wurde.
  • 'filesys show compression' wird hauptsächlich für Support und Debugging verwendet. Wenn Dateien gelöscht werden, 'filesys show compression' überschätzt das Kompressionsverhältnis.
 
Nehmen wir beispielsweise Folgendes an:
  • Das erste komplette Backup erhält eine 2-fache Komprimierung
  • Ein nachfolgendes komplettes Backup ohne Datenänderungen erhält eine 200-fache Komprimierung
  • Das erste komplette Backup wird gelöscht
Die Ausgabe von 'filesys show space' würde ein Kompressionsverhältnis von 2x aufweisen, während 'filesys show compression' würde ein Komprimierungsverhältnis von 200x anzeigen, da die einzige Datei, die jetzt existiert, ein Komprimierungsverhältnis von 200x hatte, als sie erstellt wurde.
 
Im obigen Beispiel wird nach dem zweiten Backup 'filesys show space' würde ein kumulatives Verhältnis von etwa 4x ergeben. Das kumulative Verhältnis würde sich asymptotisch in Richtung 200-fach verbessern, wenn mit mehr Backups ohne Löschung fortgefahren würde.
 
Es gibt noch einige weitere kleine Unterschiede. Die 'filesys show compression' Befehl:
  • Verschwendung auf Containerebene wird nicht berücksichtigt, wodurch das Komprimierungsverhältnis weiter überschätzt wird
  • Berücksichtigt keine Duplikateliminierung durch globale Komprimierung, sodass das Komprimierungsverhältnis unterschätzt wird
  • Kann Informationen pro Datei oder pro Verzeichnis bereitstellen, während 'filesys show space' ist auf das gesamte System beschränkt
  • Stellt die Aufschlüsselung zwischen globaler und lokaler Komprimierung bereit, während 'filesys show space' nicht
 

Warum wird 'filesys show compression last 24 hours' entspricht nicht den Erwartungen an VTL?

Für VTL ist die Ausgabe von Befehlen wie 'filesys show compression last 24 hours' entspricht oft nicht den Erwartungen, die auf anderen Quellen beruhen, wie z. B. "system show performance'.
 
Das Problem tritt aufgrund einer Besonderheit in 'filesys show compression'. Im Allgemeinen werden kumulative Statistiken in ausgewählten Dateien angezeigt. Der Qualifizierer "letzte 24 Stunden" wählt Dateien aus, die in den letzten 24 Stunden aktualisiert wurden. Die Statistiken sind weiterhin kumulativ, seit die Datei erstellt oder zuletzt auf Größe Null gekürzt wurde. Wenn also in den letzten 24 Stunden eine Datei angehängt wurde, 'filesys show compression last 24 hours' zeigt die kumulativen Statistiken vor den letzten 24 Stunden an.
 
Backupdateien in Nicht-VTL-Umgebungen werden nur einmal geschrieben, sodass es kaum Diskrepanzen zwischen den aktualisierten und den erstellten Dateien gibt. Mit VTL können Backups an vorhandene Banddateien angehängt werden. Nehmen wir beispielsweise ein 100-GB-Band, das mit bis zu 50 GB gefüllt ist. Wenn in den letzten 24 Stunden 10 GB Daten an dieses Band angehängt wurden, 'filesys show compression last 24 hours' würde die "Original-Bytes" der Datei anzeigen, die mit 60 GB geschrieben wurden.
 

Wie wird das kumulative Komprimierungsverhältnis berechnet?

Einzelne Verdichtungsverhältnisse summieren sich nicht linear.
 
Nehmen wir an, dass die Komprimierung beim ersten kompletten Backup 2x und beim zweiten kompletten Backup 20x beträgt. Die kumulative Komprimierung ist nicht (2 + 20) / 2 = 11xAber 2 / (1/2 + 1/20) = 3.64xherunter.
 
Im Allgemeinen haben niedrigere Komprimierungsverhältnisse einen größeren Einfluss auf das kumulative Komprimierungsverhältnis als höhere.
 
Nehmen wir an, dass die ith Backup hat logische Größe si und Verdichtungsverhältnis ciherunter. Dann wird das kumulative Komprimierungsverhältnis für k Backups können wie folgt berechnet werden: 
C = (total logical size)/(total space used)
total logical size = s1 + s2 + .. + sk
total space used = s1/c1 + s2/c2 + ... + sk/ck
 
Die logischen Größen sind häufig ungefähr gleich. In diesem Fall vereinfacht sich die obige Berechnung wie folgt:
C = k / (1/c1 + 1/c2 + ... + 1/ck)
 
Zum Beispiel, wenn:
  • Das erste komplette Backup erhält eine 3-fache Komprimierung
  • Jede nachfolgende vollständige Auslastung erhält eine 30-fache Komprimierung
  • Die Aufbewahrungsfrist beträgt 30 Tage

Dem Nutzer wird eine kumulative Komprimierung von 30 / (1/3 + 29/30)oder 23x.

 

Wie funktioniert die Data Domain-Komprimierung?

Diese Frage wird in einem separaten Artikel ausführlich beantwortet: Grundlegendes zur Data Domain Compression
 

Unterstützt Data Domain Multiplexing?

Multiplex-Daten aus der Backupanwendung führen zu einer sehr schlechten globalen Deduplizierung. Weitere Informationen finden Sie in diesem Artikel: Data Domain: Multiplexing in Backupsoftware
 

Warum zeigt das Replikat bei der 1:1-Verzeichnisreplikation eine bessere globale Komprimierung an?

Dies ist in der Regel auf Schwankungen in der Anzahl der Duplikatsegmente zurückzuführen, die auf das System geschrieben werden:
  • Die an der Quelle gespeicherten Daten wurden einmal dedupliziert – im Gegensatz zu den zuvor an der Quelle gespeicherten Daten.
  • Die über die Leitung gesendeten Daten wurden einmal dedupliziert – im Vergleich zu den auf dem Replikat gespeicherten Daten.
  • Die auf dem Replikat gespeicherten Daten wurden zweimal dedupliziert, einmal, als die Daten gesendet wurden, und ein weiteres Mal, als die empfangenen Daten auf das Replikat geschrieben wurden.
Da der Deduplizierungsvorgang nur einige Duplikate hinterlässt, weisen Daten, die mehrmals dedupliziert wurden, weniger Duplikate auf. Die an der Quelle gespeicherten und dann gesendeten Daten werden einmal dedupliziert, sodass sie ungefähr identisch sind, vorausgesetzt, die an der Quelle und auf dem Replikat gespeicherten Daten sind ähnlich. Die auf dem Replikat gespeicherten Daten werden zweimal dedupliziert, sodass sie besser komprimiert werden können.
 
Bei der Dateisystembereinigung werden die meisten Duplikate entfernt. Daher sollte nach der Bereinigung der Quelle und des Replikats die Menge der dort gespeicherten Daten in etwa gleich sein.
 

Was ist die Änderung bei der Komprimierung bei der Verwendung von lz, gzfastund gz Lokale Komprimierungseinstellungen?

Verwenden Sie den folgenden Befehl, um den lokalen Komprimierungsalgorithmus zu ändern, der in einer Data Domain verwendet wird:
filesys option set compression {none | lz | gzfast | gz}
 
Hinweis: Das Dateisystem muss heruntergefahren werden, bevor Sie den lokalen Komprimierungstyp ändern. Es kann sofort neu gestartet werden, nachdem die Komprimierungsoption festgelegt wurde.
 
Im Allgemeinen ist die Reihenfolge der Komprimierung wie folgt:
lz < gzfast < gz
 
Geben Sie Erwartete Komprimierung CPU-Auslastung
Keine 1-fach 0x
Lz 2-fach 1-fach
gzfast 2,5-mal 2-fach
Gz 3-fach 5-fach
 
Der grobe Unterschied ist folgender:
  • lz to gzfast bietet ~15% bessere Komprimierung und verbraucht 2x CPU
  • lz to gz bietet ~30% bessere Komprimierung und verbraucht 5x CPU
  • gzfast to gz Bietet ~10-15% bessere Kompression
Beachten Sie, dass sich eine Änderung der lokalen Komprimierung zuerst auf neue Daten auswirkt, die nach der Änderung in die Data Domain geschrieben wurden. Die alten Daten behalten ihr vorheriges Komprimierungsformat bis zum nächsten Bereinigungszyklus bei. Beim nächsten Bereinigungszyklus werden alle alten Daten kopiert und in das neue Komprimierungsformat weitergeleitet. Dadurch dauert die Bereinigung deutlich länger und benötigt mehr CPU.
 
Wenn das System bereits wenig CPU hat, insbesondere wenn Backups und Replikation gleichzeitig ausgeführt werden, kann dies die Backups und verlangsamen. Der/die KundIn sollte explizit etwas Zeit für diese Konvertierung einplanen.

Weitere Informationen

Wissensreferenzen:

Betroffene Produkte

Data Domain

Produkte

Data Domain
Artikeleigenschaften
Artikelnummer: 000022100
Artikeltyp: How To
Zuletzt geändert: 24 Apr. 2026
Version:  12
Antworten auf Ihre Fragen erhalten Sie von anderen Dell NutzerInnen
Support Services
Prüfen Sie, ob Ihr Gerät durch Support Services abgedeckt ist.