Was ist ZFS? Dateisystem und Volume-Manager einfach erklärt

Kurz gesagt: ZFS ist Dateisystem und Volume-Manager in einem. Es fasst Platten zu einem Pool zusammen, kümmert sich selbst um Redundanz und legt darauf Dateisysteme und Blockgeräte an. Weil ZFS nie Daten an Ort und Stelle überschreibt (Copy-on-Write) und jeden Block mit einer Prüfsumme absichert, erkennt es stille Datenfehler, ist nach einem Stromausfall immer konsistent und kann Snapshots fast ohne Kosten anlegen. Kaputte Daten reparieren kann es aber nur, wenn eine zweite Kopie existiert, also in einem Mirror oder RAIDZ.

Dieser Guide ist für dich, wenn du über ein NAS, einen Backupserver oder einen Proxmox-Host nachdenkst und wissen willst, was ZFS eigentlich anders macht als ein gewöhnliches Linux-Dateisystem. Du brauchst noch kein ZFS-Wissen. Am Ende kannst du ZFS einordnen und hast im Test gesehen, wie ZFS einen Datenfehler erkennt und repariert.

Voraussetzungen #

• Grundkenntnisse in der Linux-Kommandozeile (Befehle mit sudo ausführen, Dateien ansehen).
• Für den Praxisteil ein Testsystem mit installiertem OpenZFS, etwa eine virtuelle Maschine. Wie die Installation geht, steht in OpenZFS unter Debian 13 installieren.
• Keine echten Platten nötig: Der Versuch läuft mit Dateien als Ersatzplatten.

Lernziel: Du verstehst, wie ZFS Daten speichert und schützt, kennst seine Grenzen und kannst entscheiden, ob es zu deinem Vorhaben passt.

Woher ZFS kommt #

ZFS wurde ursprünglich für das Betriebssystem Solaris entwickelt. Heute pflegt die OpenZFS-Community den Code; das Hauptrepository enthält laut Projekt-README den Code für Linux und FreeBSD. Vor Version 2.0 hieß der Linux-Zweig „ZFS on Linux“; seit 2.0 (Ende 2020) gibt es eine gemeinsame Codebasis unter dem Namen OpenZFS. Stand Oktober 2026 ist OpenZFS 2.4.4 die aktuelle Version; daneben werden die Zweige 2.3 und 2.2 noch gepflegt.

Eine Besonderheit ist die Lizenz. OpenZFS steht unter der CDDL, der Linux-Kernel unter der GPL Version 2. Laut OpenZFS-Doku darf OpenZFS deshalb nicht als Teil des Kernel-Binärs verteilt werden, wohl aber als separates Kernelmodul. In der Praxis heißt das:

• Debian liefert ZFS im Bereich contrib und baut das Kernelmodul bei der Installation per DKMS (ein Mechanismus, der Module passend zum installierten Kernel übersetzt).
• Ubuntu bringt das fertige Modul im Kernelpaket mit; du installierst nur noch die Werkzeuge.
• Proxmox VE und TrueNAS haben ZFS fest eingebaut.

Jede OpenZFS-Version unterstützt nur einen bestimmten Bereich von Kernelversionen, 2.4.4 laut Release-Notes etwa Linux 4.18 bis 7.2. Wer sehr neue Kernel einsetzt, muss also darauf achten, dass die ZFS-Version mitkommt.

Dateisystem und Volume-Manager in einem #

Unter Linux ist Speicher klassisch in Schichten organisiert: unten die Platten, darüber eventuell ein Software-RAID, darüber ein Volume-Manager, der Speicher in Bereiche aufteilt, und ganz oben ein Dateisystem wie ext4. Jede Schicht weiß nur wenig über die anderen.

ZFS fasst diese Schichten zusammen:

• Ein Pool ist laut Manpage eine logische Sammlung von Geräten, die Platz für Datasets bereitstellt.
• Der Pool besteht aus einem oder mehreren vdevs (virtuellen Geräten). Ein vdev ist zum Beispiel ein Mirror (Spiegel, gleiche Daten auf zwei oder mehr Platten) oder ein RAIDZ (Paritätsverfahren ähnlich RAID 5 oder 6). Die Redundanz steckt immer im einzelnen vdev.
• Auf dem Pool legst du Datasets an: Dateisysteme, die sich den Platz im Pool teilen, oder ZVOLs, also Blockgeräte, etwa als virtuelle Platte für eine VM.

