ZFS

Die meisten Dateisysteme vertrauen der Festplatte. ZFS verlangt für jeden Block eine Quittung.

Kurz gesagt

ZFS ist Dateisystem und Volume-Manager in einem. Es speichert für jeden geschriebenen Block eine Prüfsumme, und hat der Pool Redundanz (Spiegel oder RAID-Z), repariert es einen beschädigten Block aus einer intakten Kopie [3][4]. Unsere Einschätzung: ZFS passt gut zu einem NAS oder Dateiserver, bei dem stille Datenfehler wehtun würden, und ersetzt kein Backup. Für einen Desktop mit einer einzigen Platte lohnt sich die Einarbeitung selten.

So funktioniert’s

1. Eine Schicht statt dreier. Platten werden zu virtuellen Geräten (vdevs), vdevs bilden einen Pool, und Datasets (Dateisysteme oder Volumes) beziehen ihren Platz aus diesem Pool [5]. Der Pool verteilt Daten über alle seine obersten vdevs. Die Redundanz steckt innerhalb eines vdevs, nicht zwischen vdevs: Fällt ein oberstes vdev aus, ist der ganze Pool weg [5].
2. Copy-on-Write. ZFS überschreibt nie einen Block, der in Benutzung ist. Es schreibt die geänderten Daten in freien Platz, dann neue Elternblöcke den Baum hinauf und zuletzt einen neuen Wurzelblock, den Uberblock. Dieser letzte Wechsel ist ein einziger atomarer Schreibvorgang. Der Pool bleibt nach einem Stromausfall konsistent und braucht kein fsck [1]. Snapshots sind aus demselben Grund billig: Der alte Baum ist ja noch vollständig da [1].
3. Prüfsummen im Elternblock. Jeder Blockzeiger enthält die Prüfsumme des Blocks, auf den er zeigt. Ein beschädigter Block kann sich also nicht selbst für unbeschädigt erklären [1]. Die Eigenschaft checksum steht standardmäßig auf on, in der Dokumentation vom 25. Okt. 2026 also fletcher4 (sie sagt, das kann sich ändern). Prüfsummen abzuschalten ist laut Dokumentation „NOT a recommended practice“ [2]. Ein Prüfsummenfehler beim Lesen löst eine Reparatur aus, sofern eine gute Kopie existiert [3][4].
4. Scrub. zpool scrub liest alle Daten eines Pools, prüft jede Prüfsumme und repariert Schäden aus der Redundanz. Ein Resilver betrachtet nur Daten, die nachweislich veraltet sind, etwa nach einem Plattentausch [6].
5. Was ZFS nicht kann. Keine Technik in ZFS schützt vor gekippten Bits im Arbeitsspeicher, deshalb empfiehlt der OpenZFS-Hardwareleitfaden ECC-Speicher [7]. Derselbe Leitfaden sagt, Hardware-RAID-Controller gehörten nicht vor ZFS; gib ihm die rohen Platten [7]. Ein Pool ohne Redundanz erkennt Schäden, kann sie aber nicht reparieren, und die Dokumentation nennt diese Anordnung „strongly discouraged“ [4]. Snapshots liegen im Pool und teilen sein Schicksal. Unsere Einschätzung: Führe ein getrenntes Backup.

Ein Homelab-Beispiel

In unserem Inventar (Stand 14. bis 16. Okt. 2026) ist ZFS auf keinem Bytearium-System erfasst. Was folgt, ist deshalb ein allgemeiner Ablauf und kein Bericht aus unseren Racks. Nimm zwei Ersatzplatten, die gelöscht werden dürfen, und lege einen gespiegelten Pool an, mit stabilen Gerätenamen [8]:

sudo zpool create tank mirror /dev/disk/by-id/DISK_A /dev/disk/by-id/DISK_B
sudo zfs create tank/media
sudo zpool scrub tank
zpool status tank

Das Schlüsselwort mirror bei zpool create ist die dokumentierte Syntax [4]. zpool status zeigt den Scrub-Fortschritt und was repariert wurde [6]. Bevor du einen Pool je erweiterst, sieh dir das Ergebnis mit zpool add -n vorab an: Enthält der Pool ein RAID-Z-vdev, lässt sich später kein oberstes vdev mehr entfernen [8].

Prüfliste

• Prüfe, ob du Prüfsummen und Snapshots überhaupt brauchst; eine einzelne Platte mit gutem Backup kann genügen.
• Gib ZFS ganze Platten und lass Hardware-RAID dazwischen weg [4][7].
• Entscheide die Redundanz, bevor du den Pool anlegst: Spiegel oder RAID-Z.
• Sieh jedes zpool add zuerst mit -n vorab an [8].
• Richte einen regelmäßigen Scrub ein und lies danach zpool status.
• Plane ECC-Speicher für Daten ein, die du nicht neu erzeugen kannst [7].
• Lege eine zweite Kopie außerhalb des Pools an (3-2-1).