Kompression im Backup: Was sich wie stark komprimieren lässt – ein Praxistest mit lionbackup

Veröffentlicht am 5. November 2026 · Praxistest · ← Blog

Wie viel kleiner wird ein Backup durch Kompression? Zwischen gar nicht und einem Faktor 16, und das hängt fast nur von den Daten ab. Wir haben 55 Dateien mit zusammen rund 3,8 GB aus allen Bereichen eines Firmenbackups mit zwölf Verfahren und Stufen gemessen: Logs, Datenbanken, Office-Dokumente, Fotos, Audio und Video, VM-Images, Archive, verschlüsselte Daten und den Silesia-Referenzkorpus. Eine Gegenprobe mit dem lionbackup-Client zeigt, was davon im Backup ankommt.

Was Kompression eigentlich ist

Kompression ist Umkodierung: Dieselbe Information wird mit weniger Bits dargestellt, weil die ursprüngliche Darstellung Redundanz enthält. Ein Backup darf dabei nur verlustfrei arbeiten. Nach der Dekompression muss jedes Byte exakt dem Original entsprechen, sonst ist eine Datenbankdatei oder ein Disk-Image unbrauchbar.

Verlustbehaftete Verfahren wie JPEG, MP3 oder H.264 werfen dagegen gezielt Information weg, die ein Mensch kaum wahrnimmt. Sie erreichen Faktoren von 10 bis 100, kommen für ein Backup aber nicht in Frage. Der Artikel behandelt deshalb nur verlustfreie Verfahren. Genau diese Unterscheidung erklärt später, warum ein JPEG im Backup nicht mehr schrumpft.

Vier Arten von Redundanz

Jedes Kompressionsverfahren ist auf bestimmte Formen von Redundanz spezialisiert:

