ZFS für Einsteiger — das verlässliche Dateisystem fürs Homelab

Hinweis: Dieser Beitrag enthält Affiliate-Links (mit * gekennzeichnet). Kaufst du über einen dieser Links, erhalten wir eine kleine Provision — für dich ändert sich der Preis nicht. Hardware wird vor jeder Empfehlung mindestens vier Wochen im eigenen Homelab getestet.

Wer im Homelab ein Speichersystem aufbaut, das in fünf Jahren noch verlässlich läuft, landet früher oder später bei ZFS. Das Dateisystem stammt von Sun, lebt seit zwanzig Jahren und ist 2026 in Linux fest etabliert. Es bietet Snapshots, Datenintegritäts-Checksummen, einfache Replikation und ein durchdachtes RAID-Konzept — alles in einem Stück. Dieser Guide zeigt dir die Grundlagen, ohne dich gleich in die Tiefen der Tunings-Optionen zu schicken.

Was macht ZFS anders als ext4 oder btrfs?

Klassische Linux-Dateisysteme wie ext4 sind Single-Disk-orientiert und kennen kein Konzept von „RAID gehört dazu“. Wer mehrere Disks zusammenfassen will, braucht zusätzlich mdadm (Software-RAID) und LVM (Volume-Management). Drei Schichten mit drei Werkzeugen, die unabhängig voneinander gepflegt werden müssen.

ZFS hat das anders gelöst: Es ist alles drei in einem Stück. Du sagst ZFS „das sind meine Disks“, und es kümmert sich um RAID, Volume-Management und das Dateisystem. Diese Integration bringt mehrere konkrete Vorteile:

• Daten-Integrität: Jeder Block hat eine Checksumme. ZFS erkennt Bit-Rot (also stille Datenkorruption auf der Disk) und kann ihn aus den Redundanz-Daten reparieren.
• Copy-on-Write: Schreibvorgänge schreiben nie in vorhandene Blöcke, sondern legen neue an. Das macht Snapshots quasi kostenlos und schützt vor halben Schreibvorgängen bei Stromausfall.
• Snapshots in Sekunden: Eine Momentaufnahme deines kompletten Datasets ist instant, weil nur ein Verweis gespeichert wird. Verändert sich später etwas, werden nur die Differenzen zusätzlich abgelegt.
• Replikation per Send/Receive: Du schickst nur die Snapshot-Differenz auf einen anderen Pool — auch über das Internet zu einem zweiten Server.
• Komprimierung im Kernel: LZ4 ist Standard, kostet kaum CPU und spart oft 30-50 % Speicherplatz.

Der direkte Konkurrent ist btrfs, das ähnliche Features hat. ZFS ist aber im Alltag stabiler, ausgereifter und in Storage-Setups deutlich verbreiteter — vor allem im Homelab und bei TrueNAS. Mehr zu TrueNAS in unserem TrueNAS-Scale-Tutorial.

Die drei Kernkonzepte: Pool, Vdev, Dataset

Wer ZFS verstehen will, muss drei Begriffe sauber trennen:

• Pool (zpool): der oberste Container. Ein Pool fasst eine oder mehrere Vdevs zusammen und stellt einen großen, gemeinsamen Speicher bereit. Beispiel: ein Pool namens tank mit 8 TB Gesamt-Kapazität.
• Vdev (Virtual Device): eine Gruppe physischer Disks innerhalb des Pools. Vdevs definieren das RAID-Verhalten — ein Mirror-Vdev aus 2 Disks ist redundant, ein Single-Disk-Vdev nicht. Pro Pool mehrere Vdevs möglich; Disks gehören immer zu einer Vdev, nie zwischen mehreren.
• Dataset: die logische Aufteilung innerhalb eines Pools. Du kannst auf einem Pool mehrere Datasets anlegen (z. B. tank/photos, tank/docker), jedes mit eigenen Eigenschaften wie Komprimierung, Quota oder Snapshot-Schedule.

Faustregel für die Hierarchie: Pool → Vdev(s) → Dataset(s) → Dateien. Wer einmal verstanden hat, was wo passiert, kann seinen Storage richtig planen.

RAID-Modi — welcher passt zu wem?

Das Vdev-Layout entscheidet, wie viel Redundanz du bekommst und wie schnell der Pool ist. Vier praxisrelevante Optionen:

Modus	Disks Min	Verlust durch	Nutzbar	Performance	Use-Case
Single	1	kein Schutz	100 %	hoch	Test, schnelle Caches
Mirror (RAID1)	2	Spiegel-Disk	50 %	sehr hoch	Boot-SSDs, kleine Pools
RAIDZ1	3	1 Parity-Disk	(n-1)/n	moderat	3-5 Disks Datenarchiv
RAIDZ2	4	2 Parity-Disks	(n-2)/n	moderat	6-12 Disks ernsthaft

Praxis-Empfehlungen aus dem Homelab-Alltag:

