ZFS on Linux: Grundlagen für Server mit hohen Datenintegritätsanforderungen

1. Warum ZFS für hohe Datenintegritätsanforderungen relevant ist

Klassische Kombinationen aus RAID Controller, LVM und ext4 oder XFS vertrauen darauf, dass die darunterliegende Hardware fehlerfrei arbeitet. Stille Datenkorruption, sogenannte Bit Rot, wird dabei meist erst bemerkt, wenn eine Anwendung bereits mit fehlerhaften Daten arbeitet, weil keine der beteiligten Schichten den tatsächlichen Dateiinhalt gegen eine Prüfsumme validiert.

ZFS wurde von Grund auf mit dem Ziel entwickelt, genau dieses Problem zu lösen. Jeder Block bekommt beim Schreiben eine Prüfsumme, die beim Lesen erneut berechnet und verglichen wird. Weicht sie ab und liegt Redundanz in Form von Spiegelung oder RAIDZ vor, repariert ZFS den defekten Block automatisch aus einer intakten Kopie, ein Vorgang, der als Self Healing bezeichnet wird und ohne manuellen Eingriff im Hintergrund abläuft.

2. Architektur: Pools, vdevs und Datasets

Ein ZFS Pool fasst mehrere physische Datenträger zu einer gemeinsamen Speicherressource zusammen und ersetzt damit sowohl den klassischen RAID Controller als auch den Volume Manager. Innerhalb eines Pools bilden ein oder mehrere vdevs, virtuelle Geräte, die eigentliche Redundanzebene, etwa als Spiegel aus zwei Platten oder als RAIDZ Gruppe mit verteilter Parität.

Auf einem Pool lassen sich beliebig viele Datasets anlegen, jeweils mit eigenen Eigenschaften wie Kompression, Quota oder Zugriffsrechten, ohne dass dafür eine feste Größe reserviert werden muss. Ein Dataset verhält sich für Anwendungen wie ein gewöhnliches Verzeichnis, teilt sich aber den gesamten freien Speicherplatz des Pools mit allen anderen Datasets, ganz ähnlich wie Subvolumes bei Btrfs.

3. Installation über OpenZFS

Wegen Lizenzinkompatibilitäten zwischen der CDDL von ZFS und der GPL des Linux Kernels ist ZFS nicht Teil des Mainline Kernels und muss über das OpenZFS Projekt als separates Kernel Modul installiert werden. Auf Debian und Ubuntu basierten Distributionen erfolgt die Installation meist über DKMS, das Modul wird dabei bei jedem Kernel Update automatisch neu gegen den aktuellen Kernel kompiliert.

Nach der Installation und einem Neustart oder dem manuellen Laden des Kernelmoduls stehen die Kommandozeilenwerkzeuge zpool und zfs zur Verfügung, mit denen sich der gesamte weitere Lebenszyklus von Pools und Datasets verwalten lässt, ohne dass für einzelne Operationen ein Neustart des Systems notwendig wäre.

# OpenZFS auf Debian/Ubuntu über DKMS installieren
apt update
apt install -y zfsutils-linux zfs-dkms

# Kernel Modul manuell laden und Version pruefen
modprobe zfs
zfs version

4. Praxisbeispiel: Einen Pool anlegen

Ein Pool wird mit zpool create angelegt und benötigt mindestens einen vdev Typ als Argument. Für produktive Server mit Redundanzanforderung ist RAIDZ1 die gängige Wahl bei drei bis fünf Platten, während eine Spiegelung aus zwei Platten für kleinere Setups mit besserer Random I/O Performance sinnvoller ist, weil RAIDZ bei kleinen, zufälligen Schreibzugriffen prinzipbedingt schlechter skaliert als eine reine Spiegelung.

Wichtig ist die konsequente Verwendung stabiler Geräte Identifikatoren aus /dev/disk/by-id statt der klassischen /dev/sdX Bezeichner, weil sich Letztere zwischen Neustarts ändern können und ein Pool, der auf falsche Geräte referenziert, im schlimmsten Fall nicht mehr importiert werden kann.

# Pool mit RAIDZ1 aus drei Platten anlegen, stabile IDs verwenden
zpool create datapool raidz1 \
  /dev/disk/by-id/ata-DISK1 \
  /dev/disk/by-id/ata-DISK2 \
  /dev/disk/by-id/ata-DISK3

# Status und Redundanzlage des Pools pruefen
zpool status datapool

5. Praxisbeispiel: Dataset für Datenbank Storage

Für Datenbank Workloads lohnt sich ein eigenes Dataset mit angepassten Eigenschaften statt der ZFS Standardwerte. Die Recordsize sollte an die typische Seitengröße der Datenbank angepasst werden, für MySQL mit InnoDB üblicherweise auf 16 Kilobyte, damit ZFS nicht unnötig größere Blöcke lesen und schreiben muss, als die Datenbank tatsächlich anfordert.

Kompression sollte grundsätzlich aktiviert bleiben, weil der moderne lz4 Algorithmus so schnell komprimiert und dekomprimiert, dass er in den allermeisten Fällen sogar Performance gewinnt, statt zu kosten, da weniger tatsächliche Daten von der Platte gelesen werden müssen. Der sync Parameter steuert dagegen das Verhalten bei synchronen Schreibzugriffen und sollte bei Datenbanken nicht ohne triftigen Grund auf disabled gesetzt werden, weil sonst im Falle eines Absturzes Transaktionen verloren gehen können.

