Seit sechs Monaten läuft ZFS auf zwei meiner Server. Kein Laboraufbau, sondern Alltag: ein Media-Server mit sechs 8-TB-Platten im RAIDZ2 und ein Backup-Server mit vier 4-TB-Platten als zwei Spiegel. Dazu ein dritter Server, ein kleiner Webhost mit einer einzelnen NVMe, auf dem bewusst weiter ext4 läuft. Was ich in diesen sechs Monaten erlebt habe, hat meine Meinung zu Dateisystemen verändert. Allerdings nicht in die Richtung, die ich erwartet hatte.

Der Moment, der mich überzeugt hat, war ein simpler Fehler. Ein Kollege hat in einem geteilten Ordner aufgeräumt und dabei den falschen Unterordner gelöscht. Zwei Jahre Projektarbeit, weg. Auf dem alten ext4-Server hätte das eine zweistündige Wiederherstellung aus einem Backup-Image bedeutet, mit Rückfragen, welcher Stand überhaupt noch existiert. Auf dem ZFS-Server dauerte es vier Minuten. Vier Minuten zwischen dem Anruf und dem Moment, in dem der Ordner wieder da war, inklusive aller Zwischenstände vom selben Morgen.

Vergleich ZFS, ext4 und btrfs im Alltag

Die Geschichte: Vier Minuten statt zwei Stunden

Das Zauberwort heißt Snapshot. ZFS legt im laufenden Betrieb Momentaufnahmen des Dateisystems an, ohne dass die Leistung spürbar leidet. Seit dem ersten Tag läuft bei mir ein Cronjob, der jeden Morgen um sechs Uhr einen Snapshot erstellt. Als der Anruf kam, war die Diagnose eine Zeile lang:

zfs list -t snapshot tank/data

Die Ausgabe listet alle Snapshots mit Zeitstempel. Der von heute Morgen war noch da, gelöscht wurde erst am Mittag. Ich hatte zwei Optionen. Die konservative: den Snapshot über das versteckte .zfs-Verzeichnis mounten und nur den gelöschten Ordner zurückkopieren.

ls /tank/data/.zfs/snapshot/2026-09-17-0600/

Die schnelle: da in dem Dateisystem seit dem Snapshot nichts Neues passiert war, ein Rollback.

sudo zfs rollback tank/data@2026-09-17-0600

Vier Minuten später war der Ordner zurück, auf dem Stand von heute Morgen. Kein Image einspielen, keine Downtime, keine Frage, welche Backup-Version die richtige ist. Genau dieser Unterschied ist der Grund, warum ich heute keine Maschine mit wichtigen Daten mehr ohne Snapshots betreiben möchte.

Checksummen: Der stille Tod der Daten

ext4 vertraut der Platte. Was einmal geschrieben wurde, wird beim Lesen nicht geprüft. Das klingt harmlos, bis eine Platte anfängt, still Daten zu verfälschen. Bitrot nennen wir das: einzelne Blöcke kippen, ohne dass jemand es merkt. SMART meldet nichts, der Controller meldet nichts, und das Dateisystem reicht die kaputten Daten einfach weiter.

ZFS legt zu jedem Block eine Prüfsumme ab und verifiziert sie beim Lesen. Stimmt sie nicht, wird der Block aus einer anderen Kopie rekonstruiert, falls eine existiert, oder als Fehler gemeldet. Bewusst geworden ist mir das beim ersten vollständigen Scrub meines 24-TB-Pools:

sudo zpool scrub tank

Neun Stunden lief der Scrub über die sechs Platten. Ergebnis: null Fehler. Einen Monat später meldete der nächste Scrub genau einen Checksummen-Fehler auf einer Platte, die SMART als gesund auswies. Ohne ZFS hätte ich den nie gesehen. Irgendwann wäre genau die Datei unlesbar gewesen, deren einzige Kopie auf diesem Sektor lag, und niemand hätte gewusst, warum.

Snapshots: Zeitreisen für Admins

Snapshots sind für mich der größte praktische Vorteil von ZFS. Sie sind fast kostenlos: Ein Snapshot belegt nur Speicher für die Blöcke, die sich danach ändern. Das Anlegen dauert Sekundenbruchteile, egal wie groß der Pool ist. Deshalb kann man sich eine Snapshot-Kultur leisten, die mit klassischen Backups unmöglich wäre.

Wer den Überblick über Datasets und Platzverbrauch behalten will, nutzt zfs list:

zfs list

Die Ausgabe zeigt für jedes Dataset Größe, Verbrauch und Referenz. Wer wissen will, welche Snapshots existieren, ergänzt -t snapshot.

Snapshots per Einzeiler: sudo zfs snapshot -r tank@auto-$(date +%F)
Das -r erfasst alle Datasets des Pools. Dazu ein wöchentlicher Snapshot, der vier Wochen aufbewahrt wird. Damit lässt sich jede Nacht zurückspulen, ohne dass jemand etwas konfigurieren muss.

Eine Regel gehört dazu: Snapshots ersetzen kein Backup. Sie schützen vor versehentlichem Löschen, vor kaputten Updates und vor Ransomware, die Dateien verschlüsselt. Aber sie liegen auf derselben Hardware wie die Daten. Brennt der Server ab, sind beide weg. Genau dafür gibt es send und receive.

Backup mit send/receive

zfs send und zfs receive streamen Snapshots über die Leitung. Das Schöne daran: Übertragen werden nur die Unterschiede zwischen zwei Snapshots, nicht jedes Mal alles. Mein Backup-Server zieht jeden Morgen den neuesten Snapshot des Media-Servers:

