Deduplizierungs-Albträume: Was tun, wenn TAR Sie ausbremst
Wer schon einmal versucht hat, massive Mengen ähnlicher Backup-Daten in ein Deduplizierungssystem zu drücken – sagen wir, so etwas wie Cohesity –, ist wahrscheinlich an die Grenzen traditioneller Archivierungstools gestoßen. Jahrelang war TAR das Standardformat, um Dateien zu bündeln, bevor sie zum Storage geschickt wurden. Aber sobald Deduplizierung ins Spiel kommt, besonders bei Appliances, die nach der Aufnahme komprimieren und verschlüsseln, wird es chaotisch. Und zwar schnell.
Ein Nutzer in einem beliebten Storage-Forum brachte es kürzlich auf den Punkt: Er versucht, Tausende von OS- und Anwendungs-Binärdateien (SAP, Oracle, HANA – Sie wissen schon, die schweren Brocken) mit TAR zu sichern, aber die Deduplizierung spielt nicht mit. Die Dateien werden clientseitig nicht komprimiert, um Deduplizierung überhaupt zu ermöglichen, und sie werden per NFS zu Cohesity geschickt. Der Haken? Dateien einzeln zu kopieren ist schmerzhaft langsam. So im Bereich von 5 Stunden gegen 10 Minuten langsam.
Die Frage, die sich stellte: Gibt es ein besseres Archivformat als TAR, wenn Deduplizierung im Spiel ist?
Schauen wir uns das genauer an.
Das Tauziehen zwischen Deduplizierung und Archivformat
Zunächst einmal ist es wichtig zu erwähnen, dass TAR an sich nicht schlecht für Deduplizierung ist. Wie einige Kommentatoren anmerkten, ist TAR nur ein Container – es bündelt Dateien im Rohformat mit Headern. Das Problem entsteht, wenn man diese TAR-Dateien komprimiert. Kompression verschleiert die zugrunde liegenden Datenmuster, auf die sich Deduplizierungs-Engines verlassen, um Redundanz zu erkennen. Dasselbe gilt für Verschlüsselung. Wenn Sie also TARen und gzippen (.tgz), füttern Sie Ihre Dedup-Engine im Grunde mit Müll, aus ihrer Sicht jedenfalls.
Der ursprüngliche Nutzer vermied diese Falle: keine Kompression, keine Verschlüsselung vor der Aufnahme. Aber das Problem war nicht nur die Dedup-Qualität – es war die Performance. Kleine Dateien bremsen Cohesitys Ingest-Pipeline über NFS aus. Das überrascht nicht. Die meisten Storage-Systeme – besonders solche, die auf großen sequenziellen I/O optimiert sind – hassen es, mit winzigen Dateioperationen bombardiert zu werden.
Trotzdem bleibt uns ein hartnäckiges Problem. Man kann die Dateien nicht einzeln kopieren. TAR funktioniert, sabotiert aber im Lauf der Zeit die Dedup durch verschobene Inhaltspositionen. Was gibt es sonst noch?
Warum Dedup mit sich ändernden TARs kämpft
Hier liegt der Haken: Jedes Mal, wenn Sie eine winzige Änderung in einem Verzeichnis vornehmen und es neu TARen, verschiebt sich die gesamte Struktur der resultierenden .tar-Datei. Weil TAR nur ein Strom aneinandergereihter Dateien ist, verschieben sich die relativen Positionen unveränderter Dateien. Für eine Deduplizierungs-Engine auf Blockebene kann selbst eine Verschiebung um 1 Byte einen komplett neuen Chunk bedeuten, den sie speichern muss – da gibt es keinen Dedup-Gewinn.
Einige Kommentatoren verwiesen auf ein Paper aus dem Jahr 2011, das genau vor diesem Problem warnte: TAR sei nicht dedup-freundlich, weil sich Änderungen durch das gesamte Archiv fortpflanzen. Andere widersprachen und wiesen darauf hin, dass moderne Dedup-Systeme intelligentere Chunking-Algorithmen (z. B. variable Länge, Sliding Windows) nutzen, die Redundanzen trotzdem finden können – selbst innerhalb verschobener TARs.
Die Realität liegt wahrscheinlich irgendwo dazwischen. Wenn Ihre Backup-Strategie regelmäßige Aktualisierungen riesiger Archive beinhaltet, steuern Sie auf Deduplizierungs-Kopfschmerzen zu.
Was ist also die Alternative?
Ehrlich gesagt? Es gibt hier keine Wunderwaffe. Aber es gibt Strategien, die helfen können, je nachdem, was Ihnen wichtiger ist – Restore-Granularität, Dedup-Gewinne oder Performance.
1. Chunk-ausgerichtete Archivierungstools nutzen
Es gibt einige Archivierungstools wie DAR (Disk ARchive) oder Bacula, die Chunking oder Segmentierung von Backups auf dedup-freundlichere Weise ermöglichen. Diese Tools sind etwas komplexer als das gute alte TAR, können aber den Kontext auf Dateiebene bewahren und trotzdem Daten so bündeln, dass Dedup-Engines ihre Arbeit machen können.
2. Archive nach Inhaltstyp aufteilen
Wenn Sie viele kleine, größtenteils unveränderliche Dateien haben (wie OS-Binärdateien), gruppieren Sie sie zusammen. Je einheitlicher der Inhalt eines TAR ist, desto besser fällt die Deduplizierung tendenziell aus – besonders, wenn Dateien mit ähnlicher Häufigkeit aktualisiert werden.
3. Ein eigenes dedup-bewusstes Format entwickeln
Ein Nutzer deutete an, dass TAR immer noch in Ordnung ist, wenn man die Backup-Software selbst kontrolliert und sie versteht, wie Deduplizierung am Ziel funktioniert. Das ist ein großer Vorteil. Wenn Ihr Backup-Tool geänderte Blöcke nachverfolgt, sie mit bekannten Chunks in der Dedup-Tabelle abgleicht und entsprechend verpackt, können Sie das System ein bisschen austricksen. Allerdings hat nicht jedes Team diesen Luxus.
4. Vorab-Kompression oder -Verschlüsselung vermeiden
Man kann es nicht oft genug betonen: Wenn Sie Ihre Daten komprimieren oder verschlüsseln, bevor Sie sie an das Dedup-Ziel senden, verbrennen Sie Ihre Deduplizierungsvorteile. Manche Systeme wie Cohesity kümmern sich erst nach der Dedup um Kompression und Verschlüsselung – genau, wie es sein sollte. Greifen Sie sich selbst nicht vor.
„Nutzt einfach den Agenten" ist nicht immer die Antwort
Mehrere Leute schlugen den Cohesity-Agenten und geplante Jobs vor. In der Theorie macht das Sinn: Der Agent kann geänderte Blöcke, Deduplizierungs-Kontext und sogar Restores sauber handhaben. Aber in der realen Welt ist es nie so einfach.
In diesem Fall müssen die Nutzer, denen die gesicherten Systeme gehören, Restores selbst durchführen – haben aber keinen Zugriff auf die Cohesity-GUI. Also entschied sich das Team für einen skriptbaren Ansatz: TAR-Archive auf der Festplatte gespeichert, Restore per Shell. Einfach, schnell, kein GUI-Drama.
Und das ist wichtig. Man kann die eleganteste Storage-Architektur der Welt haben, aber wenn der Restore-Prozess langsam oder hinter einer Admin-Schranke verriegelt ist, rebellieren die Nutzer.
Eine Warnung aus der Praxis
Ein Storage-Admin brachte es unverblümt auf den Punkt: Dedup klingt cool, liefert im Enterprise-Umfeld aber selten große Ergebnisse. Er habe gesehen, dass Kompression weit mehr Einsparungen bringt als Deduplizierung, und warnte sogar davor, sich zu stark auf Dedup zu verlassen, wegen möglicher Probleme mit der Chunk-Datenbank – besonders, wenn das Storage-System einen Treffer abbekommt.
Das ist keine Paranoia, das ist Erfahrung. Wenn Sie eine Strategie um Deduplizierungs-Einsparungen herum aufbauen, sollten Sie besser genau verstehen, welche Art von Dateien Sie sichern, wie oft sie sich ändern und wie die Dedup-Engine funktioniert. Andernfalls jagen Sie theoretischen Einsparungen hinterher.
Was sollten Sie also tun?
Hier die Quintessenz:
- TAR ist nicht der Bösewicht, aber auch kein Wunderformat für dedup-bewusste Backups.
- Vermeiden Sie Kompression und Verschlüsselung vor der Aufnahme. Überlassen Sie das Ihrem Storage-System.
- Testen Sie verschiedene Strategien. Manche Nutzer hatten Erfolg mit aufgeteilten TARs, gechunkten Archiven oder dem Anpassen der Dedup-Einstellungen auf der Storage-Appliance.
- Versteifen Sie sich nicht auf Deduplizierung. Wenn Kompression Ihnen 50 % bringt und Dedup 3 %, wissen Sie, wo die echten Einsparungen liegen.
Und vielleicht, nur vielleicht, ist es Zeit, Ihr Archivformat zu überdenken, wenn Restore-Zeiten und Dedup-Einbußen Ihnen Kopfzerbrechen bereiten. Die Tools sind da draußen. Sie müssen nur das auswählen, das zu Ihren Schmerzpunkten passt, nicht nur zu Ihrer Gewohnheit.