Weil ZFS alle Schichten kennt, weiß es bei einem Lesefehler genau, welche Platte welchen Block falsch geliefert hat, und kann gezielt reparieren. Die Begriffe im Detail erklärt ZFS-Begriffe verstehen.

Copy-on-Write: nie an Ort und Stelle überschreiben #

Ändert ein klassisches Dateisystem eine Datei, schreibt es die neuen Daten oft direkt über die alten. Fällt dabei der Strom aus, kann ein halb geschriebener Zustand übrig bleiben.

ZFS arbeitet nach dem Prinzip Copy-on-Write: Ein Block, der in Gebrauch ist, wird nie überschrieben. Die neue Version landet an einer freien Stelle, danach schaltet ZFS auf sie um. Schreibvorgänge sammelt ZFS in Transaktionsgruppen (txg) und schreibt sie gemeinsam. Ganz oben in der Baumstruktur steht der sogenannte Uberblock, von dem aus alle Daten im Pool erreichbar sind.

Daraus folgen drei wichtige Eigenschaften:

1. Immer konsistent: Laut OpenZFS-Doku ist ein Pool auf der Platte immer in einem stimmigen Zustand, egal wann der Strom ausfällt. Nach einem Absturz startet er beim letzten vollständig geschriebenen Stand, im Zweifel also ein paar Sekunden älter. Ein Dateisystem-Check beim Einhängen wie fsck ist deshalb nicht nötig.
2. Günstige Snapshots: Ein Snapshot hält einfach die alten Blöcke fest, statt sie freizugeben. Kopiert wird nichts.
3. Kehrseite Fragmentierung: Wird eine Datei häufig in Teilen umgeschrieben, verteilen sich ihre Blöcke über die Platte. Außerdem reagiert ZFS empfindlich auf einen vollen Pool, weil es zum Schreiben (und selbst zum Löschen) freien Platz braucht. Die Tuning-Seite der Doku empfiehlt, mehr als 10 % des Pools frei zu halten.

Prüfsummen für jeden Block #

ZFS berechnet für jeden Block eine Prüfsumme (ein kurzer Fingerabdruck der Daten) und speichert sie nicht beim Block selbst, sondern im übergeordneten Blockzeiger, also in den Metadaten, die auf den Block verweisen. Beim Lesen vergleicht ZFS die Daten mit dieser Prüfsumme. Liefert eine Platte unbemerkt falsche Daten, etwa durch einen schleichenden Speicherfehler auf dem Datenträger (oft „Bit Rot“ genannt), fällt das sofort auf.

Standard ist checksum=on, laut Doku eine Kurzform für den Algorithmus fletcher4 (bei deduplizierten Datasets sha256). Abschalten lässt sich das zwar, die Doku rät aber ausdrücklich davon ab.

Wichtig ist die Grenze: Die Prüfsumme schützt die Daten ab dem Moment, in dem ZFS sie berechnet. Wird ein Wert vorher im Arbeitsspeicher verfälscht, etwa durch einen defekten RAM-Riegel, sieht ZFS das nicht. Deshalb empfiehlt die OpenZFS-Doku ECC-Speicher (mehr dazu in Welche Hardware braucht ZFS?).

Selbstheilung, aber nur mit Redundanz #

Erkennt ZFS einen fehlerhaften Block und gibt es eine zweite Kopie, holt es die intakte Version, liefert sie an das Programm aus und überschreibt die kaputte Stelle. Das passiert beim normalen Lesen und bei einem Scrub, einem Prüflauf, der alle Daten im Pool liest und gegen ihre Prüfsummen vergleicht.

Ohne zweite Kopie kann ZFS den Fehler zwar melden, aber nicht beheben. Die OpenZFS-Doku formuliert es sinngemäß so: Prüfsummen ohne zweite Kopie sagen dir nur, was du bereits verloren hast. Genau das zeigt der Versuch weiter unten.

Snapshots #

Ein Snapshot ist laut Manpage eine nur lesbare Kopie eines Dateisystems oder Volumes zu einem bestimmten Zeitpunkt. Er entsteht sehr schnell und belegt anfangs keinen zusätzlichen Platz. Erst wenn sich Daten im aktiven Dataset ändern, wächst der Snapshot, weil er die alten Blöcke festhält.

