Data Domain – FAQs zur Komprimierung

GILT FÜR

• Alle DDRs
• Alle Versionen

Komprimierung: Häufig gestellte Fragen (FAQs):

Idealerweise wäre dies der Fall. In der Praxis verwendet das komplette Backup jedoch 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. Angenommen, die logische Größe des kompletten Backups beträgt 100 GB und die des inkrementellen Backups 2 GB. Angenommen, das inkrementelle Backup wird auf 1 GB komprimiert. Dann benötigt das komplette Backup mindestens 1,5 GB.
• Die DD-Komprimierungs-Engine schreibt einige doppelte Datensegmente aus Performancegründen neu. Je schlechter die Datenlokalität der Änderungen ist, desto mehr Duplikate werden geschrieben. Die Duplikate werden später durch „filesys cleaning“ zurückgewonnen. Ich habe festgestellt, dass etwa 2 % der logischen Größe als Duplikate neugeschrieben werden. Geht man von dieser Menge an Duplikaten aus, würde das komplette Backup 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 Neuordnungen sind. In der Regel werden etwa 0,2 % der Segmente erzwungen, so dass davon ausgegangen werden kann, dass viel mehr Platz benötigt wird.

„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. Sind gelöschte Dateien vorhanden, überschätzt „filesys show compression“ das Komprimierungsverhältnis.

Gehen wir beispielsweise davon aus, dass das erste komplette Backup eine 2-fache Komprimierung erhält. Ein nachfolgendes komplettes Backup ohne Datenänderungen erhält eine 200-fache Komprimierung. Das erste komplette Backup wird gelöscht. „filesys show space“ zeigt ein 2-faches Komprimierungsverhältnis an. „filesys show compression“ zeigt nun ein 200-faches Komprimierungsverhältnis an, da die einzige noch vorhandene Datei bei der Erstellung eine 200-fache Komprimierung erhalten hat.

Im obigen Beispiel zeigt „filesys show space“ nach dem zweiten Backup ein 4-faches kumulatives Verhältnis an. Das kumulative Verhältnis würde sich asymptotisch in Richtung 200-fach verbessern, wenn weitere Backups ohne Löschung durchgeführt würden.

Es gibt noch weitere kleine Unterschiede:

•  „filesys show compression“ berücksichtigt keine Verschwendung auf Containerebene, wodurch das Komprimierungsverhältnis weiter überschätzt wird.
•  „filesys show compression“ berücksichtigt keine Duplikateliminierung durch globale Komprimierung, wodurch das Komprimierungsverhältnis unterschätzt wird.
•  „filesys show compression“ kann Informationen pro Datei oder pro Verzeichnis bereitstellen, während „filesys show space“ sich auf das gesamte System bezieht.
•  „filesys show compression“ bietet eine Aufschlüsselung zwischen globaler und lokaler Komprimierung, während „filesys show space“ dies nicht tut.

REFERENZEN

• Warum unterscheiden sich die Komprimierungsverhältnisse für „filesys show space“ und „vtl tape show summary“?

Das Komprimierungsverhältnis, das für „vtl tape show summary“ angezeigt wird, sollte mit „filesys show compression /backup/vtc“ übereinstimmen.

Allgemeiner ausgedrückt, kann dieser VTL-Befehl mit einem optionalen Filter versehen werden, um eine Teilmenge der Bandkassetten auszuwählen, und die Komprimierung sollte mit „filesys show compression“ für diese Teilmenge an Kassetten übereinstimmen.

Aufgrund eines Bugs im VTL-UI-Code ist die für „vtl tape show summary“ angezeigte Komprimierung jedoch falsch. Dies ist ein bekanntes Problem, das in Version 4.5.0.0 behoben wurde.
 

• Warum entspricht „filesys show compression last 24 hours“ nicht den Erwartungen für VTL?

Bei VTL entspricht die Ausgabe von Befehlen wie „filesys show compression last 24 hours“ oft nicht den Erwartungen, die auf anderen Quellen wie „system show performance“ basieren.

Das Problem tritt aufgrund einer Besonderheit bei „filesys show compression“ (fsc) auf. Im Allgemeinen zeigt „filesys show compression“ kumulative Statistiken für ausgewählte Dateien an. Der Qualifizierer „last 24 hours“ wählt die 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 eine Datei in den letzten 24 Stunden angehängt wurde, zeigt „filesys show compression last 24 hours“ die kumulativen Statistiken vor den letzten 24 Stunden an.