• Boot-SSDs: immer Mirror (2 SSDs).
• 2 Disks für Daten: Mirror — einfach, schnell, robust.
• 3-5 Disks: RAIDZ1 ist solide. Bei großen Disks (10+ TB) lieber RAIDZ2.
• 6-8 Disks: RAIDZ2 oder zwei RAIDZ1-Vdevs (Striped RAIDZ) je nach Mix.
• 10+ Disks: RAIDZ3 oder mehrere RAIDZ2-Vdevs.

Ersten Pool anlegen — Schritt für Schritt

Wir gehen davon aus, du hast Linux installiert (Debian, Ubuntu, oder als Teil von Proxmox VE) und zwei Daten-Disks (z. B. /dev/sdb und /dev/sdc) bereit.

Schritt 1: ZFS installieren

sudo apt install zfsutils-linux

Auf Proxmox-Hosts ist ZFS bereits eingebaut, da musst du nichts installieren.

Schritt 2: Disks identifizieren

Wichtig: ZFS-Pools sollten mit persistenten Disk-IDs aufgebaut werden, nicht mit /dev/sdb — das kann sich beim Boot ändern. Stattdessen:

ls -l /dev/disk/by-id/

Du siehst Einträge wie ata-WDC_WD40EFRX-68N32N0_WD-WCC7K0N123456. Diese IDs bleiben gleich, auch wenn der Server umbootet.

Schritt 3: Pool als Mirror anlegen

sudo zpool create -o ashift=12 \
    tank mirror \
    /dev/disk/by-id/ata-WDC_WD40EFRX-..._WCC7K0N111111 \
    /dev/disk/by-id/ata-WDC_WD40EFRX-..._WCC7K0N222222

Wichtige Optionen:

• ashift=12 — sagt ZFS, dass die Disks 4-KB-Sektoren haben (alle modernen HDDs/SSDs). Wichtig: lässt sich nach Pool-Erstellung nicht mehr ändern!
• tank — Pool-Name. Frei wählbar.
• mirror — Vdev-Typ.

Schritt 4: Erste Datasets erstellen

sudo zfs create tank/photos
sudo zfs create tank/backups
sudo zfs create tank/docker

# Komprimierung aktivieren (LZ4 ist Standard, schadet nie):
sudo zfs set compression=lz4 tank

# Quota für ein Dataset:
sudo zfs set quota=500G tank/photos

Datasets erscheinen automatisch unter /tank/photos, /tank/backups usw. — bereit für Daten.

Snapshots — das Killer-Feature im Alltag

Snapshots sind in ZFS unfassbar günstig. Eine Momentaufnahme braucht keine extra Plattenkapazität, weil nur die Differenzen zwischen „jetzt“ und „Snapshot-Zeitpunkt“ gespeichert werden:

# Manueller Snapshot:
sudo zfs snapshot tank/photos@vor-grossem-import

# Liste aller Snapshots:
sudo zfs list -t snapshot

# Wiederherstellung (rollback):
sudo zfs rollback tank/photos@vor-grossem-import

# Snapshot löschen:
sudo zfs destroy tank/photos@vor-grossem-import

Im Produktiv-Setup automatisierst du Snapshots mit zfs-auto-snapshot oder sanoid. Beide laufen per Cron-Job und legen stündlich, täglich, wöchentlich, monatlich Snapshots an — jeweils mit konfigurierbarer Aufbewahrungszeit.

Replikation auf einen zweiten Pool

Snapshots sind nur halbe Miete — sie schützen vor versehentlichem Löschen, nicht vor Hardware-Defekten am ganzen Server. Lösung: zfs send | zfs receive, das die Snapshot-Differenzen auf einen anderen Pool oder Server schickt:

# Erste Vollkopie:
sudo zfs send tank/photos@daily-1 \
  | ssh backup-server "sudo zfs receive backup/photos"

# Folge-Replikation (nur Differenzen):
sudo zfs send -i tank/photos@daily-1 tank/photos@daily-2 \
  | ssh backup-server "sudo zfs receive backup/photos"

Werkzeuge wie syncoid automatisieren das Hin-und-Her und kümmern sich um die richtige Snapshot-Reihenfolge. Damit lässt sich eine 3-2-1-Backup-Strategie sehr elegant umsetzen — siehe unseren Spoke Die 3-2-1-Backup-Regel.

ARC, Performance und der RAM-Hunger-Mythos

Du hast vielleicht gehört, dass ZFS „ein RAM-Fresser“ ist. Das stimmt halb. Tatsächlich nutzt ZFS einen aggressiven Lese-Cache namens ARC (Adaptive Replacement Cache), der freien RAM für sich beansprucht. Dieser Cache wird aber freigegeben, sobald andere Anwendungen ihn brauchen.