Snapshots schützen vor versehentlichem Löschen, missglückten Updates oder Schadsoftware, die Dateien überschreibt, solange sie keine Root-Rechte auf dem Server hat (mit Root lassen sich Snapshots löschen). Sie liegen aber im selben Pool: Stirbt der Pool, sind auch alle Snapshots weg. Wie du sie nutzt, zeigt ZFS-Snapshots verstehen und nutzen.

Weitere Funktionen im Überblick #

• Kompression: Seit OpenZFS 2.2 ist compression=on Standard, meist gleichbedeutend mit dem schnellen Verfahren LZ4 (ZFS-Kompression).
• Replikation: Mit zfs send und zfs receive überträgst du Snapshots auf einen anderen Pool, auch inkrementell über das Netzwerk (ZFS send und receive).
• Verschlüsselung: pro Dataset, direkt in ZFS eingebaut (ZFS-Verschlüsselung).
• Quotas und Reservierungen: Platzgrenzen pro Dataset (Datasets und ZVOLs).

Grenzen und Nachteile #

ZFS ist kein Allheilmittel. Diese Punkte solltest du vorher kennen:

• Planung statt Umbauen: Ein Pool lässt sich vergrößern, aber nicht beliebig umbauen. Enthält ein Pool ein RAIDZ-vdev, lassen sich laut Doku keine Top-Level-vdevs mehr entfernen. Ein RAIDZ-vdev um einzelne Platten erweitern geht erst seit OpenZFS 2.3 und mit Einschränkungen (Pool erweitern und Platten ersetzen).
• Ein vdev weg, Pool weg: Laut Doku ist der ganze Pool verloren, wenn ein Top-Level-vdev ausfällt. Ein Pool aus zwei einzelnen Platten ohne Spiegel verkraftet also keinen einzigen Plattenausfall.
• Modul außerhalb des Kernels: Unter Debian muss DKMS das Modul nach Kernel-Updates neu bauen. Das klappt normalerweise automatisch, ist aber eine zusätzliche Fehlerquelle.
• RAM-Nutzung: ZFS nutzt freien Arbeitsspeicher als Lesecache, den ARC. Hohe Belegung ist gewollt und kein Speicherleck. Wie viel RAM wirklich nötig ist, klärt Wie viel RAM braucht ZFS?.
• Keine Hardware-RAID-Schicht darunter: ZFS will die Platten direkt sehen, sonst verliert es seine Reparaturmöglichkeiten.
• Redundanz ist kein Backup: Ein Mirror schützt vor Plattenausfall, nicht vor versehentlichem Löschen in allen Kopien, Brand oder Diebstahl.

Wofür sich ZFS eignet #

• Datei-NAS und Backupserver: Prüfsummen, Scrubs und Snapshots sind genau das, was man für langlebige Daten will. Mit zfs send lassen sich Sicherungen effizient auf einen zweiten Server spiegeln.
• Virtualisierungshost: Proxmox VE bietet ZFS direkt im Installer an, VM-Platten werden zu ZVOLs (ZFS in Proxmox VE).
• Fertige NAS-Systeme: TrueNAS baut komplett auf ZFS auf (TrueNAS und ZFS verstehen).
• Einzelne Platte: Möglich, du bekommst Snapshots, Kompression und Fehlererkennung. Selbstheilung gibt es dann aber nicht.

Ob ZFS, ext4 oder Btrfs für dich besser passt, vergleicht ZFS vs. ext4 vs. Btrfs.

Selbst ausprobieren: Fehler erkennen und reparieren #

Der folgende Versuch lief genau so in einer Testumgebung mit Debian 13 und OpenZFS 2.4.4. Statt echter Platten dienen leere Dateien im Ordner /var/tmp/zfs-test als vdevs. Die OpenZFS-Doku rät von Dateien als Speicher für echte Daten deutlich ab, für Experimente sind sie aber ideal.

Achtung: Führe den Versuch nur auf einem Testsystem aus. zpool create und das spätere Beschädigen mit dd sind nur mit den hier angelegten Testdateien ungefährlich. Ein vertippter Pfad auf eine echte Platte zerstört deren Inhalt. Der Pool heißt bewusst testpool; gibt es auf deinem System schon einen Pool mit diesem Namen (zpool list), wähle einen anderen, damit das Aufräumen am Ende nicht den falschen trifft.

Mirror anlegen #