# Dataset für MySQL Datenverzeichnis mit angepassten Eigenschaften
zfs create -o recordsize=16K -o compression=lz4 -o atime=off \
  datapool/mysql

# Aktuelle Eigenschaften eines Datasets pruefen
zfs get recordsize,compression,atime datapool/mysql

6. Checksummen, Self Healing und Scrub im Detail

Jeder Block erhält standardmäßig eine fletcher4 Checksumme, die im Merkle Baum artigen Metadatenbaum von ZFS gespeichert wird, sodass nicht nur Nutzdaten, sondern auch die Metadatenstruktur selbst gegen Korruption abgesichert ist. Weicht eine Checksumme beim Lesen ab und existiert eine redundante Kopie über Spiegelung oder RAIDZ Parität, liefert ZFS transparent die korrekte Version aus und schreibt den defekten Block automatisch neu.

Ein regelmäßiger Scrub liest proaktiv jeden Block im Pool und vergleicht ihn gegen seine Checksumme, statt auf einen zufälligen Lesezugriff zu warten, der einen Fehler erst zufällig aufdeckt. Für produktive Server empfiehlt sich ein wöchentlicher Scrub, idealerweise über einen Cron Job oder das mitgelieferte systemd Timer Unit, weil Fehler dadurch früh erkannt werden, solange noch genug Redundanz für eine Reparatur vorhanden ist.

# Scrub manuell anstossen und Fortschritt beobachten
zpool scrub datapool
zpool status datapool

# Wiederkehrenden Scrub per systemd Timer aktivieren, sofern vorhanden
systemctl enable --now zfs-scrub-weekly@datapool.timer

7. Vergleich zu Btrfs und LVM mit ext4

Btrfs bietet mit Checksummen und Copy on Write ähnliche Grundprinzipien wie ZFS, gilt für parity basierte RAID Level wie RAID5 und RAID6 aber weiterhin als weniger ausgereift und wird von vielen Administratoren dafür gemieden, während ZFS RAIDZ seit vielen Jahren produktionsstabil im Einsatz ist. Umgekehrt ist Btrfs bereits Teil des Mainline Kernels und benötigt kein separates Kernel Modul, was die Installation vereinfacht.

LVM kombiniert mit ext4 oder XFS bleibt die pragmatische Wahl, wenn Checksummen und Self Healing keine harte Anforderung sind, weil beide Dateisysteme jahrzehntelang erprobt, gut dokumentiert und mit praktisch jedem Werkzeug kompatibel sind. Wo Datenintegrität jedoch eine zentrale Anforderung ist, etwa bei Finanzdaten oder kritischen Produktionsdatenbanken, bietet ZFS derzeit die ausgereifteste Kombination aus Checksummen, Self Healing und flexiblem Volume Management in einer einzigen Schicht.

8. ARC Cache und RAM Bedarf im Serverbetrieb

ZFS verwendet standardmäßig den Adaptive Replacement Cache, kurz ARC, der einen erheblichen Teil des verfügbaren Arbeitsspeichers für häufig gelesene Blöcke reserviert, was ZFS im Vergleich zu ext4 oder XFS deutlich RAM hungriger erscheinen lässt. Auf Datenbankservern, die selbst einen eigenen Buffer Pool wie den InnoDB Buffer Pool verwalten, konkurriert der ARC direkt mit diesem um denselben Arbeitsspeicher, weshalb eine explizite Obergrenze über den Parameter zfs_arc_max gesetzt werden sollte.

Als Faustregel sollte der ARC so dimensioniert werden, dass genügend Arbeitsspeicher für Anwendung, Betriebssystem und Datenbank Buffer Pool übrig bleibt, üblicherweise ein Viertel bis maximal die Hälfte des insgesamt verfügbaren Arbeitsspeichers, abhängig davon, wie speicherhungrig die eigentliche Anwendung ist.

# ARC Obergrenze dauerhaft auf 8 GiB begrenzen
echo "options zfs zfs_arc_max=8589934592" > /etc/modprobe.d/zfs.conf
update-initramfs -u

# Aktuelle ARC Groesse zur Laufzeit pruefen
arc_summary | grep -A2 "ARC size"

9. Best Practices und Fallstricke im Praxisbetrieb

Snapshots sind bei ZFS ebenso günstig wie bei Btrfs und sollten vor jedem riskanten Eingriff erstellt werden, kosten aber ebenfalls erst mit der Zeit Speicherplatz, sobald sich Original und Snapshot auseinanderentwickeln. Ein Pool sollte niemals bis an die Kapazitätsgrenze gefüllt werden, weil die Copy on Write Architektur von ZFS ab etwa neunzig Prozent Füllstand spürbar an Performance verliert, da immer weniger zusammenhängender freier Speicherplatz für neue Blöcke verfügbar ist.

Wer vor 2021 mit ZFS begonnen hat, kennt die Einschränkung, dass sich ein bestehendes RAIDZ vdev nicht nachträglich um weitere Platten erweitern ließ. Seit OpenZFS 2.13 ist genau das mit dem RAIDZ Expansion Feature möglich, wenn auch mit einigen Einschränkungen bei der tatsächlichen Speicherplatzverteilung nach der Erweiterung, die vor dem produktiven Einsatz genau geprüft werden sollten.

10. Zusammenfassung

11. FAQ: ZFS on Linux