In Nicht-VTL-Umgebungen werden Backupdateien nur einmal geschrieben, sodass es keine große Diskrepanz zwischen den aktualisierten und den erstellten Dateien gibt. Mit VTL können Backups an vorhandene Banddateien angehängt werden. Nehmen wir beispielsweise ein Band mit einer Kapazität von 100 GB, von denen 50 GB belegt sind. Wenn in den letzten 24 Stunden 10 GB an Daten angehängt wurden, zeigt „filesys show compression last 24 hours“ die „ursprünglichen Bytes“ der Datei mit 60 GB an.
 

• Wie wird das kumulative Komprimierungsverhältnis berechnet?

Die einzelnen Komprimierungsverhältnisse werden nicht linear summiert.

Angenommen, die Komprimierung beim ersten kompletten Backup liegt bei 2-fach und die beim zweiten kompletten Backup bei 20-fach. Die kumulative Komprimierung ist nicht (2+20)/2 oder 11-fach, sondern 2/(1/2+1/20) oder 3,64-fach.

Im Allgemeinen haben geringe Komprimierungsverhältnisse einen größeren Einfluss auf das kumulative Komprimierungsverhältnis als höhere.

Angenommen, das Backup hat die logische Größe „si“ und das Komprimierungsverhältnis „ci“. Dann kann das kumulative Komprimierungsverhältnis für k Backups wie folgt berechnet werden:

C = (gesamte logische Größe)/(insgesamt verwendeter Speicherplatz)
Gesamte logische Größe = s1 + s2 + ... + sk
Insgesamt verwendeter Speicherplatz = 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:

Wenn beispielsweise das erste komplette Backup eine 3-fache Komprimierung erhält und jedes nachfolgende komplette Backup eine 30-fache Komprimierung und die Aufbewahrungsfrist 30 Tage beträgt, wird NutzerInnen eine kumulative Komprimierung von 30/(1/3+29/30) oder 23-fach angezeigt.
 

• Wie funktioniert die Data Domain Compression?

Diese Frage wird im separaten Wissensdatenbank-Artikel „Grundlegendes zur Data Domain Compression“ ausführlich beantwortet. Data Domain: Grundlegendes zur Data Domain Compression
 

• Unterstützt Data Domain Multiplexing? ​​​​​​​

Gemultiplexte Daten aus der Backupanwendung führen zu einer sehr schlechten globalen Deduplizierung. Weitere Informationen finden Sie im zugehörigen Artikel „Multiplexing in Backupsoftware wird nicht unterstützt“ Data Domain: Multiplexing in Backupsoftware. 
 

• Warum hat das Replikat bei der 1:1-Verzeichnisreplikation eine bessere globale Komprimierung?​​​​​​​

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 – gegen die zuvor an der Quelle gespeicherten Daten.
• Die gesendeten Daten wurden einmal dedupliziert – gegen die 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 ändert sich bei der Komprimierung bei Verwendung der lokalen Komprimierungseinstellungen „lz“, „gzfast“ und „gz“?

filesys option set compression {none | lz | gzfast | gz}
 

Warnung: Vor dem Ändern des lokalen Komprimierungstyps muss das Dateisystem heruntergefahren werden. Es kann sofort neu gestartet werden, nachdem die Komprimierungsoption festgelegt wurde.

Im Allgemeinen ist die Reihenfolge der Komprimierung wie folgt:

Der grobe Unterschied ist folgender:

• „lz“ zu „gzfast“ bietet ~15 % bessere Komprimierung und verbraucht 2-fache CPU
• „lz“ zu „gz“ bietet ~30 % bessere Komprimierung und verbraucht 5-fache CPU
• „gzfast“ zu „gz“ ergibt ~10–15 % bessere Komprimierung

Beachten Sie, dass sich das Ändern der lokalen Komprimierung zuerst auf neue Daten auswirkt, die nach der Änderung in den Data Domain Restorer geschrieben werden. Die alten Daten behalten ihr vorheriges Komprimierungsformat bis zum nächsten Bereinigungszyklus bei. Beim nächsten Bereinigungszyklus werden alle alten Daten in das neue Komprimierungsformat kopiert. Dadurch dauert die Bereinigung deutlich länger und benötigt mehr CPU.

Wenn das Kundensystem bereits wenig CPU-Ressourcen hat, insbesondere wenn Backup und Replikation gleichzeitig durchgeführt werden, kann dies das Backup und/oder die Replikation verlangsamen. Der/die KundIn sollte explizit etwas Zeit für diese Konvertierung einplanen.

Wissensreferenzen:

• Beheben von Migrationsproblemen
• Data Domain: Grundlegendes zur Data Domain Compression