sudo mkdir -p /var/tmp/zfs-test
sudo truncate -s 512M /var/tmp/zfs-test/d1 /var/tmp/zfs-test/d2
sudo zpool create -o ashift=12 testpool mirror /var/tmp/zfs-test/d1 /var/tmp/zfs-test/d2
sudo zpool status testpool

truncate legt zwei leere 512-MiB-Dateien an, zpool create baut daraus den Pool testpool mit einem Mirror-vdev, und zpool status zeigt den Aufbau:

  pool: testpool
 state: ONLINE
config:
 
	NAME                      STATE     READ WRITE CKSUM
	testpool                  ONLINE       0     0     0
	  mirror-0                ONLINE       0     0     0
	    /var/tmp/zfs-test/d1  ONLINE       0     0     0
	    /var/tmp/zfs-test/d2  ONLINE       0     0     0
 
errors: No known data errors

Testdaten schreiben und Snapshot anlegen #

sudo zfs create -o compression=off testpool/daten
yes "LABKOMPASS-TESTDATEN-0123456789" | head -c 8M | sudo tee /testpool/daten/bericht.txt > /dev/null
sha256sum /testpool/daten/bericht.txt
sudo zfs snapshot testpool/daten@vorher

Der erste Befehl legt ein Dataset an. Die Kompression ist hier nur für den Versuch aus, damit sich die Testdaten in der Datei wiederfinden lassen. Dann entsteht eine 8 MiB große Textdatei, sha256sum berechnet ihren Fingerabdruck, und zfs snapshot hält den Stand fest:

ead7d57c1e9dd2d7850de5a02bffbd4de8e9689c39e5618de8498e7dd5fe754f  /testpool/daten/bericht.txt

Eine Seite des Spiegels beschädigen #

Jetzt simulierst du eine Platte, die stillschweigend falsche Daten liefert. Dazu exportierst du den Pool (er wird sauber ausgehängt) und suchst die Testdaten in der ersten Datei:

sudo zpool export testpool
sudo grep -obUa -m1 "LABKOMPASS" /var/tmp/zfs-test/d1 | head -1

4579328:LABKOMPASS

Die Zahl vor dem Doppelpunkt ist die Position in Byte. Geteilt durch 4096 ergibt sie den Startblock für dd, in diesem Lauf 1118. Bei dir kann die Zahl anders lauten, setze dann deinen Wert ein:

sudo dd if=/dev/urandom of=/var/tmp/zfs-test/d1 bs=4096 seek=1118 count=1024 conv=notrunc
sudo zpool import -d /var/tmp/zfs-test testpool
sha256sum /testpool/daten/bericht.txt
sudo zpool status testpool

dd überschreibt 4 MiB der ersten Datei mit Zufallsdaten, mitten im Bereich der Testdaten; conv=notrunc verhindert, dass die Datei dabei gekürzt wird. zpool import -d sucht Pools in diesem Verzeichnis und importiert den Pool wieder. Ergebnis:

ead7d57c1e9dd2d7850de5a02bffbd4de8e9689c39e5618de8498e7dd5fe754f  /testpool/daten/bericht.txt
…
status: One or more devices has experienced an unrecoverable error.  An
	attempt was made to correct the error.  Applications are unaffected.
…
	NAME                      STATE     READ WRITE CKSUM
	testpool                  ONLINE       0     0     0
	  mirror-0                ONLINE       0     0     0
	    /var/tmp/zfs-test/d1  ONLINE       0     0     2
	    /var/tmp/zfs-test/d2  ONLINE       0     0     0

Die Datei hat denselben Fingerabdruck wie vorher, das Programm hat also korrekte Daten bekommen. In der Spalte CKSUM zählt ZFS die Fehler, bei denen die Prüfsumme nicht passte. Im Test waren es beim Lesen nur zwei: Ein Mirror liest jeden Block nur von einer Seite, und nur wenn ZFS dabei die beschädigte Seite erwischt, fällt der Fehler auf.

Scrub: alles prüfen und reparieren #

sudo zpool scrub -w testpool
sudo zpool status testpool

zpool scrub liest alle Daten im Pool von allen Seiten, -w wartet, bis der Lauf fertig ist:

  scan: scrub repaired 1.88M in 00:00:01 with 0 errors on Sun Oct 11 18:09:49 2026