Faustregel zur RAM-Planung: 1 GB RAM pro 1 TB Pool-Kapazität als Minimum. 2 GB pro TB, wenn du Deduplizierung aktivierst (was du im Homelab praktisch nie tun solltest). ECC-RAM ist empfohlen, aber kein Pflicht-Killer — viele Homelab-ZFS-Pools laufen seit Jahren stabil ohne ECC.

Pflege und Monitoring

ZFS ist erstaunlich pflegeleicht. Drei Routinen reichen:

• Scrub einmal pro Monat: liest alle Daten und prüft die Checksummen. Repariert stille Bit-Rot-Korruption automatisch. Befehl: sudo zpool scrub tank. Auf Proxmox als Cron-Job standardmäßig sonntags früh.
• Pool-Status checken: sudo zpool status. Zeigt Health, ausgefallene Disks, laufende Scrubs.
• Speicher-Auslastung: sudo zpool list für Pool-Größe, sudo zfs list für Datasets-Größen. Pools über 85 % Auslastung werden langsam — rechtzeitig erweitern oder aufräumen.

Im Alltag bekommst du E-Mail-Benachrichtigungen, wenn etwas schiefgeht — auf Proxmox aktivierst du das im Web-UI, auf normalem Linux mit zed (ZFS Event Daemon).

Häufige Fragen

Brauche ich ECC-RAM für ZFS?

Empfohlen, aber nicht zwingend. Im Server-Bereich Pflicht (z. B. bei TrueNAS für Produktiv-Setups). Im Homelab läuft ZFS auch auf normalem RAM stabil — das oft zitierte „ohne ECC zerstört ZFS deine Daten“ ist überzogen. Wer das letzte Quäntchen Sicherheit will, geht auf AMD-Plattform mit ECC-Unterstützung.

Kann ich Disks zu einem laufenden Pool hinzufügen?

Eingeschränkt. Du kannst neue Vdevs zu einem Pool hinzufügen (also den Pool erweitern), aber innerhalb eines RAIDZ-Vdevs lassen sich keine zusätzlichen Disks einfach so dazustecken. Seit ZFS 2.3 gibt es RAIDZ-Expansion, aber das ist noch jung und langsam. Pragmatisch: vor dem ersten Pool-Aufbau plant du die Disk-Anzahl ehrlich.

Was passiert, wenn eine Disk ausfällt?

Im Mirror oder RAIDZ läuft der Pool normal weiter, ZFS markiert die ausgefallene Disk als „FAULTED“. Du tauschst die Disk physisch, ersetzt sie mit zpool replace tank /dev/disk/by-id/alte-disk /dev/disk/by-id/neue-disk, und ZFS rebuilded die Redundanz im Hintergrund. Dauert je nach Pool-Größe Stunden bis Tage, aber ohne Service-Unterbrechung.

Lohnt sich Deduplizierung?

Im Homelab fast nie. Dedup kostet enorm RAM (3-5 GB pro 1 TB!), bringt aber nur dann Nutzen, wenn du sehr viele Duplikate hast (z. B. tausende identische VM-Images). Komprimierung mit LZ4 reicht in 95 % der Fälle und kostet kaum etwas.

ZFS oder btrfs?

Beide haben ähnliche Features. ZFS ist im Storage-Setup robuster, btrfs ist im Ubuntu-Standard-Repo verfügbar und hat Vorteile bei Single-Disk-Setups. Im Homelab und für ernsthafte Speicher-Setups führt an ZFS kaum ein Weg vorbei — allein schon, weil Proxmox und TrueNAS es als Standard nutzen.

Wie groß sollte ein Dataset werden?

Theoretisch unbegrenzt. Praktisch: Eine Dataset-Größe von 1-10 TB ist im Homelab üblich. Die Hauptunterscheidung machst du anhand der Verwendung — Fotos, VMs, Docker-Volumes — nicht anhand der Größe.

Wie sichere ich einen ZFS-Pool?

Mit zfs send/receive auf einen zweiten Pool oder einen anderen Server. Im Proxmox-Kontext über den Proxmox Backup Server bequem. Die 3-2-1-Backup-Regel bleibt natürlich auch für ZFS-Pools Pflicht.

Wo es weitergeht

• Homelab für Anfänger 2026 — die Pillar-Page, in der ZFS ein Storage-Baustein ist.
• TrueNAS Scale aufbauen — wenn du ZFS als komplette NAS-Lösung willst.
• Der komplette Proxmox-Guide — ZFS als Default-Storage in Proxmox.
• Proxmox Backup Server einrichten — Backup-Ziel für ZFS-Pools.
• Die 3-2-1-Backup-Regel — Strategie über ZFS hinaus.

Externe Pflichtquellen:

• openzfs.github.io — offizielle OpenZFS-Dokumentation.
• Oracle ZFS Administration Guide — älterer, aber sehr detaillierter Klassiker.
• r/zfs auf Reddit — lebendige Community.

Du planst gerade einen Pool und bist unsicher beim Layout? Schreib uns eine Mail an admin@lapalutschi.de.