Wie reduziert Content-Defined Chunking doppelte Backup-Daten?
Inhaltsdefiniertes Chunking verbessert die Deduplizierung von Backups, indem es Chunk-Grenzen anhand des Dateiinhalts festlegt. Dadurch bleiben unveränderte Bereiche nach Einfügungen oder Löschungen wiederverwendbar.
Inkrementelle Backups enthalten häufig große Dateien, die zwischen den Versionen größtenteils unverändert bleiben: virtuelle Festplatten-Images, E-Mail-Archive, als Dateien kopierte Datenbanken, Projektpakete und exportierte Mediatheken. Beginnt jeder Chunk an einem festen Byte-Offset, kann das Einfügen eines kleinen Headers am Anfang jede nachfolgende Grenze verschieben, obwohl die späteren Bytes identisch sind. Inhaltsdefiniertes Chunking richtet die Segmentierung an lokalen Byte-Mustern statt an absoluten Positionen aus, sodass das Backup nach dem geänderten Bereich wieder mit alten Chunks synchronisieren kann.
Feste Grenzen können aus einer kleinen Änderung viele neue Chunks machen
Ein Chunker mit fester Größe teilt Daten beispielsweise unabhängig vom Inhalt alle 1 MiB. Werden am Anfang Bytes eingefügt, sind die alten und neuen Datenströme danach gegeneinander verschoben. Dadurch enthält jeder spätere Chunk mit fester Größe eine andere Kombination von Bytes, selbst wenn fast der gesamte zugrunde liegende Inhalt unverändert geblieben ist.
Inhaltsdefiniertes Chunking wurde für die Deduplizierung entwickelt, weil aus dem Inhalt abgeleitete Schnittpunkte Redundanz erkennen, die feste Offsets nach lokalen Änderungen möglicherweise übersehen. Der Vorteil besteht nicht darin, dass CDC vorhersagt, welche Dateien ähnlich sind. Es liefert dem Deduplizierer eine Segmentierung, die verschobene Positionen überstehen kann.
Wird eine gesamte Datei durch unabhängige Bytes ersetzt, kann kein Chunking-Algorithmus doppelte Inhalte erzeugen. CDC hilft vor allem dann, wenn Versionen große unveränderte Bytebereiche gemeinsam haben, diese Bereiche jedoch relativ zum Dateianfang verschoben sind.
Ein gleitender Fingerabdruck sucht im Bytestrom nach lokalen Schnittpunkten
CDC bewegt ein Fenster über die Eingabe und aktualisiert einen Fingerabdruck, während Bytes in dieses Fenster hinein- oder aus ihm herausbewegt werden. Eine Grenze wird festgelegt, wenn der Fingerabdruck eine konfigurierte Bedingung erfüllt. Dabei gelten Mindest- und Höchstgrenzen für die Chunk-Größe, die extrem kleine oder große Chunks verhindern.
Der Chunker von Borg verwendet einen gleitenden Inhaltsfingerabdruck, sodass die Bewertung der nächsten möglichen Grenze nicht erfordert, das gesamte Fenster von Grund auf neu zu hashen. Da der Fingerabdruck von benachbarten Bytes abhängt, kann dieselbe lokale Sequenz denselben Schnitt auslösen, selbst wenn sich ihr absoluter Datei-Offset geändert hat.
Der gleitende Fingerabdruck dient daher dazu, Grenzen zu finden, und ist nicht die endgültige Identität der gespeicherten Backup-Daten. Würde man diese beiden Hashes gleichsetzen, wäre die Erklärung dafür, wo die Deduplizierung tatsächlich über die Wiederverwendung entscheidet, ungenauer.
Mindest-, Höchst- und durchschnittliche Chunk-Größen beeinflussen ebenfalls die Grenzsuche. Sie bestimmen, wie häufig mögliche Schnitte geprüft werden und wie viele Metadaten das Repository verwalten muss.
CDC synchronisiert sich nach einer Änderung erneut, statt dauerhaft verschoben zu bleiben
Nach einer Einfügung oder Löschung sieht das gleitende Fenster zunächst andere Bytes und erzeugt rund um die Änderung andere Chunk-Grenzen. Sobald es vollständig in einen ausreichend langen unveränderten Bereich vorgedrungen ist, kann es dieselben lokalen Inhaltsmuster finden und wieder an Positionen schneiden, die mit der älteren Version übereinstimmen.
Borg weist darauf hin, dass inhaltsdefinierte Grenzen relativ zum unveränderten Inhalt stabil bleiben können, selbst wenn an anderer Stelle Bytes eingefügt oder entfernt werden. Diese erneute Synchronisierung beschränkt viele Änderungen auf wenige neue Chunks, anstatt den restlichen Inhalt der Datei ungültig zu machen.
Auch Restic teilt Dateien mithilfe eines gleitenden Fingerabdrucks in Chunks variabler Länge auf, sodass unveränderte Chunks variabler Länge über mehrere Snapshots hinweg erneut referenziert werden können. Das Repository benötigt weiterhin einen Index, um bereits gespeicherte Chunks zu erkennen.
Die Entfernung bis zur erneuten Synchronisierung hängt von den Chunking-Parametern und dem Muster der geänderten Bytes ab. CDC verspricht daher nicht, dass bei jeder Änderung genau ein neuer Chunk entsteht. Der Vorteil liegt in der statistischen Lokalität: Änderungen verschieben mit geringerer Wahrscheinlichkeit jede nachfolgende Grenze.
Eine starke Chunk-ID entscheidet nach der Grenzbestimmung über die Wiederverwendung
Das Finden einer Grenze beantwortet nur, wo ein möglicher Chunk endet. Das Repository muss anschließend noch entscheiden, ob der vollständige Chunk-Inhalt bereits vorhanden ist. Für diese zweite Entscheidung wird ein stärkerer Inhaltsbezeichner oder ein authentifizierter Hash über den fertigen Chunk verwendet und im Repository-Index gesucht.
Borg trennt seinen Grenz-Hash ausdrücklich von der kryptografischen Chunk-Identität, die als Kriterium für die Deduplizierung dient. Auch Restic referenziert gespeicherte Chunks über einen starken Inhalts-Hash, statt den gleitenden Fingerabdruck als Beweis dafür zu behandeln, dass zwei Chunks identisch sind.
Dieser zweistufige Aufbau macht den Speicherpfad verständlich: Der gleitende Hash bestimmt die mögliche Segmentierung, der Inhalts-Hash identifiziert den daraus entstandenen Chunk und die Repository-Suche entscheidet zwischen Speichern und Wiederverwenden. Die Einsparungen durch Deduplizierung entstehen erst in den letzten beiden Schritten, obwohl CDC dafür sorgt, dass diese Übereinstimmungen Änderungen mit deutlich höherer Wahrscheinlichkeit überstehen.
Chunk-Größe und Datentransformation bestimmen das Verhältnis zwischen Rechenaufwand und Einsparungen
Kleinere durchschnittliche Chunks grenzen Änderungen präziser ab, erhöhen jedoch die Anzahl der Fingerabdrücke, Indexeinträge, Suchvorgänge, Metadatenobjekte und Speicherreferenzen. Größere Chunks verringern den Indexierungsaufwand, ermöglichen es aber, dass eine kleine Änderung eine größere Einheit wiederverwendbarer Daten ungültig macht.
FastCDC konzentriert sich darauf, den CPU-Aufwand des gleitenden Hashings zu reduzieren und gleichzeitig eine starke Erkennung von Redundanzen beizubehalten. Das zeigt, dass das Chunking selbst zu einem relevanten Kostenfaktor werden kann, bevor überhaupt doppelte Bytes eingespart werden. Die besten Parameter schaffen ein Gleichgewicht zwischen Chunking-Aufwand, Indexgröße und dem Ähnlichkeitsmuster des Backup-Sets.
Eine Transformation vor dem Chunking kann außerdem die Byte-Ähnlichkeit beseitigen, von der CDC abhängt. Verschlüsselung mit unterschiedlichen Nonces, Formate, die nach einer kleinen logischen Änderung den Großteil einer Datei neu schreiben, oder bestimmte Komprimierungsverfahren können dazu führen, dass zwei logisch ähnliche Versionen auf Byte-Ebene unabhängig voneinander erscheinen.
Die Analyse von ZimaSpace zu dem Aufwand von Deduplizierungsindizes behandelt die andere Seite dieses Zielkonflikts: Eine feinere Wiederverwendung erfordert mehr Metadaten und Arbeitsspeicher, um bereits vorhandene Daten zu verfolgen. CDC ist dann wertvoll, wenn der eingesparte Speicher die zusätzlichen Kosten für Chunking und Index übersteigt – nicht lediglich, weil Chunks variabler Größe anspruchsvoller klingen.
Empfohlene Produkte
Tech- & KI-Zentrum
Mehr zum Lesen
Was ist der Plex-Zustand, und welche Teile müssen erhalten bleiben?
Der persistente Plex-Zustand umfasst die Informationen, die das Servererlebnis über Neustarts und Neuaufbauten hinweg erhalten; Medien und temporäre Transkodierungsdaten erfüllen separate Aufgaben.
Wie handhabt Plex die Authentifizierung bei lokalen und Remote-Sitzungen?
Die Plex-Authentifizierung beginnt mit der Identität des Servers und des Kontos. Anschließend bestimmen lokale oder entfernte Netzwerkpfade die Erreichbarkeit und das Verhalten der sicheren...
Warum kann die Plex-Suche langsamer werden, wenn die Bibliotheksdaten wachsen?
Das Wachstum der Bibliothek allein ist nicht die Diagnose. Prüfe zunächst die Abfragestruktur, Indizes, den Cache-Zustand, die Speicherlatenz und die Schreibaktivität, bevor du die...
