ZFS oder Btrfs: Welches Dateisystem zu deinem Linux-Server passt

Entscheidend ist die Kombination aus Prüfsumme und Redundanz. Erkennt ZFS beim Lesen eine Abweichung und existiert eine zweite Kopie, wird der Block automatisch aus der intakten Kopie wiederhergestellt und repariert. Ohne Redundanz bekommst du immerhin eine ehrliche Fehlermeldung statt falscher Daten, und weißt, welche Datei betroffen ist.

# ZFS: liest alle Daten und repariert, was reparierbar ist
sudo zpool scrub tank
zpool status tank

# Btrfs: dasselbe Prinzip
sudo btrfs scrub start /mnt/daten
sudo btrfs scrub status /mnt/daten

# Fehlerzähler ansehen (READ/WRITE/CKSUM müssen 0 sein)
zpool status -v tank
sudo btrfs device stats /mnt/daten

Einmal im Monat ist ein guter Takt, bei Consumer-Hardware eher alle zwei Wochen. Der Scrub läuft im Hintergrund, kostet aber spürbar I/O. Leg ihn auf eine ruhige Zeit.

Ein oft übersehener Unterschied: Btrfs kann raid1 über Platten unterschiedlicher Größe legen und nutzt den Platz erstaunlich gut aus, weil es paarweise auf Chunk-Ebene arbeitet. ZFS erwartet innerhalb eines vdev gleich große Platten und richtet sich nach der kleinsten. Für gewachsene Heimserver mit gemischten Platten ist das ein echter Vorteil von Btrfs.

# ZFS: RAID-Z2 aus sechs Platten, immer /dev/disk/by-id verwenden
sudo zpool create -o ashift=12 tank raidz2 \
  /dev/disk/by-id/ata-WDC_... /dev/disk/by-id/ata-WDC_... \
  /dev/disk/by-id/ata-WDC_... /dev/disk/by-id/ata-WDC_... \
  /dev/disk/by-id/ata-WDC_... /dev/disk/by-id/ata-WDC_...

# Btrfs: Spiegel über zwei Platten
sudo mkfs.btrfs -m raid1 -d raid1 /dev/sda /dev/sdb

ashift=12 setzt die Blockgröße auf 4 KB und passt zu praktisch allen heutigen Platten und SSDs. Der Wert lässt sich nachträglich nicht ändern, ein falsch gesetzter ashift kostet dauerhaft Leistung. by-id statt /dev/sdX, weil sich die Buchstaben beim Booten verschieben können.

Zur Erweiterung: ZFS konnte lange nur ganze vdevs hinzufügen, ein RAID-Z ließ sich nicht um eine einzelne Platte erweitern. Mit OpenZFS 2.3 ist RAID-Z Expansion dazugekommen, sodass ein bestehendes RAID-Z um Platten wachsen kann. Btrfs konnte das schon immer, dort fügst du eine Platte hinzu und startest einen Balance-Lauf.

ZFS bringt mit dem ARC einen eigenen Lesecache mit, der standardmäßig bis zur Hälfte des Arbeitsspeichers belegt. Das sieht in free -h nach viel benutztem Speicher aus, ist aber Cache: Braucht eine Anwendung Speicher, gibt ZFS ihn zurück. Btrfs nutzt dagegen den normalen Seitencache des Kernels und fällt in der Speicherstatistik gar nicht auf.

# Aktuelle Größe und Trefferquote
arc_summary | head -40
cat /proc/spl/kstat/zfs/arcstats | grep -E '^(size|c_max|hits|misses) '

# Obergrenze setzen, z.B. 8 GB auf einem 32-GB-Server
echo 'options zfs zfs_arc_max=8589934592' | \
  sudo tee /etc/modprobe.d/zfs.conf
sudo update-initramfs -u   # Debian/Ubuntu
# danach Neustart

Eine Begrenzung ist vor allem dann sinnvoll, wenn auf derselben Maschine Datenbanken oder virtuelle Maschinen laufen, die ihren Speicher fest reservieren. Auf einem reinen Dateiserver lässt du den ARC am besten in Ruhe.