zfs send tank/data@2026-09-17-0600 | zfs receive backup/tank

Die erste Übertragung war ein voller 12-TB-Stream über Nacht. Seitdem sind es jeden Tag ein paar hundert Megabyte. Das Backup steht damit immer exakt auf dem Stand des letzten Snapshots. Und weil auf dem Zielsystem ebenfalls ZFS läuft, habe ich dort dieselben Prüfsummen und Snapshots wie auf dem Quellsystem, inklusive der Möglichkeit, den Stream jederzeit anzuhalten und später fortzusetzen.

ARC: Der RAM-Hunger

Der Preis für all das ist Arbeitsspeicher. ZFS hält einen großen Teil des RAM als Cache, die ARC (Adaptive Replacement Cache). Standardmäßig frisst sie sich bis zur Hälfte des physischen Speichers hoch. Auf meinem Media-Server mit 32 GB RAM sind das bis zu 16 GB. Das ist kein Bug, sondern Design: Freier RAM ist verschwendeter RAM.

Auf dem kleinen Webhost mit 8 GB RAM und einer einzigen NVMe wäre genau das ein Problem. ZFS würde dauerhaft mehrere Gigabyte für einen Cache reservieren, den eine schnelle NVMe kaum braucht, während PHP und Datenbank um denselben Speicher konkurrieren. Man kann die Obergrenze über den Kernel-Parameter zfs_arc_max deckeln. Aber dann verwaltet man manuell, was ZFS eigentlich automatisch kann.

Und dann ist da Dedup. Deduplizierung klingt verlockend, kostet aber pro Block einen Eintrag im RAM. Auf einem Pool mit ein paar Terabyte Daten spricht man schnell von zehn oder mehr Gigabyte Arbeitsspeicher nur für die Dedup-Tabelle. Ich habe Dedup auf keinem Server aktiviert. Kompression ist der bessere Deal: lz4 oder zstd kosten fast nichts und sparen auf Log- und Textdaten regelmäßig 30 bis 50 Prozent.

Wo ext4 weiter gewinnt

Jetzt zur Gegenrede. Mein dritter Server läuft bewusst weiter mit ext4. Ein kleiner VPS mit einer 1-TB-NVMe, 8 GB RAM und einem einzigen Zweck: Webhosting mit ein paar Docker-Containern. Kein RAID, keine riesigen Dateien, keine Daten, die es nicht auch woanders gäbe.

ext4 gewinnt dort aus drei Gründen. Erstens: null Verwaltung. Ich habe in zehn Jahren noch nie einen ext4-Server wegen des Dateisystems warten müssen. Kein Scrub, keine Pool-Importe nach einem Kernel-Update, kein Nachdenken über ashift oder record size. Zweitens: RAM. ZFS würde dauerhaft mehrere Gigabyte belegen, die ich lieber den Containern gebe. Drittens: Vorhersagbarkeit. Stirbt auf einem einzelnen Laufwerk die Platte, ist der Unterschied zwischen ext4 und ZFS ohne Redundanz klein. Beide verlieren die Daten. ZFS ohne Spiegel oder RAIDZ ist im Kern ein ext4 mit Prüfsummen, das mehr RAM frisst.

Das ist die ehrliche Rechnung: ZFS zahlt sich ab einer gewissen Datenmenge aus, bei Redundanz, bei vielen kleinen Dateien, bei der Angst vor stillem Datenverlust. Für einen einzelnen Datenträger mit überschaubaren Daten ist ext4 das pragmatischere Werkzeug. Dateisysteme sind Werkzeuge, keine Glaubensfragen.

RAIDZ gegen RAID 5/6: Der Preis der Parität

Wer mit ZFS ein RAID baut, sollte den Unterschied zum klassischen RAID kennen. RAIDZ1 entspricht von der Parität her RAID 5, RAIDZ2 entspricht RAID 6, RAIDZ3 hat keine klassische Entsprechung. Die nutzbare Kapazität ist identisch: Bei RAIDZ2 mit sechs Platten gehen zwei Platten für Parität drauf, genau wie bei RAID 6.

Was viele unterschätzen, ist der Schreib-Penalty. Ein Schreibzugriff kostet bei RAID 5 vier IOs (zwei lesen, zwei schreiben), bei RAID 6 sechs. Bei RAIDZ ist es nicht besser, im Gegenteil: ZFS schreibt bevorzugt ganze Stripe-Sets, und kleine zufällige Schreibzugriffe, wie Datenbanken sie erzeugen, sind auf RAIDZ-Pools der teuerste Fall überhaupt. Wer viele Random Writes hat, fährt mit einem Spiegel-Pool oder RAID 10 besser.

Für genau diese Planung gibt es die Rechner auf bitcalc.net. Der IOPS-Rechner zeigt, was ein RAID-Level an Schreibzugriffen kostet. Der RAID-Rechner rechnet die nutzbare Kapazität für RAID 5, RAID 6, RAIDZ und Spiegel aus, bevor man Platten bestellt.

Fazit

Nach sechs Monaten ZFS ist mein Fazit klar. Für Server mit mehreren Platten, mit Daten, die niemand verlieren will, und mit Lust auf Snapshots gibt es aktuell keinen guten Grund, an ext4 festzuhalten. Die vier Minuten für den gelöschten Ordner haben mehr überzeugt als jede Benchmark. Aber der kleine VPS bleibt auf ext4, und das ist keine Schande. Das richtige Dateisystem ist das, das zur Aufgabe passt. Nicht das mit der längeren Feature-Liste.