- ZFS prüft bei jedem Lesevorgang automatisch eine Prüfsumme und repariert stille Fehler (sogenanntes Bitrot) selbstständig – vorausgesetzt, es gibt eine Redundanz wie einen Mirror oder RAIDZ.
- Snapshots sind augenblickliche Zeitpunktkopien, die im Moment der Erstellung keinen zusätzlichen Speicherplatz kosten – aber kein Ersatz für ein echtes Backup.
- Ein Scrub durchsucht regelmäßig den kompletten Pool nach stillen Fehlern, damit sie nicht erst beim nächsten Festplattenausfall zum echten Datenverlust werden.
- ECC-Arbeitsspeicher ist sinnvoll, aber entgegen einem hartnäckigen Mythos keine Voraussetzung, um ZFS sicher zu betreiben.
Was ist ZFS eigentlich?
ZFS ist ein Dateisystem mit eingebauter Datenträgerverwaltung (Volume-Manager) – es kümmert sich also nicht nur darum, wie Dateien gespeichert werden, sondern verwaltet gleich mehrere Festplatten zu einem gemeinsamen Speicherpool. Entwickelt wurde es ursprünglich 2005 bei Sun Microsystems, heute wird es als Gemeinschaftsprojekt namens OpenZFS für Linux, FreeBSD und Illumos weiterentwickelt. Das technische Grundprinzip heißt Copy-on-Write: Statt vorhandene Daten direkt zu überschreiben, schreibt ZFS Änderungen immer an eine neue Stelle und aktualisiert erst danach die Verweise darauf. Das klingt zunächst wie ein Detail, ist aber die Basis für fast alles, was ZFS im Homelab interessant macht.
Prüfsummen gegen Bitrot – das Herzstück von ZFS
Jeder Datenblock, den ZFS schreibt, bekommt eine Prüfsumme spendiert – eine Art digitaler Fingerabdruck. Beim Lesen wird diese Prüfsumme jedes Mal neu berechnet und mit der gespeicherten verglichen. Stimmen sie nicht überein, hat sich der Block seit dem Schreiben unbemerkt verändert – man spricht von Bitrot oder stillen Datenfehlern, die durch Alterung der Hardware oder andere seltene Störungen entstehen können. Ein normales Dateisystem würde die beschädigten Daten einfach ausliefern, ohne dass irgendjemand etwas merkt. ZFS dagegen erkennt den Fehler sofort – und wenn eine Redundanz vorhanden ist, also die Daten gespiegelt oder mit Parität abgesichert sind (dazu gleich mehr), repariert ZFS den fehlerhaften Block automatisch aus der intakten Kopie.
Snapshots: Zeitmaschine ohne Zusatzkosten
Dank Copy-on-Write kann ZFS jederzeit einen Snapshot anlegen – eine Momentaufnahme des gesamten Dateisystems zu genau diesem Zeitpunkt. Weil dabei keine Daten kopiert werden, sondern nur der aktuelle Stand „eingefroren“ wird, ist ein Snapshot in Sekundenbruchteilen fertig und belegt im Moment der Erstellung praktisch keinen zusätzlichen Platz. Erst wenn sich Daten danach ändern, wachsen die alten Blöcke im Hintergrund weiter mit, weil sie ja noch vom Snapshot referenziert werden. Das macht Snapshots ideal, um versehentlich gelöschte Dateien zurückzuholen oder einen Zustand vor einem fehlgeschlagenen Update wiederherzustellen.
Wichtig ist aber: Ein Snapshot ist kein Backup. Er liegt im selben Pool wie die Originaldaten – fällt die Hardware komplett aus, wird das Gerät gestohlen oder brennt der Server ab, sind alle Snapshots genauso weg wie die Originaldaten. Ein echtes Backup braucht eine physisch getrennte Kopie, zum Beispiel auf einem zweiten Gerät. Genau dafür gibt es zfs send und zfs receive: Damit lassen sich Snapshots inkrementell und blockbasiert auf einen anderen Pool oder Host übertragen. Wer das nicht von Hand per Cronjob bauen will, greift am besten zu Sanoid und Syncoid – zwei Werkzeuge, die Snapshot-Zeitpläne nach Regeln verwalten (Sanoid) und die Replikation auf andere Rechner übernehmen (Syncoid), inklusive Fortsetzen abgebrochener Übertragungen.
Scrubs: Der Gesundheitscheck für den ganzen Pool
Ein Scrub liest im Hintergrund systematisch den gesamten Pool durch und vergleicht jeden Block mit seiner Prüfsumme. Gefundene stille Fehler werden – wieder vorausgesetzt, es gibt Redundanz – direkt repariert. Der Sinn dahinter: Ein einzelner defekter Block ist meist kein Problem, solange die Redundanz ihn ausgleichen kann. Gefährlich wird es erst, wenn ein zweiter, unabhängiger Fehler dazukommt – etwa der komplette Ausfall einer Festplatte – während der erste Fehler unentdeckt geblieben ist. Regelmäßige Scrubs sorgen dafür, dass solche schleichenden Fehler auffliegen, solange noch genug Redundanz da ist, um sie zu beheben.
RAIDZ: Redundanz ohne Write Hole
Für die Redundanz selbst bietet ZFS die RAIDZ-Level, die klassischem RAID5 und RAID6 ähneln, aber ein bekanntes Problem von Hardware-RAID-Controllern vermeiden: das sogenannte „Write Hole“, bei dem ein Stromausfall mitten im Schreibvorgang die Parität inkonsistent zurücklässt. Weil ZFS dank Copy-on-Write nie bestehende Daten überschreibt, kann dieser Fall gar nicht erst auftreten.
| Level | Ausfallende Festplatten, die verkraftet werden | Vergleichbar mit |
|---|---|---|
| RAIDZ1 | 1 Festplatte | RAID5 |
| RAIDZ2 | 2 Festplatten | RAID6 |
| RAIDZ3 | 3 Festplatten | kein klassisches Pendant |
Neu seit OpenZFS 2.3: Nachträglich erweitern
Bis vor Kurzem galt: Ein RAIDZ-Vdev (die Gruppe von Platten, die zusammen die Parität bilden) ist nach dem Anlegen in seiner Plattenzahl festgelegt. Mit OpenZFS 2.3 (Januar 2025) kam die lange gewünschte RAIDZ-Erweiterung: Einzelne Platten lassen sich einem bestehenden RAIDZ-Vdev live hinzufügen, ohne den Pool neu aufbauen zu müssen. Ein Fallstrick dabei, der in älteren Anleitungen noch fehlt: Bereits vorhandene Daten behalten ihr altes Verhältnis von Nutzdaten zu Parität bei. Nur neu geschriebene Daten profitieren vom besseren Verhältnis der erweiterten Platte – der Effizienzgewinn stellt sich also erst nach und nach ein, wenn Daten mit der Zeit neu geschrieben oder gezielt per zfs send/zfs receive umkopiert werden. OpenZFS 2.4 folgte im Dezember 2025 mit weiteren Verbesserungen, außerdem brachte die 2.3er-Reihe eine deutlich sparsamere Deduplizierung (Fast Dedup) sowie Direct I/O für schnellen NVMe-Speicher.
WD Red Plus 4TB NAS 3.5″ Internal Hard Drive
Eine solide Wahl, um einen ZFS-Pool mit Mirror oder RAIDZ aufzubauen, wie er in diesem Artikel beschrieben wird.
ECC-RAM: Sinnvoll, aber kein Muss
Kaum ein Mythos hält sich so hartnäckig wie dieser: „ZFS ohne ECC-RAM (Error-Correcting Code, also Arbeitsspeicher mit eingebauter Fehlerkorrektur) ist gefährlich.“ Matt Ahrens, einer der Mitentwickler von ZFS, hat dem wiederholt widersprochen: ZFS ist nicht anfälliger für RAM-Fehler als andere Dateisysteme und hält auch nicht mehr Daten im Speicher vor als vergleichbare Systeme. ECC ist empfehlenswert, wenn das Mainboard es unterstützt und die Daten wirklich wichtig sind – aber keine Voraussetzung für den sicheren Betrieb. Millionen Consumer-NAS-Geräte laufen seit Jahren ohne ECC problemlos. Wer seine Prioritäten für die Datensicherheit setzen will, tut das besser in dieser Reihenfolge: zuerst ein echtes Backup, dann ein prüfsummenbasiertes Dateisystem wie ZFS, dann eine USV (unterbrechungsfreie Stromversorgung), und erst danach ECC-RAM.
Wo läuft ZFS im Homelab?
ZFS ist längst nicht mehr nur FreeBSD und Enterprise-Storage vorbehalten. Proxmox VE unterstützt ZFS nativ als Root- und Storage-Dateisystem, aktuell in Version 9.x mit OpenZFS 2.3 beziehungsweise 2.4. Bei den fertigen NAS-Betriebssystemen ist für Einsteiger 2026 klar TrueNAS SCALE die richtige Wahl – die FreeBSD-basierte Variante TrueNAS CORE erreichte im April 2025 ihren letzten Release und wird nicht mehr aktiv weiterentwickelt. Auch Unraid bietet inzwischen ZFS-Pools an, ZFS ist also längst in ganz unterschiedlichen Homelab-Umgebungen angekommen. Eine Ausnahme bleibt Ubuntu: Die ZFS-Root-Installation ist dort weiterhin nur als „experimentell“ gekennzeichnet – nicht wegen technischer Instabilität, sondern wegen der ungeklärten Lizenzfrage zwischen der CDDL-Lizenz von ZFS und der GPL des Linux-Kernels. Ein Vorschlag von Februar 2025, OpenZFS zusätzlich unter GPLv2 zu lizenzieren, verlief im Sand. Rechtlich ist die Frage, ob ZFS als separates Kernelmodul die Lizenzbindung umgeht, bis heute nicht gerichtlich geklärt.
Ein Wort zu den Festplattenpreisen
Wer aktuell über den Aufbau eines ZFS-Pools nachdenkt, merkt es im Portemonnaie: Festplattenpreise sind 2025 und 2026 durch die Nachfrage von KI-Rechenzentren spürbar gestiegen, einzelne Hersteller haben ihre Fertigungskapazität für 2026 bereits weitgehend verkauft. Wer eine größere Anschaffung plant, sollte das einkalkulieren – konkrete Prozentzahlen schwanken je nach Anbieter und Zeitpunkt zu stark, um sie hier seriös zu nennen.
Fazit
ZFS nimmt einem im Homelab viel Arbeit ab, die man sonst manuell absichern müsste: Prüfsummen erkennen stille Fehler, Scrubs finden sie proaktiv, und Snapshots machen Fehlbedienungen rückgängig – solange man nicht vergisst, dass daneben ein echtes, getrenntes Backup nötig bleibt. Mit RAIDZ-Erweiterung, schlankerer Deduplizierung und Direct I/O ist OpenZFS gerade in den letzten Monaten spürbar weiterentwickelt worden, während der ECC-Mythos und die Lizenzfrage rund um Linux zwei der wenigen Punkte bleiben, die es beim Einstieg richtig einzuordnen gilt.