# Snapshot anlegen, rekursiv über alle untergeordneten Dateisysteme
sudo zfs snapshot -r tank/daten@$(date +%F-%H%M)

# Vorhandene ansehen
zfs list -t snapshot -o name,used,refer tank/daten

# Einzelne Datei zurückholen, ohne den ganzen Stand zu rollen
cp /tank/daten/.zfs/snapshot/2026-07-20-0300/wichtig.txt ~/

# Kompletten Stand zurückrollen (verwirft neuere Snapshots!)
sudo zfs rollback -r tank/daten@2026-07-20-0300

# Inkrementell auf einen zweiten Server übertragen
sudo zfs send -i tank/daten@gestern tank/daten@heute | \
  ssh backup@zweitserver "zfs receive -F sicherung/daten"

Das versteckte Verzeichnis .zfs/snapshot/ ist der schnellste Weg für Nutzende, eine gelöschte Datei selbst zurückzuholen. Mit zfs set snapdir=visible wird es sogar in Dateimanagern sichtbar.

# Schreibgeschützter Snapshot eines Subvolumes
sudo btrfs subvolume snapshot -r /mnt/daten /mnt/snapshots/daten-$(date +%F)

# Übertragung auf ein anderes Dateisystem
sudo btrfs send -p /mnt/snapshots/daten-gestern /mnt/snapshots/daten-heute | \
  ssh backup@zweitserver "btrfs receive /mnt/sicherung"

# Snapshot wieder entfernen
sudo btrfs subvolume delete /mnt/snapshots/daten-2026-06-01

Für die Übertragung muss der Snapshot schreibgeschützt sein (-r), sonst verweigert btrfs send den Dienst.

Automatisieren solltest du das nicht von Hand. Für ZFS haben sich sanoid und syncoid etabliert: Sanoid legt nach einem Zeitplan Snapshots an und räumt alte auf, Syncoid überträgt sie inkrementell. Im Btrfs-Umfeld übernimmt snapper diese Rolle, unter openSUSE ist es bereits eingerichtet.

# ZFS: lz4 ist seit Jahren die sichere Voreinstellung
sudo zfs set compression=lz4 tank

# Mehr Platzersparnis bei etwas mehr CPU-Last
sudo zfs set compression=zstd-3 tank/archiv

# Tatsächliche Ersparnis ansehen
zfs get compressratio,compression tank

# Btrfs: beim Einhängen aktivieren
sudo mount -o compress=zstd:3 /dev/sda /mnt/daten
# dauerhaft über /etc/fstab, Option compress=zstd:3

Bereits geschriebene Daten werden nicht rückwirkend komprimiert. Bei ZFS hilft nur Umkopieren, bei Btrfs ein btrfs filesystem defragment -r -czstd, das die Dateien neu schreibt.

Zur Wahl des Verfahrens: lz4 ist so schnell, dass es sich auch bei nicht komprimierbaren Daten nicht negativ auswirkt, weil ZFS solche Blöcke unkomprimiert ablegt. zstd holt spürbar mehr heraus, kostet aber CPU beim Schreiben. Für Archive und Backups ist zstd auf Stufe 3 bis 6 eine gute Wahl, für Datenbanken und virtuelle Maschinen bleibt lz4 die verlässlichere Einstellung.

ZFS führt für die Deduplizierung eine Tabelle aller Blockprüfsummen, die DDT. Diese Tabelle muss für akzeptable Geschwindigkeit im Arbeitsspeicher liegen. Als Faustregel gelten rund 5 GB RAM je TB deduplizierter Daten. Passt sie nicht mehr in den Speicher, wandert sie auf die Platte, und jeder Schreibvorgang wird zur Zufallslesung. Der Server fühlt sich dann nicht langsam an, sondern defekt.

# Simulation: Was würde Deduplizierung überhaupt bringen?
sudo zdb -S tank

# Interessant ist die letzte Zeile: dedup = 1.23 bedeutet 23 Prozent Ersparnis
# Unter etwa 2.0 lohnt es sich praktisch nie

Kompression bringt bei realen Daten meist mehr als Deduplizierung, kostet einen Bruchteil der Ressourcen und lässt sich jederzeit wieder abschalten. Deduplizierung hingegen bekommst du nur durch vollständiges Umkopieren des Datensatzes wieder los.