…
	    /var/tmp/zfs-test/d1  ONLINE       0     0    17
	    /var/tmp/zfs-test/d2  ONLINE       0     0     0
 
errors: No known data errors

Der Scrub hat 1,88 MiB auf der beschädigten Seite aus der intakten Kopie neu geschrieben. Mit sudo zpool clear testpool setzt du die Fehlerzähler zurück; ein zweiter Scrub meldete im Test repaired 0B.

Gegenprobe ohne Redundanz #

Derselbe Ablauf mit einem Pool aus nur einer Datei endet anders. Statt des Mirrors entsteht dabei ein Einzel-vdev:

sudo truncate -s 512M /var/tmp/zfs-test/d3
sudo zpool create -o ashift=12 einzel /var/tmp/zfs-test/d3

Danach folgen dieselben Schritte wie oben: Dataset mit compression=off anlegen, Testdatei schreiben, Pool exportieren, Position mit grep suchen, mit dd beschädigen (hier ab Block 1115) und wieder importieren. Schon das Lesen scheitert:

sha256sum: /einzel/daten/bericht.txt: Input/output error

ZFS gibt also lieber gar keine Daten heraus als falsche. Nach sudo zpool scrub -w einzel nennt sudo zpool status -v einzel die betroffene Datei:

status: One or more devices has experienced an error resulting in data
	corruption.  Applications may be affected.
action: Restore the file in question if possible.  Otherwise restore the
	entire pool from backup.
…
  scan: scrub repaired 0B in 00:00:00 with 32 errors on Sun Oct 11 18:10:05 2026
…
errors: Permanent errors have been detected in the following files:
 
        /einzel/daten/bericht.txt

Die Datei ist verloren und muss aus einem Backup kommen. Das ist der Kern dieses Guides: ZFS erkennt Fehler, reparieren kann es nur mit Redundanz.

Ergebnis prüfen #

Diese lesenden Befehle zeigen dir jederzeit den Zustand:

sudo zpool status -x testpool
sudo zfs list -t snapshot -r testpool

zpool status -x meldet nur Probleme und sonst eine Kurzzeile, zfs list -t snapshot zeigt die vorhandenen Snapshots:

pool 'testpool' is healthy
NAME                    USED  AVAIL  REFER  MOUNTPOINT
testpool/daten@vorher     0B      -  8.10M  -

Aufräumen #

Achtung: zpool destroy löscht einen Pool samt allen Daten und Snapshots ohne Rückfrage. Prüfe die Poolnamen vorher mit zpool list.

sudo zpool destroy einzel
sudo zpool destroy testpool
sudo rm /var/tmp/zfs-test/d1 /var/tmp/zfs-test/d2 /var/tmp/zfs-test/d3

Die ersten beiden Befehle entfernen die Testpools, der dritte die Ersatzplatten.

Häufige Fehler #

• „ZFS repariert doch alles“ → Selbstheilung braucht eine zweite Kopie → für wichtige Daten Mirror oder RAIDZ planen und zusätzlich ein Backup anlegen.
• CKSUM-Fehler, aber die Platte ist neu → Prüfsummenfehler entstehen auch durch Kabel, Controller oder RAM → nicht sofort die Platte tauschen, sondern erst eingrenzen (ZFS-Troubleshooting).
• Snapshots als einziges Backup → Pool weg, Snapshots weg → Snapshots zusätzlich per zfs send auf ein zweites System übertragen (ZFS-Backup-Strategien).
• ZFS auf einem Hardware-RAID-Volume → ZFS sieht nur eine „Platte“ und kann nicht gezielt reparieren → Platten direkt anbinden (Welche Hardware braucht ZFS?).
• Pool läuft bis zum Rand voll → ZFS wird langsam und braucht selbst zum Löschen Platz → rechtzeitig erweitern oder aufräumen, Kapazität vorher mit dem ZFS-Kapazitätsrechner planen.

Weiterlesen #

• ZFS-Begriffe verstehen erklärt Pool, vdev, Dataset, ARC und Co. mit Diagramm.
• ZFS vs. ext4 vs. Btrfs hilft bei der Wahl des Dateisystems.
• Welche Hardware braucht ZFS? trennt Pflicht und Kür bei CPU, RAM und Platten.
• Mit dem ZFS-Kapazitätsrechner siehst du, wie viel Platz ein Layout nutzbar macht.
• Alle Guides der Serie sammelt der Themenbereich ZFS.