ZFS erklärt: Dateisystem für Profis
ZFS gilt als das fortschrittlichste Dateisystem der Welt. Es bietet Datenintegrität, Snapshots, Compression und RAID-Funktionalität — alles in einem. Wir erklären, wie ZFS funktioniert und warum es der Standard für NAS und Server geworden ist.
Was ist ZFS?
ZFS (Zettabyte File System) wurde von Sun Microsystems entwickelt und ist heute als OpenZFS Open Source. Es ist mehr als ein Dateisystem — es ist ein Storage-Management-System, das Dateisystem, Volume-Manager und RAID-Controller in einem vereint.
Was ZFS besonders macht
| Eigenschaft | Traditionell (ext4/NTFS) | ZFS |
|-------------|------------------------|-----|
| RAID | Externe Hardware/Software | Integriert (RAIDZ) |
| Volume-Manager | Seperat (LVM) | Integriert |
| Datenintegrität | Checksums (begrenzt) | Jedes Block hat Checksum |
| Snapshots | Externe Tools | Nativ, sofort |
| Compression | Optional | Transparent (LZ4/ZSTD) |
| Deduplication | Extern | Nativ (optional) |
| Caching | OS-Cache | ARC + L2ARC + SLOG |
| Self-Healing | ❌ | ✅ (automatische Reparatur) |
| Copy-on-Write | ❌ | ✅ |
Die ZFS-Architektur
Das ZFS-Stack-Modell
``
┌─────────────────────────────────┐
│ Datasets (Filesystems) │
├─────────────────────────────────┤
│ ZFS Pool (zpool) │
├─────────────────────────────────┤
│ Virtual Devices (VDEVs) │
├─────────────────────────────────┤
│ Physical Disks │
└─────────────────────────────────┘
VDEVs: Die Bausteine
Ein VDEV (Virtual Device) ist eine Gruppe von Disks. Verschiedene Typen:
| VDEV-Typ | Beschreibung | Min. Disks | Fehlertoleranz |
|----------|-------------|-----------|----------------|
| Stripe | Kein Redundanz (schnell) | 1 | 0 |
| Mirror | Spiegelung (RAID 1) | 2 | n-1 |
| RAIDZ1 | Single Parity (RAID 5) | 3 | 1 |
| RAIDZ2 | Double Parity (RAID 6) | 4 | 2 |
| RAIDZ3 | Triple Parity | 5 | 3 |
Empfehlung:
Effizienz: Wie viel nutzbarer Speicher?
Beispiel: 4× 12 TB HDDs
| VDEV-Typ | Roh-Kapazität | Nutzbar | Redundanz |
|----------|--------------|---------|-----------|
| Stripe | 48 TB | 48 TB | Keine |
| RAIDZ1 | 48 TB | ~36 TB | 1 Disk |
| RAIDZ2 | 48 TB | ~24 TB | 2 Disks |
| 2× Mirror | 48 TB | ~24 TB | 1 pro Mirror |
Datenintegrität: Wie ZFS Ihre Daten schützt
Checksums für jeden Block
Jeder Block in ZFS hat eine 256-bit Checksum (Fletcher-4, SHA-256). Bei jedem Lesen wird die Checksum verifiziert. Bei Abweichung: Fehler-Detection.
Self-Healing
Wenn ZFS einen fehlerhaften Block erkennt und Redundanz vorhanden ist (Mirror/RAIDZ):
Das passiert im Hintergrund — ohne manuelles Eingreifen.
Silent Data Corruption
Normale Dateisysteme (ext4, NTFS) bemerken nicht, wenn Daten durch Bit-Rot stumm beschädigt werden. ZFS erkennt und repariert solche Korruptionen automatisch.
Snapshots: Zeitreise für Ihre Daten
Ein ZFS-Snapshot ist instantan und platzsparend (Copy-on-Write).
`bashSnapshot erstellen
zfs snapshot tank/data@backup_2026-08-07
Snapshots auflisten
zfs list -t snapshot
Verzeichnis aus Snapshot wiederherstellen
cp /tank/data/.zfs/snapshot/backup_2026-08-07/wichtig.doc /tank/data/
`
Snapshot-Automatisierung
Mit Sanoid oder zfs-auto-snapshot:
bash
Sanoid config (/etc/sanoid/sanoid.conf)
[tank/data]
use_template = production
frequently = 0
hourly = 24
daily = 7
weekly = 4
monthly = 3
`Dies behält: 24 stündliche, 7 tägliche, 4 wöchentliche, 3 monatliche Snapshots — automatisch.
Compression: Kostenloser Geschwindigkeits-Boost
ZFS bietet transparente Compression. Daten werden beim Schreiben komprimiert, beim Lesen dekomprimiert — völlig automatisch.
| Algorithmus | Speed | Ratio | Empfohlen für |
|-------------|-------|-------|---------------|
| LZ4 | Sehr schnell | 1,5-2x | Standard (beste Wahl) |
| ZSTD | Schnell | 2-3x | Höhere Compression |
| GZIP | Langsam | 2,5-3,5x | Archiv-Daten |
| ZLE | Sehr schnell | ~1x | Bereits komprimierte Daten |
LZ4 ist die Standardwahl. Es ist so schnell, dass die CPU die Daten schneller komprimieren/dekomprimieren kann, als die Disk sie lesen/schreiben kann. Resultat: höhere effektive Performance trotz Compression.
bash
Compression aktivieren
zfs set compression=lz4 tank/data
`Caching: ARC, L2ARC und SLOG
ARC (Adaptive Replacement Cache)
ZFS nutzt RAM als Read-Cache. Standard: 50 % des RAMs (bei TrueNAS).
| RAM | ARC Size | Empfohlen für |
|-----|----------|---------------|
| 8 GB | ~4 GB | Kleines NAS |
| 16 GB | ~8 GB | Mittelklasse |
| 32 GB | ~16 GB | Große NAS |
| 64+ GB | ~32+ GB | Profi |
L2ARC (Read Cache auf SSD)
Zusätzlicher Read-Cache auf NVMe/SSD. Nützlich bei:
Wiederholtes Lesen derselben Dateien
Datenbank-Workloads
VM-Images Nicht empfohlen für: Streaming, Backups (sequenzielle Reads profitieren kaum).
SLOG/ZIL (Write Cache)
Der SLOG (Safe Log on Gigabit/ZFS Intent Log) ist ein Write-Cache auf SSD. Er beschleunigt synchrone Writes (Datenbanken, NFS-Sync).
Wichtig: SLOG schützt bei Power-Loss. Nach einen Stromausfall werden die Daten aus dem SLOG committet.
| Komponente | Device-Typ | Größe | Zweck |
|------------|-----------|-------|-------|
| ARC | RAM | 50% of RAM | Read Cache (heiß) |
| L2ARC | NVMe SSD | 32-256 GB | Read Cache (warm) |
| SLOG | NVMe SSD (PLP) | 16-64 GB | Write Cache (Sync) |
Power-Loss-Protection (PLP): SLOG sollte eine NVMe SSD mit Power-Loss-Protection sein (z. B. Intel Optane, Western Digital Red SN700).
Scrub: Regelmäßige Gesundheitsprüfung
Ein Scrub liest alle Daten und verifiziert die Checksums. Bei gefundenen Fehlern: automatische Reparatur.
bash
Scrub starten
zpool scrub tankScrub-Status
zpool status tank
`Empfohlen: Scrub monatlich (Heimanwender) oder wöchentlich (Unternehmen).
ZFS Send/Receive: Effiziente Backups
ZFS kann Snapshots inkrementell über das Netzwerk senden:
bash
Inkrementelles Backup zu Remote-Server
zfs send -i tank/data@snap1 tank/data@snap2 | ssh user@backup zfs receive tank/backup/data
`Das ist extrem effizient — nur die veränderten Blöcke werden übertragen.
Praxis: ZFS auf Linux
Pool erstellen
bash
Mirror aus 2 SSDs
zpool create -o ashift=12 -o compression=lz4 tank mirror sda sdbRAIDZ2 aus 4 HDDs
zpool create -o ashift=12 -o compression=lz4 tank raidz2 sda sdb sdc sdd
`Datasets erstellen
bash
zfs create tank/vms
zfs create tank/data
zfs create tank/backupEigenschaften setzen
zfs set quota=2T tank/vms
zfs set compression=zstd tank/backup
zfs set atime=off tank/data
``Wichtige Eigenschaften
| Eigenschaft | Beschreibung | Empfohlener Wert |
|-------------|-------------|-----------------|
| compression | Compression-Algorithmus | lz4 (Standard) |
| atime | Access-Time logging | off (spart IOPS) |
| recordsize | Block-Größe | 1M (Default), 16K für DBs |
| quota | Max. Größe | nach Bedarf |
| dedup | Deduplizierung | off (Vorsicht: RAM-Hungry) |
| sync | Sync-Write-Verhalten | standard |
FAQ
Brauche ich ECC RAM für ZFS?
ECC RAM wird empfohlen (erkennt und korrigiert Bit-Flips im RAM), ist aber keine zwingende Voraussetzung. ZFS funktioniert auch ohne ECC. Die Datenintegrität auf den Disks ist auch ohne ECC gewährleistet.
Was ist ashift=12?
ashift legt die minimale Block-Größe fest. ashift=12 bedeutet 2^12 = 4096 Byte (4K), was zu modernen Advanced Format Disks passt. Immer setzen, auch bei SSDs.
Kann ich ZFS-Disks später vergrößern?
Ja. Bei Mirror- oder RAIDZ-VDEVs können Sie Disks nacheinander durch größere ersetzen. Nach dem Replace aller Disks in einem VDEV wächst der Pool automatisch.
Was passiert, wenn eine Disk ausfällt?
Bei Mirror/RAIDZ: Der Pool läuft im degraded-Modus weiter. Disk ersetzen → ZFS resilvert automatisch. Bei zu vielen ausgefallenen Disks: Datenverlust.
Lohnt sich Deduplizierung?
Meistens nein. Dedup braucht extrem viel RAM (5-10 GB pro TB gespeicherter Daten). Für die meisten Anwender ist Compression (LZ4) die bessere Wahl. Dedup nur bei vielen identischen Dateien (VM-Images, Backups).
Fazit
ZFS ist das mächtigste Dateisystem 2026 — und dank OpenZFS für jeden verfügbar. Die Kombination aus Datenintegrität (Checksums + Self-Healing), Snapshots, Compression und Caching macht es unschlagbar für NAS, Server und Backups. Wer Daten ernst nimmt, nutzt ZFS. Die Einrichtung erfordert etwas Einarbeitung, aber der Schutz Ihrer Daten ist jeden Aufwand wert.