1. Wiederholung: Dieselbe Zeichenfolge kommt mehrfach vor. In einem SQL-Dump steht INSERT INTO kunden VALUES ( tausendfach, in einem Logfile wiederholt sich der Hostname in jeder Zeile.
2. Ungleiche Häufigkeit: Manche Bytes sind viel häufiger als andere. In deutschem Text macht das e etwa 17 Prozent aller Buchstaben aus, das q unter 0,1 Prozent. Trotzdem belegen beide 8 Bit.
3. Kontext: Das nächste Zeichen ist aus den vorherigen oft vorhersagbar. Nach q folgt fast immer u, nach 2026-11-0 eine Ziffer.
4. Struktur: Dateiformate enthalten Füllbytes, Ausrichtung auf Blockgrenzen, leere Tabellenzellen oder ungenutzte Sektoren in Disk-Images, oft lange Nullfolgen.

Die Entropie als untere Grenze

Claude Shannon hat 1948 bewiesen, dass es für jede Datenquelle eine untere Grenze gibt, unter die kein verlustfreier Kodierer kommt. Diese Grenze ist die Entropie der Quelle, gemessen in Bit pro Symbol:

Dabei ist p(x) die Wahrscheinlichkeit des Symbols x. Ein Byte, dessen 256 Werte alle gleich wahrscheinlich sind, hat die Entropie 8 Bit und lässt sich nicht verkürzen. Ein Byte, das zu 99 Prozent den Wert 0 und sonst den Wert 1 hat, trägt nur etwa 0,08 Bit Information und lässt sich im Mittel auf ein Hundertstel kodieren.

Das erklärt die beiden Extremfälle im Test: Eine Datei aus lauter Nullbytes schrumpft auf wenige Kilobyte, weil ihre Entropie praktisch null ist. Eine Datei aus Zufallsbytes bleibt gleich groß oder wird minimal größer, weil ihre Entropie bereits bei 8 Bit pro Byte liegt. Für englischen Text liegt die Entropie nach Shannons Schätzungen und späteren Experimenten bei etwa 1 bis 1,5 Bit pro Zeichen, obwohl ASCII 8 Bit verwendet. Theoretisch wäre also ein Faktor 5 bis 8 drin; für englische Prosa erreichten zstd -3 bis xz -6 im Test 2,8 bis 3,6.

Warum kein Verfahren alles komprimieren kann

Ein Abzählargument zeigt die Grenze: Es gibt 2ⁿ verschiedene Dateien mit n Bit, aber nur 2ⁿ − 1 Dateien mit weniger als n Bit. Ein Kompressor, der jede Datei verkleinert, müsste zwei verschiedene Eingaben auf dieselbe Ausgabe abbilden, und dann wäre die Dekompression mehrdeutig. Jedes Verfahren, das manche Daten verkleinert, muss andere vergrößern. In der Praxis sind das bereits komprimierte oder verschlüsselte Daten; dort erzeugten die Verfahren im Test einen Overhead von 0,002 bis 0,45 Prozent.

Modell und Kodierer

Jeder praktische Kompressor besteht aus zwei Teilen. Das Modell findet Redundanz: Es sucht Wiederholungen, zählt Häufigkeiten oder schätzt aus dem Kontext, welches Zeichen als nächstes kommt. Der Kodierer übersetzt die Ausgabe des Modells in möglichst kurze Bitfolgen, sodass häufige Ereignisse weniger Bits bekommen als seltene.

Die Qualität des Modells entscheidet, wie nahe man der Entropie kommt, seine Geschwindigkeit, wie viele Megabyte pro Sekunde durch den Kompressor laufen. Dieses Spannungsfeld unterscheidet die Verfahren im Test: LZ4 verwendet ein sehr einfaches Modell und schafft knapp 500 MB/s auf einem Kern, xz verwendet ein aufwendiges Modell und kommt bei maximaler Stufe auf unter 2 MB/s.

So wird gemessen

Die Kompressionsrate ist im ganzen Artikel das Verhältnis der unkomprimierten zur komprimierten Größe. Eine Rate von 4,0 bedeutet, dass 400 MB auf 100 MB geschrumpft sind, also 75 Prozent Ersparnis. Der Durchsatz ist die unkomprimierte Datenmenge, die pro Sekunde verarbeitet wird, getrennt für Kompression und Dekompression.

Wie die Verfahren im Inneren arbeiten

Alle Kompressoren im Test kombinieren zwei bis drei Grundbausteine: ein Verfahren zum Finden von Wiederholungen, ein Verfahren zum sparsamen Kodieren der Ergebnisse und manchmal eine Vorsortierung der Daten. Die Bausteine stammen aus den Jahren 1952 bis 2013; ihre Kombination entscheidet über Rate und Tempo.

Lauflängenkodierung: der Urahn

Die einfachste Form ersetzt eine Folge gleicher Bytes durch Zähler und Wert. Aus AAAAAAAB wird 7A1B, aus einem Megabyte Nullen werden wenige Bytes. Lauflängenkodierung (RLE) steckt in Fax-Übertragungen, in BMP- und PCX-Bildern und als Vorstufe in bzip2. Bei Text, Code oder Datenbanken versagt sie, weil dort kaum lange gleiche Folgen vorkommen.

LZ77: das gleitende Fenster

Abraham Lempel und Jacob Ziv veröffentlichten 1977 die Idee, die bis heute den meisten Allzweckkompressoren zugrunde liegt. Der Kodierer merkt sich die zuletzt gesehenen Bytes in einem Fenster. Taucht eine Byte-Folge auf, die im Fenster bereits vorkam, schreibt er statt der Bytes nur ein Paar aus Abstand und Länge.

Aus lionbackup komprimiert, lionbackup verschlüsselt wird so lionbackup komprimiert, (24,11)verschlüsselt: Gehe 24 Bytes zurück und kopiere 11 Bytes. Ein Verweis kostet wenige Bytes, egal ob er 4 oder 258 Bytes ersetzt. Je länger und häufiger die Wiederholungen, desto stärker die Kompression.

Die Fenstergröße entscheidet, wie weit entfernt eine Wiederholung liegen darf. Deflate (gzip, ZIP, PNG) hat ein Fenster von 32 KiB. Zstandard arbeitet je nach Stufe mit 512 KiB bis 8 MiB und mit --long mit 128 MiB und mehr. LZMA (xz) nutzt bei Stufe 6 ein Wörterbuch von 8 MiB, bei Stufe 9 von 64 MiB. Zwei Kopien derselben 20-MB-Datei in einem Archiv erkennt gzip deshalb nicht, xz -9 und zstd --long dagegen schon. Der Test misst diesen Effekt später direkt.

Das Suchen der Wiederholungen ist der teuerste Schritt. Schnelle Stufen (zstd -1, gzip -1, LZ4) prüfen pro Position nur wenige Kandidaten. Hohe Stufen (zstd -19, xz -9) verfolgen Hash-Ketten oder Binärbäume über hunderte Kandidaten und berechnen per optimalem Parsing, welche Kombination aus Verweisen und Literalen insgesamt am wenigsten Bits kostet. Deshalb wird zstd von Stufe 3 auf Stufe 19 über hundertmal langsamer beim Komprimieren, beim Dekomprimieren aber kaum: Der Dekoder kopiert nur Bytes, suchen muss er nie.

LZ78 und das daraus abgeleitete LZW (1984) arbeiten mit einem explizit aufgebauten Wörterbuch. LZW steckt in GIF und älteren TIFF- und PDF-Dateien, spielt für moderne Backups aber keine Rolle mehr.

Huffman-Kodierung: kurze Codes für häufige Zeichen

David Huffman entwickelte 1952 ein Verfahren, das jedem Symbol einen Code variabler Länge zuweist: häufige Symbole bekommen kurze Codes, seltene lange. Die Codes entstehen über einen Binärbaum, in dem die beiden seltensten Symbole wiederholt zu einem Knoten verschmolzen werden. Kein Code ist Präfix eines anderen, deshalb lässt sich der Bitstrom ohne Trennzeichen eindeutig dekodieren.

Vier Symbole mit den Häufigkeiten e: 50 Prozent, n: 25 Prozent, a und q: je 12,5 Prozent ergeben die Codes 0, 10, 110 und 111. Statt 8 Bit pro Zeichen braucht der Text im Mittel 1,75 Bit. Deflate teilt den Datenstrom in Blöcke und baut für jeden Block eigene Huffman-Tabellen, die komprimiert im Datenstrom stehen.

Huffman hat eine bekannte Schwäche: Codelängen sind ganze Zahlen. Ein Symbol mit 90 Prozent Wahrscheinlichkeit trägt nur 0,15 Bit Information, bekommt aber mindestens ein ganzes Bit. Bei stark ungleichen Verteilungen verschenkt Huffman deshalb bis zu einem Bit pro Symbol.

Arithmetische Kodierung und ANS: Bruchteile von Bits

Arithmetische Kodierung (ab 1976, praktisch ab den 1980ern) löst dieses Problem. Sie kodiert die gesamte Nachricht als eine Zahl in einem Intervall zwischen 0 und 1, das mit jedem Symbol proportional zu dessen Wahrscheinlichkeit schrumpft. Ein Symbol mit 90 Prozent kostet dann tatsächlich nur 0,15 Bit. LZMA (xz, 7-Zip) verwendet eine Variante namens Range-Coder, die die Wahrscheinlichkeiten laufend aus dem Kontext lernt: Ob nach einem Verweis ein Literal oder ein weiterer Verweis folgt, schätzt sie aus den vorherigen Entscheidungen.

Der Preis ist Rechenzeit, weil pro Symbol Multiplikationen und Divisionen anfallen. Jarek Duda beschrieb ab 2009 mit Asymmetric Numeral Systems (ANS) einen Weg, dieselbe Effizienz mit Tabellenzugriffen zu erreichen; die schnellen Varianten folgten 2013. Zstandard kodiert Längen und Abstände mit der tabellenbasierten ANS-Variante Finite State Entropy (FSE) und Literale mit Huffman. Das ist ein Grund, warum zstd im Test bei gleicher Rate fast sechsmal so schnell dekomprimierte wie gzip.

Burrows-Wheeler-Transformation: erst sortieren, dann kodieren

bzip2 (1996) geht einen anderen Weg. Es sortiert alle zyklischen Rotationen eines Blocks von bis zu 900 KB alphabetisch und behält nur die letzte Spalte. Die Transformation ist umkehrbar und komprimiert selbst nichts, aber sie gruppiert Bytes mit gleichem Kontext: Alle Zeichen, die vor einem ackup stehen, landen nebeneinander, und das ist fast immer ein b.

Danach folgen eine Move-to-Front-Transformation, Lauflängenkodierung und Huffman. Für Text liefert das bessere Raten als Deflate. Nachteile sind die Blockgrenze, hinter der keine Wiederholung erkannt wird, und die langsame Dekompression: Die Rücktransformation springt kreuz und quer durch den Block und wartet ständig auf den Arbeitsspeicher.

Kontextmodelle: die Spitze der Rate

Verfahren wie PAQ, zpaq oder cmix sagen für jedes Bit aus den vorangegangenen Bytes eine Wahrscheinlichkeit voraus, mit dutzenden Modellen, die ein neuronaler Mischer gewichtet. Sie erreichen die besten Raten überhaupt, komprimieren aber mit weit unter 2 MB/s und brauchen Gigabytes an Speicher. Für Backups im Terabyte-Bereich sind sie nicht praktikabel; der Test lässt sie außen vor.

Die Verfahren im Test

LZ4, Brotli und bzip2 laufen als Vergleichspunkte mit, um die Spannweite zwischen maximalem Tempo und maximaler Rate zu zeigen. Wichtig für das Lesen der Ergebnisse: Gemessen wurden die Referenzwerkzeuge auf der Kommandozeile. Der Client verwendet für dieselben Formate eigene Go-Bibliotheken mit anderen Stufen; was das ändert, zeigt die Gegenprobe.

Was alle Verfahren gemeinsam haben

Ein Kompressor sieht nur Bytes, keine Dateitypen. Er weiß nicht, ob er ein JPEG, eine Datenbank oder ein Disk-Image vor sich hat. Er findet Wiederholungen und schiefe Häufigkeiten, wo sie existieren, und scheitert, wo ein anderes Verfahren sie bereits entfernt hat. Deshalb liegen die Ergebnisse im Test zwischen einer Rate von 1,00 und über einer Million.

Wie der lionbackup-Client komprimiert

Der Client ist ein einzelnes Go-Programm, das den lokalen Teil eines Backup-Laufs übernimmt: Quellen lesen, komprimieren, verschlüsseln und hochladen. Die Reihenfolge ist zwingend. Verschlüsselte Daten sehen für jeden Kompressor wie Zufall aus; komprimiert werden kann nur vorher.

Die Verarbeitungskette

1. Quellen lesen. Jeder Eintrag unter files: wird zu einem eigenen Archiv: Der Client verpackt die Quelle in einen tar-Strom. Lesefehler unterhalb einer Quelle führen je nach on_read_error zu Warnung und Überspringen oder zum Abbruch.
2. Komprimieren. Der tar-Strom läuft durch das in compression_method gewählte Verfahren mit der Stufe aus compression_level. Weil jede Quelle ihr eigenes Archiv bekommt, findet die Kompression Wiederholungen nur innerhalb einer Quelle.
3. Verschlüsseln. Verschlüsselt wird immer. Der Client erzeugt pro Archiv einen zufälligen 32-Byte-Datenschlüssel (DEK) und verschlüsselt nur diesen asymmetrisch für den Empfängerschlüssel. Die Nutzdaten laufen symmetrisch in 64-KiB-Blöcken durch XChaCha20-Poly1305.
4. Übertragen. Die fertige .lbk-Datei geht in Teilstücken an einen Citadel der gewählten Storage-Zone. Die Liste der Citadels kommt aus einem DNS-TXT-Record, wird zufällig gemischt und per /v1/health geprüft; fällt ein Server aus, wechselt der Client auf den nächsten. Während eine Datei übertragen wird, packt der Client bereits die nächste (Fließbetrieb). Die Replikation über mehrere Standorte erfolgt serverseitig.

Verfahren, Stufen und Fenster im Client

Zwei Einstellungen steuern die Kompression. compression_method wählt das Verfahren: ZSTD, GZIP oder LZMA2 (auch XZ). Fehlt der Eintrag, nimmt der Client GZIP; die Beispielkonfiguration und die Dokumentation empfehlen ZSTD. compression_level wählt die Stufe von 1 bis 9, Standard ist 5; 0 schaltet die Kompression ab, verschlüsselt wird trotzdem.

Die drei Verfahren setzen die Stufe unterschiedlich um:

Die Werte stammen aus dem Quelltext des Clients und seiner Bibliotheken: klauspost/compress für ZSTD, klauspost/pgzip für GZIP und ulikunitz/xz für LZMA2. Drei Folgen sind für die Messergebnisse wichtig:

• ZSTD im Client entspricht zstd -1 bis etwa -11, nicht zstd -19. Die Ultra-Stufen der Kommandozeile gibt es im Client nicht.
• Das Fenster ist fest. GZIP sieht 32 KiB zurück, ZSTD 8 MiB (auf Stufe 1: 4 MiB) und LZMA2 8 MiB. Wiederholungen, die weiter auseinanderliegen oder in verschiedenen Quellen stehen, speichert der Client mehrfach; einen Modus wie zstd --long bietet er nicht.
• GZIP nutzt alle Kerne, ZSTD und LZMA2 im Wesentlichen einen. pgzip komprimiert Blöcke von 1 MiB parallel. Die ZSTD-Bibliothek arbeitet in der Einstellung des Clients mit einem Kern und einem Hilfsfaden, LZMA2 mit einem Kern. Beim Entpacken ist ZSTD trotzdem mit Abstand am schnellsten.

Beim Restore erkennt der Client das Verfahren an den ersten Bytes der entschlüsselten Daten (1f 8b für gzip, 28 b5 2f fd für zstd, fd 37 7a 58 5a 00 für xz, sonst ein unkomprimiertes tar).

Das .lbk-Dateiformat

"LIONBKP1" | Version | Header-Länge | age-verschlüsselter Header   <- asymmetrisch (KEM)
             Header-Inhalt: 32-Byte-DEK | JSON-Metadaten
Chunk 0 | Chunk 1 | ... | Chunk N (isLast)                        <- symmetrisch (DEM)
Chunk = [Länge | 24-Byte-Nonce | Chiffretext + 16-Byte-Tag]

Den Header verschlüsselt age; neue Schlüssel des Clients sind ein Hybrid aus ML-KEM-768 und X25519 und damit gegen Angriffe mit Quantencomputern ausgelegt. Jeder Chunk trägt als zusätzlich authentifizierte Daten seinen Index und ein Ende-Flag. Umsortierte Chunks fallen deshalb bei der Entschlüsselung auf, eine abgeschnittene Datei am fehlenden letzten Chunk.

Was Kompression für den Backup-Lauf bedeutet

Die Kompressionsrate wirkt an drei Stellen. Sie bestimmt das Volumen, das über die Leitung geht, und damit die Laufzeit bei begrenzter Bandbreite. Sie bestimmt den belegten Speicher in der Storage-Zone und damit die laufenden Kosten. Und das Verfahren bestimmt, wie lange die CPU des Quellsystems belegt ist.

Bei 100 Mbit/s Upload überträgt die Leitung etwa 12 MB/s. Ein Kompressor, der mit 200 MB/s eine Rate von 2,5 erreicht, macht daraus effektiv 30 MB/s Nutzdaten, ohne selbst zum Engpass zu werden. Ein Kompressor mit 4 MB/s und Rate 3,2 wird dagegen selbst zum Engpass: Das Backup dauert siebeneinhalbmal so lange wie mit dem schnelleren Verfahren, obwohl weniger Bytes übertragen werden.

Selbst messen mit --autotune

Der Client bringt den Vergleich für die eigenen Daten mit: lionbackup-client --autotune komprimiert jede Quelle einmal mit ZSTD, GZIP und LZMA2 auf der eingestellten Stufe, ohne zu verschlüsseln oder hochzuladen. Die Tabelle zeigt Ausgabegröße, die Größe in Prozent des Originals (25 Prozent entsprechen einer Rate von 4,0), Laufzeit und Durchsatz. Als Empfehlung nennt der Client das Verfahren mit dem kleinsten Produkt aus Größe und Laufzeit. Wie das aussieht und warum die Empfehlung nicht immer ZSTD lautet, zeigt die Gegenprobe weiter unten.

Testaufbau und Methodik

Der Haupttest misst 55 Dateien mit zusammen rund 3,8 GB gegen zwölf Verfahren und Stufen, insgesamt 625 Einzelmessungen. Dazu kommen ein Stufen-Sweep mit 51 Konfigurationen, ein Fenster-Experiment mit 70 und ein Versions-Experiment mit 14 Messungen. Für die Kompressionsrate spielt die Dateigröße ab einigen Megabyte kaum noch eine Rolle; 3,8 GB reichen deshalb aus.

Hardware und Software

Die Messungen liefen auf einem einzelnen Kern eines Intel Xeon mit 2,1 GHz unter Ubuntu 24.04 mit 3,9 GB RAM, mit den Referenzwerkzeugen in der jeweils paketierten Version: gzip 1.12, bzip2 1.0.8, xz 5.4.5, zstd 1.5.5, lz4 1.9.4 und brotli 1.1.0. Jede Datei wurde vor der Messung einmal gelesen, damit sie im Seitencache liegt und die Messung nicht die Festplatte misst. Die Zeit ist die Wanduhrzeit um den Prozess, der Speicherbedarf die maximale Resident Set Size.

Ein Kern ist bewusst gewählt: So vergleicht der Test die Verfahren selbst und nicht, wie gut ein Werkzeug parallelisiert. Wie sich der Client auf einem Rechner mit mehreren Kernen verhält, zeigt die Gegenprobe.

Die Testdaten

Die Dateien stammen aus drei Quellen. Erstens der Silesia-Korpus, ein seit 2003 etablierter Referenzdatensatz aus zwölf realen Dateien, den auch die Entwickler von zstd und lz4 für ihre Benchmarks verwenden: englische Literatur (dickens), Programmdateien von Mozilla 1.0 (mozilla), ein MRT-Bild (mr), eine Chemie-Datenbank (nci), eine Windows-DLL (ooffice), eine MySQL-Datenbank (osdb), ein PDF (reymont), der Samba-Quellcode (samba), ein Sternkatalog (sao), ein HTML-Wörterbuch (webster), ein Röntgenbild (x-ray) und XML-Dateien (xml).

Zweitens reale Dateien aus dem Testsystem: 300 Linux-Bibliotheken und Programme, der Python-Quellcode der Standardbibliothek, der Go-Quellcode von klauspost/compress (die zstd-Implementierung des lionbackup-Clients), deren Git-Objekte und 200 TrueType-Schriften.

Drittens synthetische Dateien, deterministisch mit festem Zufalls-Seed erzeugt, damit der Test reproduzierbar bleibt: Syslog- und Nginx-Logs mit realistischen Zeitstempeln, IP-Adressen und Meldungen; ein MySQL-Dump, CSV, JSON Lines, XML, SQLite und Excel aus denselben 220.000 Bestelldatensätzen; Word-, PowerPoint- und PDF-Dokumente; HTML-Seiten; eine Mailbox mit Base64-Anhängen; 24 Fotos mit Sensorrauschen als JPEG, PNG, BMP und TIFF; dreiminütige Audiodaten als WAV, FLAC und MP3; ein H.264-Video; Messreihen als float64 und gerundet als float32; ein ext4-Disk-Image mit einem Linux-Teilsystem als raw, qcow2, VMDK, VDI und ISO; tar, tar.gz und ZIP desselben Baums; eine AES-verschlüsselte Datei, Zufallsdaten und Nullbytes.

Die synthetischen Geschäftsdaten verwenden ein begrenztes Vokabular aus 40 Vornamen, 40 Nachnamen, 30 Städten und 20 Produkten. Sie komprimieren deshalb etwas besser als echte Kundendaten. Wo es reale Vergleichsdaten gibt, etwa bei Datenbanken (synthetischer Dump gegen Silesia osdb) oder Quellcode, liegen die Ergebnisse nahe beieinander. Die Werte für HTML und die Mailbox sind als Obergrenze zu lesen; echte Logs können dagegen noch gleichförmiger sein als die synthetischen.

Die Verfahren und Stufen

Für den Stufen-Sweep liefen zusätzlich zstd 1 bis 22, gzip 1 bis 9, xz 0 bis 9, bzip2 1/5/9, lz4 1/3/9/12 und brotli 1/5/9/11 auf einem 64-MB-Ausschnitt eines Server-Backups aus Logs, SQL-Dump, PDF, Quellcode, Binaries, Fotos, Office-Dokumenten und JSON.

Die Kennzahlen pro Verfahren sind über ein Kernset von 45 Dateien berechnet, ohne die drei Extremfälle (Nullbytes, Zufall, verschlüsselt) und ohne die Dateien, für die nicht alle Konfigurationen gemessen wurden. Als Mittelwert der Rate dient das geometrische Mittel, weil Raten multiplikativ sind: Ein Verfahren, das eine Datei auf die Hälfte und eine andere auf ein Viertel bringt, hat im Mittel eine Rate von 2,83 und nicht von 3,0. Der Durchsatz ist Gesamtmenge geteilt durch Gesamtzeit; große Dateien zählen dadurch stärker.

Ergebnisse nach Dateiformat

Zwischen einer Rate von 1,00 für JPEG, MP3 und verschlüsselte Daten und 15,9 für XML liegt der Faktor 16; die Nullbytes-Datei sprengt mit über einer Million jede Skala. Innerhalb eines Formats liegen die Verfahren dagegen meist nur 20 bis 60 Prozent auseinander. Die Datenart entscheidet über die Größenordnung, das Verfahren über den Feinschliff.

Die Rangfolge der Datenarten

Aus den geometrischen Mitteln pro Kategorie ergibt sich eine Rangfolge, die sich zwischen den Verfahren nur wenig verschiebt (sortiert nach zstd -3):

* Für zstd -19 liegen bei den VM-Images nur zwei der sechs Dateien vor; der Wert 3,7 gilt für das unkomprimierte qcow2.

Text und Logs: der Idealfall

Logdateien sind der Idealfall für LZ77. In jeder Zeile wiederholen sich Datum, Hostname, Prozessname und große Teile der Meldung; nur Zeitstempel, PIDs und IP-Adressen wechseln. Das Nginx-Access-Log erreicht mit zstd -3 eine Rate von 6,9 bei 245 MB/s, mit zstd -19 10,0 und mit bzip2 sogar 13,0. Das Syslog liegt mit 5,3 bis 8,3 darunter, weil die Meldungstexte vielfältiger sind.

Bei beiden Logs liegt gzip -6 in der Rate vor zstd -3 (7,9 gegen 6,9 und 5,7 gegen 5,3), und zstd -1 vor zstd -3. Die schnellen Stufen verwenden eine Suchstrategie, die bei extrem gleichförmigen Zeilen zufällig besser greift; ab zstd -9 liegt zstd wieder klar vorn. Echte Systemprotokolle sind oft noch gleichförmiger als die synthetischen: In der Gegenprobe erreichte ein Systemprotokoll im Client Raten über 15.

Strukturierte Daten liegen noch höher. Derselbe Datensatz mit 220.000 Bestellungen erreicht als XML eine Rate von 8,3 (zstd -3) bis 15,9 (bzip2), als JSON Lines 6,2 bis 11,8 und als CSV 3,5 bis 5,8. XML wiederholt in jedem Datensatz vierzehn Tag-Paare, JSON vierzehn Schlüssel, CSV nur dreizehn Semikolons. Je geschwätziger das Format, desto höher die Rate, aber die Größe nach der Kompression ist fast gleich: XML schrumpft mit zstd -3 von 91 auf 11 MB, JSON von 66 auf 11 MB, CSV von 31 auf 9 MB. Die Struktur ist nach der Kompression fast umsonst, die Nutzdaten kosten.

Quellcode liegt in derselben Klasse. Der Python-Quellcode erreicht 4,7 (zstd -3) bis 6,7 (xz -6), der Go-Code 6,9 bis 9,4, der C-Code von Samba aus dem Silesia-Korpus 4,3 bis 5,7. Englische Prosa (dickens) kommt auf 2,8 bis 3,6, ein Wörterbuch in HTML (webster) auf 3,4 bis 4,8. Natürliche Sprache komprimiert schlechter als Code, weil der Wortschatz größer und Wiederholungen seltener sind.

Datenbanken: Dump gegen Datei

Derselbe Datenbestand verhält sich als SQL-Dump und als SQLite-Datei unterschiedlich. Der Dump erreicht 3,9 (zstd -3) bis 6,7 (bzip2), die SQLite-Datei 3,2 bis 4,8. Der Dump ist reiner Text mit tausendfach wiederholten INSERT-Präfixen; die Datenbankdatei enthält binäre Seitenköpfe, Indexstrukturen und Verwaltungsdaten mit hoher Entropie. Die MySQL-Datenbank osdb aus dem Silesia-Korpus liegt mit 2,9 bis 3,6 im selben Bereich wie die SQLite-Datei und bestätigt das mit realen Daten.

Für Backups heißt das: Ein logischer Dump ist nicht nur portabler, sondern auch kompakter. Im Test war er schon unkomprimiert kleiner (36 gegen 42 MB), nach zstd -3 belegte er 9 MB statt 13 MB.

Office-Dokumente: eine Frage des Jahrgangs

Die alte Excel-Datei im BIFF-Format (.xls) komprimiert mit 3,3 bis 5,7 gut, weil das Format Zellen unkomprimiert als binäre Datensätze speichert. Dieselben Daten als .xlsx erreichen 1,00 bis 1,04: Seit 2007 sind Office-Dateien ZIP-Container, deren XML-Inhalt bereits mit Deflate komprimiert ist. Word- und PowerPoint-Dateien zeigen dasselbe Bild.

Eine Ausnahme fällt auf: Das Archiv aus zwölf Word-Dateien erreicht mit xz -9 eine Rate von 2,93, mit zstd -19 und xz -6 immerhin 1,17. Die Dokumente enthalten dieselben eingebetteten Fotos, und Verfahren mit großem Fenster erkennen die zweite und dritte Kopie eines Bildes über Dateigrenzen hinweg. Firmenlogos, Vorlagenbilder und Diagramme wiederholen sich in echten Dokumentbeständen ständig; die Fenstergröße entscheidet, ob das Backup davon profitiert.

PDF liegt bei 1,2 bis 1,4, unabhängig von Verfahren und Stufe. Das Text-PDF hat intern Flate-komprimierte Inhaltsströme, das Scan-PDF enthält JPEG-Seiten; beide lassen nur Objektstrukturen, Querverweistabellen und Schriften übrig.

Bilder, Audio, Video: fertig komprimiert

JPEG-Fotos erreichen exakt 1,00, mit bzip2 1,02. PNG ebenfalls 1,00, weil PNG intern Deflate verwendet; selbst xz findet in einem Deflate-Strom nichts mehr. Dieselben Fotos als unkomprimiertes BMP oder TIFF kommen nur auf 1,04 bis 1,29. Die Testfotos enthalten Sensorrauschen, und Rauschen ist per Definition nicht vorhersagbar. Ein unkomprimiertes Format heißt nicht, dass die Daten komprimierbar sind.

Spezialisierte Bildkompression schlägt hier jeden Allzweckkompressor: PNG brachte dieselben Fotos von 84 auf 47 MB (Rate 1,8), weil es jedes Pixel aus seinen Nachbarn vorhersagt und nur die Abweichung speichert; xz kam auf 1,29. Das Röntgenbild x-ray (1,4 bis 2,1) und das MRT-Bild mr (2,7 bis 4,1) aus dem Silesia-Korpus zeigen die Bandbreite realer medizinischer Rohbilder.

Audio verhält sich ebenso: WAV erreicht 1,06 bis 1,15, FLAC und MP3 exakt 1,00. FLAC ist bereits eine spezialisierte verlustfreie Kompression, die Abtastwerte linear vorhersagt und das WAV auf 63 Prozent bringt. MP4-Video liegt bei 1,00 bis 1,02.

Messdaten: der unterschätzte Fall

Drei Messreihen mit je fünf Millionen Werten als float64 erreichen nur 1,09 (zstd -3) bis 1,30 (xz -6), obwohl die Werte glatte Kurven mit leichtem Rauschen sind. Das Problem ist die Darstellung: Die 52-Bit-Mantisse eines float64 enthält bei realen Messwerten in den unteren Bits praktisch Zufall. Dieselben Werte auf zwei Nachkommastellen gerundet und als float32 gespeichert erreichen 2,15 bis 3,3. Komprimiert belegen sie mit zstd -3 dann 27 statt 105 MB, ein Viertel.

Wer Sensordaten, Simulationsergebnisse oder Finanzzeitreihen sichert, gewinnt durch sinnvolles Runden vor dem Speichern mehr als durch jede Kompressionsstufe. Deshalb bringen wissenschaftliche Formate wie HDF5 oder Parquet eigene Kodierungen für Gleitkommazahlen mit.

VM-Images: der Container ist egal

Dasselbe ext4-Dateisystem liefert als qcow2, VMDK, VDI und ISO fast identische Raten: 2,95 bis 3,00 mit zstd -3 und 3,8 bis 3,9 mit xz -6. Die Containerformate speichern nur belegte Cluster, der Inhalt ist in allen gleich. Das Raw-Image mit 512 MB erreicht dagegen 7,5 (zstd -3) bis 9,9 (xz -6), weil seine unbelegten Nullbereiche fast nichts kosten. Ohne die Nullen komprimiert der Inhalt wie in den Containerformaten.

Das qcow2 mit interner Kompression (qemu-img convert -c) ist bereits 78 statt 200 MB groß und schrumpft kaum weiter (1,01 bis 1,03). Die Wahl lautet also: qcow2 intern komprimieren und das Backup schnell durchlaufen lassen, oder unkomprimiert speichern und die Kompression dem Backup überlassen. zstd -3 erreicht auf dem unkomprimierten qcow2 eine Rate von 2,95 und damit mehr als die interne Kompression von qcow2 mit 2,56.

Archive und bereits komprimierte Daten

Das unkomprimierte tar des VM-Baums verhält sich wie das qcow2 (2,9 bis 3,8). Derselbe Baum als tar.gz oder ZIP ist 68 bis 69 MB groß und bleibt bei 1,00 bis 1,03. Git-Objekte sind zlib-komprimiert und erreichen 1,00 bis 1,08. Die Mailbox mit 35 Prozent Base64-Anhängen liegt bei 1,3 bis 2,75: Der Text komprimiert, die Base64-kodierten JPEGs kaum.

Die vollständige Tabelle

Ein Strich bedeutet, dass die Kombination nicht gemessen wurde; betroffen sind nur Formate, deren Inhalt einer bereits gemessenen Datei entspricht (VMDK und VDI entsprechen qcow2, TIFF entspricht BMP).

Ergebnisse nach Verfahren und Stufe

Über das Kernset von 45 Dateien liegt die mittlere Rate zwischen 1,64 (lz4 -1) und 3,02 (xz -9), der Kompressionsdurchsatz auf einem Kern zwischen 1,6 MB/s (xz -9) und 484 MB/s (lz4 -1). Das ist ein Faktor 1,8 bei der Rate gegen einen Faktor 300 beim Tempo. Die Dekompression streut weniger: zwischen 19 MB/s (bzip2) und 1.203 MB/s (lz4).

zstd gegen gzip: gleiche Rate, achtfaches Tempo

zstd -3 erreicht im Mittel mit 2,20 etwas mehr als gzip -6 mit 2,17, komprimiert aber mit 203 statt 24 MB/s und dekomprimiert mit 832 statt 144 MB/s. Selbst zstd -1 schlägt gzip -1 bei Rate (2,07 gegen 1,97) und Tempo (237 gegen 44 MB/s). Deutlich vorn liegt gzip -6 nur bei den Logs und den gerundeten Messdaten (7 bis 15 Prozent höhere Rate), knapp auch bei einigen Programm- und Messdateien (2 bis 5 Prozent).

Der Sweep bestätigt das auf dem Server-Mix: gzip -6 erreicht dort 4,06 bei 36 MB/s, zstd -3 3,99 bei 171 MB/s und zstd -5 4,14 bei 86 MB/s. Die gzip-Stufen 7 bis 9 lohnen sich nicht: Stufe 9 bringt gegenüber Stufe 6 nur 1,5 Prozent mehr und ist fast fünfmal so langsam (7,6 statt 36 MB/s).

zstd gegen xz: der Preis der letzten 30 Prozent

xz -6 erreicht mit 2,81 eine um 28 Prozent höhere Rate als zstd -3, braucht aber 107-mal so lange. zstd -19 liegt mit 2,69 nur 4 Prozent unter xz -6, ist genauso langsam und braucht mehr Speicher. xz -9 ist mit 3,02 das Maximum des Tests, benötigt aber 675 MB Arbeitsspeicher und bringt gegenüber xz -6 nur 7 Prozent, fast ausschließlich durch das größere Wörterbuch.

Der Stufen-Sweep

Auf dem 64-MB-Server-Mix flacht die zstd-Kurve ab Stufe 9 deutlich ab; erst die Stufen 16 bis 19 mit größerem Fenster und optimalem Parsing bringen wieder mehr, zu sehr hohen Kosten. xz zeigt dasselbe Muster: Ab Stufe 7 wachsen nur noch Wörterbuch und Speicher.

Zusammen bilden die Sweep-Kurven eine Grenze, hinter der kein Verfahren liegt: lz4 für höchstes Tempo, zstd 1 bis 9 für 50 bis 350 MB/s, zstd 10 bis 19 und bzip2 für 2 bis 30 MB/s, xz 5 bis 9 und brotli 11 für maximale Rate unter 2 MB/s. gzip liegt in jeder Stufe unterhalb der zstd-Kurve. brotli -11 bräuchte für ein 1-TB-Backup 27 Tage; es ist für Webseiten gebaut, die einmal komprimiert und millionenfach ausgeliefert werden.

Dekompression: die vergessene Hälfte

Beim Restore zählt die Dekompression. zstd dekomprimiert mit 650 bis 910 MB/s, fast unabhängig von der Stufe. gzip schafft 130 bis 145 MB/s, xz 43 bis 44 MB/s, bzip2 nur 19 MB/s.

Ein 500-GB-Restore braucht mit zstd auf einem Kern knapp zehn Minuten reine Dekompressionszeit, mit gzip eine Stunde, mit xz drei Stunden, mit bzip2 sieben Stunden. LZ77-Dekoder kopieren nur Bytes; zstd gewinnt zusätzlich durch die tabellenbasierte Entropiekodierung. bzip2 muss die Burrows-Wheeler-Transformation mit zufälligen Speicherzugriffen umkehren, xz den Range-Coder Bit für Bit nachrechnen.

Speicherbedarf

Die Spitzenwerte reichen von 13 MB (lz4, gzip, bzip2, xz -1) über 53 MB (zstd -3) und 95 MB (xz -6) bis 675 MB (xz -9). Für einen Backup-Client auf einem kleinen Server oder in einem Container ist das relevant: xz -9 kann auf einem System mit 1 GB RAM bereits scheitern.

Das Fenster-Experiment

Um die Fenstergrößen sichtbar zu machen, wurde ein 16-KiB-Block aus Zufallsdaten zweimal in eine Datei geschrieben, getrennt durch 16 KiB bis 256 MiB weiterer Zufallsdaten. Ein Kompressor, dessen Fenster den Abstand abdeckt, spart die zweite Kopie fast vollständig ein; einer, dessen Fenster zu klein ist, spart nichts.

Die Messung deckt sich mit den dokumentierten Fenstergrößen. bzip2 ist der Sonderfall: Es arbeitet nicht mit Verweisen, sondern sortiert, und spart deshalb auch innerhalb seines Blocks nur 73 Prozent der zweiten Kopie ein. Wiederholungen im Abstand von 16 MiB und mehr erkennen nur xz -9 und zstd mit --long. Der Client liegt mit seinem 8-MiB-Fenster bei ZSTD und LZMA2 in der Zeile von xz -6, mit GZIP in der Zeile von gzip -9.

Das Versions-Experiment: zwei Stände, ein Archiv

Der praktische Fall dahinter: In einem Archiv liegen zwei Versionen desselben Quellbaums mit 61 MB, in der zweiten sind 3 Prozent der Dateien geändert. Das kommt in Backups ständig vor, etwa bei Projektkopien, Release-Verzeichnissen, Container-Images mit gemeinsamen Schichten oder Dokumenten in mehreren Fassungen.

Mit einem 128-MiB-Fenster erkennt zstd -3 die zweite Version fast vollständig und verdoppelt die Rate auf 9,78, ohne langsamer zu werden. xz -9 erreicht mit 13,87 die höchste Rate, braucht dafür aber über hundertmal so lange. Bei redundanten Daten ist die Fenstergröße wichtiger als die Stufe. Mit seinem festen Fenster von 8 MiB würde der Client die zweite Version hier noch einmal speichern, denn die beiden Stände liegen 61 MB auseinander.

Gegenprobe: der lionbackup-Client selbst

Der Haupttest misst die Referenzwerkzeuge. Der Client verwendet Go-Bibliotheken mit eigenen Stufen, deshalb haben wir nachgemessen: mit dem Client aus dem aktuellen Entwicklungsstand (Version 0.1.35) auf einem Notebook-Prozessor mit 10 Kernen und 12 Threads. Die vier Quellen bestehen aus echten Daten:

• Systemprotokoll: 60 MB Export des Systemjournals des Testrechners
• Projektdateien: 17 MB aus unserem eigenen Repository, überwiegend PHP, YAML- und Ansible-Vorlagen und Go, zu einem Viertel Webschriften
• Programme: 36 MB Linux-Bibliotheken und Programme
• Bilder: 69 MB Hintergrundbilder von Ubuntu als JPEG und PNG

Raten: ZSTD wie zstd -3, LZMA2 deutlich unter xz

Die Raten stammen aus --autotune mit compression_level 1, 5 und 9. Die letzten beiden Spalten zeigen die Referenzwerkzeuge auf denselben tar-Strömen.

Drei Ergebnisse stechen heraus. ZSTD auf Stufe 5 komprimiert wie zstd -3, Stufe 9 liegt zwischen zstd -7 und zstd -11. Beim Systemprotokoll liegt der Client mit 21,1 sogar weit vor zstd -3 mit 13,3: Sein Fenster ist mit 8 MiB viermal so groß und erfasst Meldungen, die sich in größerem Abstand wiederholen; mit demselben Fenster kommt auch zstd -3 auf 20,2.

LZMA2 im Client erreicht nicht die Raten von xz. Die Go-Bibliothek sucht weniger gründlich als das Referenzwerkzeug: Beim Systemprotokoll kommt sie auf die Hälfte von xz -6, bei den Programmen auf 2,64 statt 3,18. ZSTD auf Stufe 9 erreicht in allen vier Quellen praktisch dieselbe oder eine höhere Rate (bei den Programmen 2,62 gegen 2,64).

GZIP liegt bei allen komprimierbaren Quellen hinter ZSTD: bei Projektdateien und Programmen um 3 bis 8 Prozent, beim Systemprotokoll erreicht ZSTD mehr als die dreifache Rate. Hier fehlt GZIP das Fenster: 32 KiB reichen für die Wiederholungen im Journal nicht.

Tempo: GZIP packt schneller, ZSTD entpackt viel schneller

Für die Durchsätze haben wir die Bibliotheken mit genau den Einstellungen des Clients aufgerufen und jede Messung dreimal wiederholt (Median, auf zwei Stellen gerundet). „Entpacken“ entspricht dem Restore nach dem Entschlüsseln.

GZIP nutzt alle zwölf Threads und komprimiert deshalb 1,1- bis 2,3-mal so schnell wie ZSTD. ZSTD kommt bei den Projektdateien und Programmen nicht über das Tempo von zstd -3 auf einem Kern hinaus. Beim Entpacken dreht sich das Bild: Auf den komprimierbaren Quellen ist ZSTD drei- bis siebenmal so schnell wie GZIP und 18- bis 44-mal so schnell wie LZMA2.

Stufe 1 ist bei ZSTD höchstens 40 Prozent schneller als Stufe 5, beim Systemprotokoll sogar langsamer, liefert aber 5 bis 35 Prozent größere Archive. Stufe 9 macht die Archive der Projektdateien und Programme um 8 Prozent kleiner, das Systemprotokoll um ein Drittel, braucht dafür aber das Fünf- bis Zehnfache an Zeit.

LZMA2 bricht bei Daten ein, die sich nicht komprimieren lassen: Die Bilder liefen mit 1,1 MB/s durch. Ein Fotoarchiv von 100 GB bräuchte so über einen Tag, ohne nennenswert kleiner zu werden.

Was das für den Backup-Lauf heißt

Ob das schnellere Packen von GZIP zählt, entscheidet die Leitung. Bei 100 Mbit/s Upload ist ZSTD in jeder Quelle mindestens so schnell fertig wie GZIP, weil weniger Bytes übertragen werden; beim Systemprotokoll mehr als dreimal so schnell. Das gilt in der Gegenprobe bis 500 Mbit/s. Erst oberhalb von etwa 750 Mbit/s schließt GZIP Projektdateien und Programme auf diesem Rechner früher ab, weil es alle Threads nutzt. Dafür belegt das Backup mehr Speicherplatz, und der Restore dauert dreieinhalb- bis fünfeinhalbmal so lange.

Warum --autotune manchmal GZIP empfiehlt

Die Empfehlung von --autotune ist das Verfahren mit dem kleinsten Produkt aus Größe und Laufzeit beim Komprimieren. Restore-Tempo und Speicherkosten fließen nicht ein, und die Laufzeit beim Packen bevorzugt auf Rechnern mit vielen Kernen GZIP. In der Gegenprobe empfahl --autotune für das Systemprotokoll ZSTD, für Projektdateien, Programme und Bilder GZIP. So sieht die Ausgabe für die Projektdateien aus:

Quelle: /var/tmp/kx-gegenprobe/c/code
Unkomprimiert (tar): 16.5 MB   Level: 5   CPUs: 12

Methode        Größe    Ratio       Zeit    Durchsatz
-----------------------------------------------------
ZSTD          6.0 MB    36.7%       78ms    223.1 MB/s
GZIP          6.6 MB    39.7%       45ms    381.8 MB/s
LZMA2         5.7 MB    34.6%     2.339s      7.4 MB/s

  Kleinste Größe : LZMA2 (5.7 MB)
  Schnellste     : GZIP (45ms)
  Empfehlung     : GZIP  (bestes Verhältnis aus Größe und Zeit)
  → in der Config setzen:  compression_method: GZIP

Die Spalte „Ratio“ ist die Größe in Prozent des Originals; 36,7 Prozent entsprechen einer Rate von 2,73. Größen gibt --autotune in Binäreinheiten aus: 16.5 MB sind 17,3 Millionen Bytes. Lesen Sie die Tabelle als Messung, nicht als Urteil: Für die meisten Anschlüsse sind die kleinere Datei und der schnellere Restore wichtiger als die Sekunden beim Packen.

Warum manche Daten nicht kleiner werden

Von den 55 Testdateien bleiben 12 bei jedem Verfahren und jeder Stufe unter einer Rate von 1,05, mit zstd -3 sind es 16. Das ist kein Versagen der Kompressoren, sondern eine Eigenschaft der Daten. Es gibt vier Gründe, jeder mit eigener Signatur.

Grund 1: Die Entropiekodierung ist schon passiert

JPEG, PNG, MP3, MP4, FLAC, ZIP, gzip, Git-Objekte, .docx, .xlsx, .pptx, die meisten PDFs und intern komprimierte qcow2-Images haben eines gemeinsam: Am Ende ihrer Verarbeitungskette steht ein Entropiekodierer. Bei JPEG und MP3 ist das Huffman, bei PNG, ZIP und Office-Dateien Deflate, bei H.264 CABAC, bei FLAC Rice-Codes. Ein Entropiekodierer erzeugt einen Bitstrom, in dem jedes Bit annähernd gleich wahrscheinlich 0 oder 1 ist. Für den nächsten Kompressor sieht das aus wie Zufall.

Übrig bleiben die unkomprimierten Teile des Containers: Dateinamen und Verzeichnisse im ZIP, Objektstrukturen im PDF, Metadaten im MP4. Deshalb erreicht der ZIP-Container 1,00 bis 1,03, das Text-PDF 1,37 und das Scan-PDF 1,24. Bei großen Fenstern kommen manchmal Prozente hinzu, wenn sich identische Objekte wiederholen, etwa dasselbe Bild in zwölf Word-Dateien.

Für ein Backup heißt das: Ein Verzeichnis mit Fotos, Videos, Musik und Office-Dokumenten hat eine Gesamtrate nahe 1,0. Hier zählt nur, wie schnell der Kompressor die Daten durchreicht. zstd -3 lief über die JPEG-Fotos mit 417 MB/s und über die PNG-Bilder mit 478 MB/s; zstd -19 brauchte für dieselben Dateien bei identischem Ergebnis bis zu 150-mal so lange.

Grund 2: Verschlüsselung ist Zufall mit Schlüssel

Der AES-verschlüsselte MySQL-Dump erreicht exakt 1,00 bei allen zwölf Verfahren, obwohl dieselben Daten unverschlüsselt eine Rate von 3,9 bis 6,7 erreichen. Das ist beabsichtigt: Eine Chiffre, deren Ausgabe sich von Zufall unterscheiden ließe, wäre gebrochen.

Daraus folgt die Reihenfolge im lionbackup-Client: erst komprimieren, dann verschlüsseln. Dasselbe gilt für jede verschlüsselte Quelle im Backup: LUKS-Volumes, BitLocker-Container, verschlüsselte Datenbank-Tablespaces, age- oder GPG-Dateien, Passwort-Tresore. Sie bleiben bei Rate 1,00 und sollten das Backup so schnell wie möglich durchlaufen.

Grund 3: Rauschen ist Information

Unkomprimierte Formate sind nicht automatisch komprimierbar. Die BMP- und TIFF-Bilder (1,04 bis 1,29), die WAV-Datei (1,06 bis 1,15), die float64-Messdaten (1,09 bis 1,30) und die Zufallsdaten (1,00) enthalten Rauschen, und Rauschen ist aus Sicht der Informationstheorie echte Information: Es lässt sich nicht vorhersagen und deshalb nicht kürzer schreiben.

Bei Fotos stammt das Rauschen vom Bildsensor, bei Audio vom Mikrofon und der Quantisierung, bei Messdaten von der Messung selbst und von den überzähligen Mantissenbits. Spezialisierte Verfahren wie PNG, FLAC oder die Gleitkomma-Kodierer in HDF5 helfen, weil sie das Signal unter dem Rauschen vorhersagen und nur die Differenz speichern. Ein Allzweckkompressor kann das nicht. Bei Messdaten hilft vor allem, nur die Stellen zu speichern, die tatsächlich gemessen wurden.

Grund 4: Base64 verschenkt zwei Bit pro Byte

E-Mail-Anhänge, JSON-Felder mit eingebetteten Bildern, Zertifikate und viele API-Antworten enthalten Binärdaten als Base64. Base64 verwendet 64 Zeichen, also 6 Bit Information pro 8-Bit-Zeichen. Ein Kompressor kann Base64-Text deshalb auf 75 Prozent bringen (Rate 1,33), aber nicht weiter, wenn der kodierte Inhalt selbst schon komprimiert ist. Die Testmailbox mit 35 Prozent Base64-Anteil erreicht 1,65 (zstd -3): Der Text schrumpft stark, die Anhänge auf bestenfalls drei Viertel.

Der Overhead bei doppelter Kompression

Bereits komprimierte Daten werden durch einen zweiten Kompressor minimal größer. Der Rahmen kostet bei den 40 MB Zufallsdaten mit zstd 0,002 Prozent (973 Bytes), mit gzip 0,02 Prozent, mit xz 0,005 Prozent und mit bzip2 0,45 Prozent (187 KB). Der Platz ist also kein Problem, die Zeit schon: zstd -19 und xz -6 suchen in Zufallsdaten genauso lange nach Wiederholungen wie in Text und finden nichts.

zstd hat dafür eine Abkürzung eingebaut: Findet es in einem Block keine Wiederholungen, speichert es ihn roh und beschleunigt. zstd -3 lief über die AES-Datei mit 488 MB/s, über das Syslog mit 180 MB/s. xz kennt diese Abkürzung nicht und braucht für Zufallsdaten mit 1,9 MB/s genauso lange wie für alles andere.

Das andere Extrem: Nullbytes

Das andere Extrem zeigt die Obergrenzen der Formate. 128 MiB Nullbytes schrumpfen mit gzip auf 130 KB (Rate 1.030), mit xz auf 19,7 KB (6.827), mit zstd auf 4,1 KB (32.435), mit bzip2 auf 112 Bytes (1,2 Millionen) und mit brotli auf 102 Bytes (1,3 Millionen). Die Unterschiede stammen aus dem Format: Deflate kann pro Verweis höchstens 258 Bytes kopieren und braucht für 128 MiB über 500.000 Verweise, zstd speichert jeden 128-KiB-Block aus gleichen Bytes als RLE-Block von 4 Bytes, brotli erlaubt Kopien von bis zu 16 MiB, und bzip2 bringt eine Lauflängenkodierung mit.

In der Praxis treten solche Folgen in Disk-Images, vorbelegten Datenbankdateien und Sparse-Dateien auf. Die Obergrenze ist egal, weil schon eine Rate von 1.000 den Nullbereich auf ein Promille bringt. Wichtig ist, dass alle Verfahren Nullen schnell verarbeiten: zstd -3 lief hier mit 1.208 MB/s, bzip2 mit 126 MB/s.

Empfehlungen für die Praxis

Aus Messung und Gegenprobe ergeben sich sechs Regeln. Die ersten vier betreffen die Einstellungen des Clients, die letzten beiden gelten für jedes Backup.

Regel 1: ZSTD wählen und ausdrücklich eintragen

ZSTD lieferte in der Gegenprobe bei jeder komprimierbaren Quelle kleinere Archive als GZIP, beim Systemprotokoll knapp ein Drittel der Größe, und stellte drei- bis siebenmal so schnell wieder her. Mit 220 bis 760 MB/s auf komprimierbaren Daten packt es schneller, als die meisten Anschlüsse übertragen; ein Anschluss mit 1 Gbit/s nimmt 125 MB/s ab.

Tragen Sie compression_method: ZSTD ausdrücklich ein. Fehlt der Eintrag, komprimiert der Client mit GZIP. Wenn --autotune GZIP empfiehlt, liegt das an der Gewichtung des Packtempos (siehe Gegenprobe); GZIP war in der Gegenprobe erst oberhalb von etwa 750 Mbit/s Upload früher fertig und stellt auch dann deutlich langsamer wieder her.

Regel 2: Die Stufe 5 beibehalten

Stufe 5 ist der Standard und für fast alle Daten richtig. Stufe 1 spart bei ZSTD höchstens 40 Prozent Zeit und kostet 5 bis 35 Prozent mehr Speicherplatz. Stufe 9 lohnt sich für Text, Logs und Quellcode hinter einer schmalen Leitung oder wenn Speicherplatz knapp ist: Die Archive werden 8 bis 35 Prozent kleiner, das Packen dauert fünf- bis zehnmal so lange. In der Gegenprobe war ein Lauf mit Stufe 9 nur bei schmaler Leitung insgesamt früher fertig: für die Projektdateien unterhalb von etwa 130 Mbit/s Upload, für Programme unterhalb von etwa 70 Mbit/s, für das Systemprotokoll unterhalb von etwa 50 Mbit/s.

Regel 3: LZMA2 nur in Ausnahmefällen

Im Haupttest erreicht xz -6 eine um 28 Prozent höhere Rate als zstd -3. Im Client gilt das nicht: Seine LZMA2-Bibliothek erreicht auf komprimierbaren Daten nur 50 bis 92 Prozent der Rate von xz -6; ZSTD auf Stufe 9 komprimiert praktisch genauso stark oder stärker und ist knapp drei- bis sechsmal so schnell, bei Bildern 50-mal. LZMA2 entpackt 18- bis 44-mal langsamer als ZSTD und verarbeitet Daten, die nicht schrumpfen, mit rund 1 MB/s. Wer heute LZMA2 eingetragen hat, wechselt besser auf ZSTD, bei schmaler Leitung mit compression_level: 9; ältere Sicherungen bleiben lesbar, weil der Client das Verfahren beim Restore selbst erkennt.

Regel 4: Bereits Komprimiertes durchreichen

Fotos, Videos, Musik, fertige Archive, aktuelle Office-Dateien und verschlüsselte Container bleiben bei Rate 1,0. ZSTD reicht sie auf den Stufen 1 bis 5 mit über 1 GB/s durch; sie können deshalb mit anderen Daten in einer Konfiguration bleiben. Auf Stufe 9 sinkt das Tempo auf rund 55 MB/s. Liegen solche Daten in eigenen Verzeichnissen, ist eine zweite Konfiguration mit compression_level: 0 am schnellsten: Verschlüsselt wird trotzdem, und der Prozessor bleibt frei. Mit LZMA2 sollten solche Daten nie komprimiert werden.

Regel 5: Vor dem Backup aufräumen

Die größten Gewinne liegen vor dem Kompressor:

• Datenbanken als Dump sichern. Ein logischer Dump komprimiert 20 bis 40 Prozent besser als die Datenbankdatei. Ist der Dump schon mit gzip oder pigz gepackt, gehört er in eine Konfiguration mit compression_level: 0 (siehe Managed Database sichern).
• Messdaten runden. Auf die tatsächlich gemessene Genauigkeit gerundete Werte komprimieren doppelt so gut und belegen am Ende ein Viertel.
• Freie Blöcke in VM-Images nullen. Images, deren Gastsystem freie Blöcke mit Nullen überschreibt (sdelete -z, zerofree) oder per fstrim an ein Image mit Discard-Unterstützung freigibt, schrumpfen um den Anteil des freien Speichers.
• Kopien vermeiden. Das Fenster des Clients reicht 8 MiB zurück und endet an der Grenze einer Quelle. Projektkopien, mehrere Release-Stände oder dieselben Dateien unter zwei Pfaden speichert er mehrfach.

Regel 6: Nach dem Restore-Tempo fragen

Ein Backup wird selten geschrieben und im Ernstfall unter Zeitdruck gelesen. zstd dekomprimierte im Test mit 650 bis 910 MB/s pro Kern, xz mit 44 MB/s, bzip2 mit 19 MB/s. Wer für eine Rate von 3,0 statt 2,5 auf xz setzt, wartet im Ernstfall 15- bis 20-mal länger auf die Daten. Bei einem 2-TB-Server sind das rund 40 Minuten reine Dekompression mit zstd gegen einen halben Tag mit xz.

Die Entscheidungstabelle

Zwei Konfigurationen für einen typischen Server

Ein Server mit Anwendungsdaten, Datenbank-Dumps und einem Ordner mit Fotos braucht zwei Sicherungsaufträge. Der erste komprimiert mit ZSTD:

# /etc/lionbackup/server.yaml
lionbackup:
  name: server
  # … Projekt, Storage-Zone und Token wie gehabt …
  files:
    - /srv/app
    - /srv/dumps
    - /var/log
  compression_method: ZSTD   # ausdrücklich setzen, ohne Angabe gilt GZIP
  compression_level: 5
  encryption_keyfile: /etc/lionbackup/backup.pub

Der zweite reicht die Fotos ohne Kompression durch:

# /etc/lionbackup/medien.yaml
lionbackup:
  name: medien
  # … Projekt, Storage-Zone und Token wie gehabt …
  files:
    - /srv/fotos
  compression_level: 0       # nicht komprimieren, verschlüsselt wird trotzdem
  encryption_keyfile: /etc/lionbackup/backup.pub

Beide laufen nacheinander, etwa als zwei Aufrufe mit --config im selben Zeitplan.

Fazit

Kompression ist kein Schieberegler zwischen klein und schnell, sondern eine Eigenschaft der Daten, die ein Verfahren mehr oder weniger vollständig ausschöpft. Die Datenart bestimmt die Größenordnung: Logs, strukturierte Daten und Quellcode schrumpfen auf ein Sechstel bis ein Neuntel, Datenbanken auf ein Drittel bis ein Fünftel, VM-Images auf ein Drittel, Programmdateien auf weniger als die Hälfte. Was bereits entropiekodiert oder verschlüsselt ist, bleibt, wie es ist. Das Verfahren bestimmt innerhalb dieser Größenordnung die letzten 20 bis 60 Prozent und vor allem, wie viel Zeit sie kosten.

zstd hat in diesem Spannungsfeld die beste Position: die Rate von gzip bei achtfachem Tempo, die schnellste Dekompression im Test und große Fenster im selben Format. Die Gegenprobe bestätigt das für den lionbackup-Client mit zwei Einschränkungen. LZMA2 ist dort schwächer als xz und lohnt sich praktisch nie, und GZIP packt auf Rechnern mit vielen Kernen schneller, verliert aber bei Größe und Restore.

Die beiden Erkenntnisse mit der größten praktischen Wirkung stehen nicht in der Stufenliste. Erstens entscheidet bei redundanten Daten das Fenster mehr als die Stufe. Zweitens findet die wirksamste Kompression vor dem Kompressor statt: beim Dumpen von Datenbanken, beim Runden von Messdaten, beim Nullen freier Blöcke und beim Aussortieren dessen, was ohnehin nicht schrumpft.

Anhang: Messverfahren und Reproduktion

Messverfahren

Jede Messung ruft das Werkzeug als eigenen Prozess mit der Testdatei auf der Standardeingabe und der komprimierten Ausgabe in eine temporäre Datei auf, danach den Dekompressor mit dieser Datei und /dev/null als Ausgabe. Vor jeder Messung wird die Datei einmal gelesen, damit sie im Seitencache liegt. Die Zeit ist die Wanduhrzeit zwischen Prozessstart und -ende, der Speicher die maximale Resident Set Size aus wait4. Jede Kombination wurde einmal gemessen; bei Dateien unter 10 MB dominiert der Prozessstart die Zeitmessung, die Durchsatzwerte der kleinen Silesia-Dateien und des Text-PDFs sind deshalb nur Richtwerte.

Aufrufe

lz4 -1 -B7 -c            lz4 -d -c
gzip -N -c               gzip -d -c
zstd -N -c -q -T1        zstd -d -c -q
zstd -N --long=27 -c -q  zstd -d -c -q --long=27
brotli -q N -c           brotli -d -c
bzip2 -9 -c              bzip2 -d -c
xz -N -c -T1             xz -d -c

lz4 lief mit 4-MB-Blöcken (-B7), weil die Standardeinstellung bei Eingabe über die Standardeingabe deutlich kleinere Blöcke verwendet. zstd und xz liefen mit -T1 einkernig, damit alle Verfahren denselben Kern teilen. Die synthetischen Testdaten entstehen deterministisch aus dem Seed 20261105.

Gegenprobe mit dem Client

Gemessen wurde der lionbackup-Client 0.1.35, gebaut aus dem Entwicklungsstand vom 6. November 2026 mit Go 1.27.3, klauspost/compress v1.20.3, klauspost/pgzip v1.3.0 und ulikunitz/xz v0.5.17. Die Raten stammen aus --autotune mit compression_level 1, 5 und 9. Für die Durchsätze hat ein kleines Go-Programm die Bibliotheken mit denselben Einstellungen wie der Client aufgerufen, die Daten im Arbeitsspeicher komprimiert und wie beim Restore wieder entpackt, dreimal je Messung; LZMA2 auf den Bildern lief einmal. Die Referenzwerkzeuge liefen auf denselben tar-Strömen: zstd und xz mit -T1, gzip und pigz mit Stufe 5.

Bekannte Einschränkungen

Die synthetischen Geschäftsdaten verwenden ein begrenztes Vokabular und komprimieren etwas besser als echte Kundendaten. Die HTML-Seiten und die Mailbox ziehen ihren Fließtext aus einem begrenzten Satzvorrat; Verfahren mit großem Fenster profitieren dort überdurchschnittlich, die Werte für xz -9 und zstd -19 sind deshalb nur eingeschränkt übertragbar. Die synthetischen Fotos enthalten mehr Rauschen als typische Kameraaufnahmen; die Raten für BMP und TIFF sind eine Untergrenze. Die Gegenprobe lief auf einem Notebook mit variablem Turbotakt, auf dem nebenher weitere Programme liefen; ihre Durchsätze schwanken dort um rund 20 Prozent. Ihre vier Quellen sind mit 17 bis 69 MB klein. Für die Raten genügt das, das Tempo auf großen Quellen und auf Servern mit anderen Prozessoren kann abweichen.

Versionen

Haupttest: Ubuntu 24.04.5 LTS, Intel Xeon 2,1 GHz (ein Kern), 3,9 GB RAM; gzip 1.12, bzip2 1.0.8, xz 5.4.5, zstd 1.5.5, lz4 1.9.4, brotli 1.1.0, qemu-img 8.2.2, genisoimage 1.1.11, Python 3.12 mit reportlab, python-docx, python-pptx, openpyxl, xlwt, Pillow und NumPy. Silesia-Korpus in der Fassung des GitHub-Mirrors MiloszKrajewski/SilesiaCorpus, Go-Quellcode von klauspost/compress mit Stand vom 5. November 2026. Gegenprobe: Ubuntu 26.04.1 LTS, Intel Core i5-1235U (10 Kerne, 12 Threads), 14 GB RAM; zstd 1.5.7, xz 5.8.3, gzip 1.14, pigz 2.8.

Ausprobieren

Den Client gibt es unter Downloads, den Quelltext und das Benutzerhandbuch mit allen Konfigurationsoptionen im öffentlichen Repository. Wenn Sie --autotune auf Ihren eigenen Daten laufen lassen, sehen Sie in wenigen Minuten, welche Rate Ihr Backup erreicht.