# Special-vdev IMMER als Spiegel
sudo zpool add tank special mirror \
  /dev/disk/by-id/nvme-... /dev/disk/by-id/nvme-...

# Kleine Dateien zusätzlich dorthin legen
sudo zfs set special_small_blocks=32K tank/viele-kleine-dateien

# L2ARC (unkritisch, Ausfall kostet nur Geschwindigkeit)
sudo zpool add tank cache /dev/disk/by-id/nvme-...

Vor jedem zpool add ein -n für den Trockenlauf. Ein versehentlich als Datenspeicher hinzugefügtes vdev lässt sich bei RAID-Z nicht mehr entfernen.

Die ehrliche Reihenfolge lautet: Erst mehr Arbeitsspeicher, dann ein special-vdev, und erst danach über SLOG oder L2ARC nachdenken. In der Mehrzahl der Fälle, in denen jemand eine SSD als Cache einbaut, hätte zusätzlicher RAM mehr gebracht und weniger gekostet.

# Subvolumes sind eigenständige Bäume im selben Dateisystem
sudo btrfs subvolume create /mnt/daten/projekte
sudo btrfs subvolume list /mnt/daten

# Snapper einrichten
sudo snapper -c projekte create-config /mnt/daten/projekte
sudo snapper -c projekte list

# Was hat sich zwischen zwei Ständen geändert?
sudo snapper -c projekte status 42..47
sudo snapper -c projekte undochange 42..47 /pfad/zur/datei

undochange ist die Funktion, für die Btrfs-Nutzende das System lieben: gezielt einzelne Änderungen zurücknehmen, statt den ganzen Stand zu rollen.

Der praktische Nutzen zeigt sich beim Systemupdate. Läuft die Wurzel auf Btrfs und ist Snapper eingerichtet, entsteht vor jeder Paketaktualisierung automatisch ein Snapshot. Geht etwas schief, bootest du aus dem GRUB-Menü in den vorherigen Stand zurück. Das ist unter openSUSE seit Jahren erprobt und einer der überzeugendsten Gründe für Btrfs auf Arbeitsplatzrechnern.

# Btrfs zeigt freien Platz anders als df - dieser Befehl ist die Wahrheit
sudo btrfs filesystem usage /mnt/daten

# Chunks neu verteilen, wenn 'unallocated' knapp wird
sudo btrfs balance start -dusage=50 -musage=50 /mnt/daten
sudo btrfs balance status /mnt/daten

Ein voller Btrfs-Pool ist schwerer zu retten als ein voller ZFS-Pool, weil selbst das Löschen Platz für Metadaten braucht. Halte immer Reserve frei und beobachte unallocated, nicht nur die Ausgabe von df.

# Speicherhunger zügeln
echo 'options zfs zfs_arc_max=4294967296' | sudo tee /etc/modprobe.d/zfs.conf

# SSD dauerhaft trimmen
sudo zpool set autotrim=on rpool

# Verschlüsseltes Dataset für die Arbeitsdaten
sudo zfs create -o encryption=aes-256-gcm -o keyformat=passphrase rpool/arbeit

# Automatische Snapshots
sudo apt install zfs-auto-snapshot
zfs list -t snapshot | tail

# Nach einem misslungenen Update zurück
sudo zfs rollback rpool/ROOT/ubuntu@autozsys_vor_update

Bei Root-on-ZFS unter Ubuntu erledigt zsys die Snapshots vor Paketoperationen und trägt Rollback-Punkte ins GRUB-Menü ein. Prüfe nach der Installation, ob die Automatik wirklich aktiv ist.

Was in keiner Tabelle steht, aber die Entscheidung oft dominiert: Nimm das System, das ihr im Team betreiben könnt. Ein ZFS-Pool, dessen Aufbau nur eine Person versteht, ist im Störungsfall ein Risiko. Beide Dateisysteme verlangen Wissen über Snapshots, Scrub-Zyklen, Platzverhalten und Wiederherstellung, und dieses Wissen gehört auf mindestens zwei Köpfe verteilt.