Ich habe sieben Backup-Methoden auf 5,3 GiB echten Daten gemessen — von tar.gz über alle 7z-Stufen bis zur verschlüsselten Variante. Das überraschende Ergebnis: Das kleinste Archiv kam nicht von der aggressivsten Kompression (7z mx=9 schaffte 45,8 %), sondern von einer Pipeline, die vor dem Packen die Duplikate entfernt — Endgröße 35,3 %. Der Grund ist simpel und übertragbar: 2.863 identische Dateien fielen weg, bevor der Packer überhaupt startete. Die Lehre: Bei Backups entscheidet die Reihenfolge. Erst deduplizieren, dann komprimieren, dann verschlüsseln.
Warum ich das überhaupt gemessen habe
Für eigene Backups gibt es eine bequeme Annahme: „Pack einfach alles mit maximaler Kompression, dann wird es am kleinsten.“ Ich wollte wissen, ob das stimmt — und habe es nicht an synthetischen Testdaten gemessen, sondern an einem echten, unaufgeräumten Datensatz: 5.450 MiB in 11.319 Dateien, gemischt aus Disk-Images, Kartenmaterial und Projektordnern. Genau die Art Datenmüll, die sich über Jahre ansammelt.
Sieben Methoden traten an: das klassische tar.gz, die 7z-Kompressionsstufen mx=1, mx=5 und mx=9, eine mit AES-256 verschlüsselte 7z-Variante und zwei Varianten meiner eigenen Backup-Pipeline — eine auf Geschwindigkeit, eine auf Sicherheit und mit vorgeschalteter Deduplikation getrimmt.
Die reine Kompression: erwartbar, aber langweilig
Schaut man nur auf die klassischen Packer, passiert genau das, was die Lehrbücher sagen: Mehr Mühe bringt etwas kleinere Dateien — mit abnehmendem Ertrag.
| Methode | Ausgabe | Endgröße | Dauer |
|---|---|---|---|
| tar.gz | 2.921 MiB | 53,6 % | 1m 09s |
| 7z mx=1 | 2.859 MiB | 52,5 % | 38s |
| 7z mx=5 | 2.597 MiB | 47,7 % | 2m 09s |
| 7z mx=9 | 2.498 MiB | 45,8 % | 3m 48s |
| 7z AES-256 (mx=5) | 2.597 MiB | 47,7 % | 2m 18s |
Zwei Dinge fallen auf. Erstens: Der Sprung von mx=5 auf mx=9 kostet die doppelte Zeit (2m 09s → 3m 48s) und bringt gerade einmal knapp zwei Prozentpunkte. Zweitens: Die Verschlüsselung mit AES-256 ist quasi gratis — gleiche Größe wie mx=5, nur neun Sekunden länger. Verschlüsselung kostet bei modernen Maschinen praktisch nichts, weil die CPU dafür eigene Befehle hat.
Geschwindigkeit gegen Größe — der ehrliche Sweet Spot
Wer Backups regelmäßig fährt, interessiert sich nicht nur für die kleinste Datei, sondern auch für die Zeit. Hier zeigt sich der eigentliche Kompromiss:
| Methode | Tempo | Endgröße |
|---|---|---|
| 7z mx=1 | 144 MiB/s | 52,5 % |
| tar.gz | 79 MiB/s | 53,6 % |
| 7z mx=5 | 42 MiB/s | 47,7 % |
| 7z mx=9 | 24 MiB/s | 45,8 % |
Mein Fazit für reine Kompression: 7z mx=5 ist der Sweet Spot. Es holt fast die gesamte Ersparnis von mx=9 heraus, läuft aber fast doppelt so schnell. mx=9 lohnt nur, wenn Speicherplatz teurer ist als Zeit — bei lokalen Backups ist das selten der Fall. Und mx=1 ist die Wahl, wenn es vor allem schnell gehen muss: dreimal so flott bei kaum schlechterer Größe als tar.gz.
Der eigentliche Gewinner kam aus einer anderen Richtung
Bis hierher bewegt sich alles in einem engen Korridor zwischen 45 und 54 %. Dann trat die Pipeline mit vorgeschalteter Deduplikation an — und sprengte den Rahmen:
5.450 MiB → 1.921 MiB. Endgröße: 35,3 %. Das kleinste Ergebnis aller sieben Methoden — und das, obwohl die Pipeline nicht einmal die aggressivste Kompressionsstufe verwendet, sondern zusätzlich noch doppelt verschlüsselt (7z mit AES-256, anschließend eine zweite Schicht).
Wie kann ein Verfahren, das weniger stark komprimiert als 7z mx=9, am Ende ein kleineres Archiv liefern? Die Antwort steckt nicht in der Kompression, sondern in dem, was vor ihr passiert.
Was Deduplikation wirklich tut
Bevor irgendetwas gepackt wird, läuft ein eigener Schritt davor. Es ist kein exotisches Verfahren, sondern dasselbe Prinzip, das auch frei verfügbare Werkzeuge wie rdfind, jdupes oder fdupes verwenden — in meiner Backup-Pipeline ist es fest vorgeschaltet und reversibel eingebaut. Es passiert in drei Schritten:
- Fingerabdruck bilden. Jede Datei wird einmal vollständig gelesen und zu einer SHA-256-Prüfsumme verrechnet — einem 64-stelligen Fingerabdruck ihres Inhalts. Gleicher Inhalt ergibt immer denselben Fingerabdruck; schon ein einziges geändertes Bit einen völlig anderen. Große Dateien werden dabei blockweise gelesen, damit auch ein mehrere Gigabyte großes Disk-Image nicht komplett in den Speicher muss.
- Vergleichen. Jeder bereits gesehene Fingerabdruck wird gemerkt. Taucht derselbe erneut auf, ist die Datei bitgenau identisch — eine echte Kopie, egal wie sie heißt oder wo sie liegt.
- Nur einmal sichern. Das erste Vorkommen wandert ins Backup, jede weitere Kopie wird durch einen kleinen Verweis ersetzt. Beim Wiederherstellen werden diese Verweise anhand des Fingerabdrucks wieder zu vollständigen Dateien aufgelöst — verlustfrei.
Im Testdatensatz war der Effekt drastisch:
| Kennzahl | Wert |
|---|---|
| Gefundene Duplikate | 2.863 von 11.319 Dateien (25,3 %) |
| Eingesparte Daten (vor Kompression) | 979 MiB |
| Tatsächlich einzigartige Dateien | 8.452 |
| Quelle vor dem Packen | 5,32 GiB → 4,37 GiB (−18,4 %) |
Ein Viertel der Dateien war schlicht doppelt vorhanden — zwei identische Kartenordner, mehrfach kopierte Disk-Images. Der entscheidende Punkt: Diese 979 MiB verschwinden vollständig, bevor der Packer beginnt. Ein Kompressionsprogramm dagegen muss jede Kopie erneut einlesen und verarbeiten; selbst wenn das Ergebnis klein ist, kostet jede doppelte Datei trotzdem Platz im Archiv. 7z erkennt zwar Wiederholungen innerhalb seines Suchfensters, aber über Tausende Dateien und Gigabyte hinweg ist eine vorgeschaltete Hash-Deduplikation schlicht gründlicher.
Die Reihenfolge ist die eigentliche Lehre
Das Ergebnis lässt sich auf einen Satz eindampfen: Erst die Duplikate weg, dann packen, dann verschlüsseln. Jeder Schritt arbeitet dann mit weniger Daten als der vorige — und die teure Kompressionsarbeit wird gar nicht erst auf Material verschwendet, das man sowieso nur einmal braucht.
- Deduplizieren zuerst. Der billigste Weg, ein Archiv zu verkleinern, ist, Daten erst gar nicht hineinzulegen. Ein Hash-Vergleich ist um Größenordnungen günstiger als jede Kompression.
- Komprimieren mit Augenmaß. 7z mx=5 reicht fast immer. Die letzten Prozentpunkte über mx=9 sind ihre Zeit selten wert.
- Verschlüsseln ist fast kostenlos. AES-256 kostete im Test neun Sekunden mehr — es gibt keinen Grund, ein privates Backup unverschlüsselt zu lassen.
Ehrlich bleibt eine Einschränkung: Deduplikation glänzt nur, wenn es echte Duplikate gibt. Bei einem sauber sortierten Datensatz ohne Kopien wäre der Gewinn klein, und die reine Kompression läge vorne. Mein Punkt ist deshalb nicht „Dedup ist immer besser“, sondern: Wer nur an der Kompressionsstufe dreht, optimiert oft an der falschen Stelle. Der größte Hebel liegt häufig davor — in den Daten selbst.
Transparenzhinweis: Dieses Projekt ist selbst finanziert. Die genannten Werkzeuge (7-Zip, AES-256, SHA-256) sind etablierte Standards bzw. quelloffen; es bestehen keine bezahlten Kooperationen. Alle Zahlen stammen aus einem echten Benchmark-Lauf am 21. März 2026 auf 5,3 GiB gemischter Realdaten.