ZFS-RAID-Pool für Proxmox erstellen: Mirror, RAIDZ1/Z2 und Snapshots für Einsteiger

Diese Anleitung zeigt, wie Sie einen ZFS RAID Pool in Proxmox erstellen: vom RAID-Level (Mirror, RAIDZ1 oder RAIDZ2) über die stabile Disk-Identifikation per /dev/disk/by-id bis zu Kompression und automatischen Snapshots. ZFS ist in Proxmox VE integriert, Zusatzpakete für den Pool brauchen Sie nicht. Sie richtet sich an Einsteiger und Homeserver-Betreiber, die ihren Storage ausfallsicher und wartbar aufsetzen möchten.

Was ist ein ZFS-Pool und warum lohnt er sich in Proxmox?

ZFS ist Dateisystem und Volume-Manager in einem. Ein ZFS-Pool (zpool) fasst physische Festplatten zu einem logischen Speicher zusammen, auf dem Sie Datasets (für Dateien) oder ZVOLs (Block-Devices für VM-Disks) anlegen. Anders als Hardware-RAID berechnet ZFS zu jedem Block eine Prüfsumme und erkennt so stille Datenfehler (Bit Rot).

Copy-on-Write liefert nahezu kostenlose, atomare Snapshots, schnelle VM-Klone und inkrementelle Replikation zwischen Hosts; dazu kommen transparente Kompression, Self-Healing bei redundanten Pools und ein gut dokumentiertes CLI.

Welches RAID-Level passt zu mir?

Die Wahl des vdev-Typs entscheidet über Ausfallsicherheit und nutzbare Kapazität. Hier die gängigen Varianten im Überblick:

RAIDZ1 vs. RAIDZ2 in Proxmox: RAIDZ1 toleriert genau einen Disk-Ausfall, RAIDZ2 verkraftet zwei gleichzeitig. Bei modernen, großen Festplatten (8 TB und mehr) dauert ein Resilver lange; fällt während dieses Wiederaufbaus eine zweite Disk aus, ist bei RAIDZ1 der ganze Pool verloren. Deshalb gilt für vier oder mehr große Disks die Empfehlung: lieber RAIDZ2. Für virtuelle Maschinen mit hohem Random-I/O ist ein Mirror (oder ein Pool aus mehreren Mirror-vdevs) meist die bessere Wahl als RAIDZ.

Voraussetzungen

1. Ein installiertes Proxmox VE mit Root-Zugriff (SSH oder Konsole).
2. Mindestens 2 Datenträger für einen Mirror, 3 für RAIDZ1, 4 für RAIDZ2 – idealerweise gleich groß und gleichen Typs.
3. Die vorgesehenen Disks dürfen keine wichtigen Daten mehr enthalten: Der Pool-Aufbau löscht sie.
4. Ausreichend RAM. Faustregel des Proxmox-Wikis für den ZFS-Cache (ARC): mindestens 2 GB Grundbedarf plus 1 GB je TB Pool-Kapazität, zusätzlich zum RAM für VMs und Container. Beispiel: 8 TB Pool = 10 GB für den ARC. Deutlich mehr, wenn Sie Deduplikation aktivieren (was Sie als Einsteiger nicht tun sollten).
5. SSDs für VM-Workloads idealerweise mit Power-Loss-Protection; vermeiden Sie für den Pool reine SMR-Festplatten.
6. Prozessor: jede x86-64-CPU, auf der Proxmox VE läuft. Prüfsummen und lz4-Kompression erzeugen nur geringe Last.

Schritt 1: Datenträger ermitteln und stabile IDs verwenden

Kürzel wie /dev/sda sind nicht stabil: Nach Reboot oder Controller-Wechsel wird aus sdb womöglich sdc. Arbeiten Sie in ZFS deshalb immer mit den persistenten Pfaden unter /dev/disk/by-id.

1. Verschaffen Sie sich einen Überblick über alle Datenträger:

lsblk -o NAME,SIZE,MODEL,SERIAL,TYPE

1. Listen Sie die stabilen IDs auf und notieren Sie die WWN- oder Modell-Seriennummer-Pfade Ihrer Zieldisks:

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

Einträge wie ata-CT2000MX500SSD1_2240E6XXXXXX oder wwn-0x5000c500xxxxxxxx ändern sich nicht; diese verwenden Sie. Ignorieren Sie Partitions-Einträge (-part1 usw.) und nehmen Sie immer die ganze Disk.

Verifizieren: Für jede vorgesehene Disk haben Sie einen Pfad unter /dev/disk/by-id/ notiert, und lsblk zeigt auf diesen Disks keine Partitionen mit Daten, die Sie noch brauchen.

Schritt 2: ashift korrekt bestimmen

ashift legt die kleinste Schreibblockgröße als Zweierpotenz fest. ashift=12 bedeutet 2^12 = 4096 Byte (4K), Standard für nahezu alle modernen Platten und SSDs. Falsch gesetzt (z. B. ashift=9 auf einer 4K-Disk) kostet dauerhaft Performance, denn nach dem Erstellen lässt sich der Wert nicht mehr ändern.

1. Prüfen Sie die physische Sektorgröße Ihrer Disks:

lsblk -o NAME,PHY-SEC,LOG-SEC,MODEL

Im Zweifel ist -o ashift=12 richtig; nur bei sehr modernen SSDs mit 8K-Pages kann ashift=13 sinnvoll sein.

Verifizieren: Die Spalte PHY-SEC zeigt 4096 oder 512 für Ihre Zieldisks. In beiden Fällen ist ashift=12 passend.

Schritt 3: Den ZFS-Pool erstellen (Mirror, RAIDZ1 oder RAIDZ2)

Der Pool heißt hier tank; wählen Sie einen kurzen Namen ohne Sonderzeichen und verwenden Sie die by-id-Pfade aus Schritt 1.

Variante A: Mirror (2 Disks)

zpool create -o ashift=12 -f tank mirror \
  /dev/disk/by-id/ata-DISK1_SERIAL \
  /dev/disk/by-id/ata-DISK2_SERIAL

Variante B: RAIDZ1 (3 Disks, 1 Disk Ausfalltoleranz)

zpool create -o ashift=12 -f tank raidz1 \
  /dev/disk/by-id/ata-DISK1_SERIAL \
  /dev/disk/by-id/ata-DISK2_SERIAL \
  /dev/disk/by-id/ata-DISK3_SERIAL

Variante C: RAIDZ2 (4 Disks, 2 Disks Ausfalltoleranz)

zpool create -o ashift=12 -f tank raidz2 \
  /dev/disk/by-id/ata-DISK1_SERIAL \
  /dev/disk/by-id/ata-DISK2_SERIAL \
  /dev/disk/by-id/ata-DISK3_SERIAL \
  /dev/disk/by-id/ata-DISK4_SERIAL

-f erzwingt das Erstellen trotz alter Signaturen; setzen Sie es nur, wenn die Disks sicher leer sein dürfen. Der Pool ist danach sofort unter /tank eingehängt.

Verifizieren: zpool list tank zeigt den Pool mit HEALTH ONLINE, und zpool get ashift tank liefert den Wert 12.

Schritt 4: Kompression und sinnvolle Pool-Defaults setzen

Aktivieren Sie zuerst die Kompression. lz4 ist extrem schnell, kostet kaum CPU und überspringt nicht-komprimierbare Blöcke automatisch.

zfs set compression=lz4 tank
zfs set atime=off tank
zfs set xattr=sa tank

atime=off spart Schreibzugriffe für kaum genutzte Zugriffszeitstempel, xattr=sa speichert erweiterte Attribute effizienter. Die Werte vererben sich an alle künftigen Datasets unter tank.

Verifizieren: zfs get compression,atime,xattr tank zeigt lz4, off und sa mit der Quelle local.

Schritt 5: Pool in Proxmox als Storage einbinden

Damit Proxmox VM-Disks und Container auf dem Pool ablegt, fügen Sie ihn als ZFS-Storage hinzu, in der Weboberfläche unter Rechenzentrum > Storage > Hinzufügen > ZFS oder per Kommandozeile:

pvesm add zfspool tank-vmdata -pool tank -content images,rootdir
pvesm status

tank-vmdata steht dann in Proxmox bereit; VM-Disks liegen als ZVOLs im Pool mit Snapshots und Kompression.

Verifizieren: pvesm status listet tank-vmdata vom Typ zfspool als active, und in der Weboberfläche erscheint der Storage unter Ihrem Knoten.

Schritt 6: Automatische ZFS-Snapshots mit Sanoid einrichten

Snapshots sind in Sekunden erstellt und belegen anfangs keinen Platz. Für automatische Snapshots ist Sanoid der De-facto-Standard (alternativ zfs-auto-snapshot); es übernimmt Rotation (stündlich/täglich/wöchentlich) und Aufräumen.

1. Sanoid (bringt das Replikations-Tool Syncoid mit) installieren:

apt update
apt install sanoid

1. Konfiguration anlegen unter /etc/sanoid/sanoid.conf:

[tank]
        use_template = production
        recursive = yes

[template_production]
        frequently = 0
        hourly = 36
        daily = 14
        weekly = 4
        monthly = 3
        autosnap = yes
        autoprune = yes

1. Einen manuellen Testlauf starten und prüfen, dass Snapshots entstehen:

sanoid --verbose --cron
zfs list -t snapshot -r tank

Das Debian-Paket startet Sanoid per systemd-Timer alle 15 Minuten; prüfen Sie ihn mit systemctl status sanoid.timer. Für inkrementelle Replikation auf einen zweiten Host als Off-Host-Backup nutzen Sie syncoid.

Verifizieren: systemctl is-active sanoid.timer meldet active, und zfs list -t snapshot -r tank zeigt Snapshots mit dem Namensmuster autosnap_…_hourly.

Schritt 7: Verifikation und erster Test

Prüfen Sie nun, ob alles sauber steht. Diese drei Befehle brauchen Sie auch später im Betrieb:

zpool status -v tank
zfs list -r tank
zpool list

zpool status -v muss ONLINE und unter errors: No known data errors zeigen, die Disks mit ihren by-id-Namen. Legen Sie testweise ein Dataset und einen manuellen Snapshot an:

zfs create tank/test
zfs snapshot tank/test@erster-snap
zfs list -t snapshot -r tank/test

Erscheint tank/test@erster-snap, funktionieren Snapshots. Entfernen Sie das Test-Dataset mit zfs destroy -r tank/test.

Verifizieren: zpool status -v tank meldet state: ONLINE und No known data errors, der Test-Snapshot war sichtbar, und nach zfs destroy -r tank/test zeigt zfs list -r tank kein tank/test mehr.

Updates & Wartung

Halten Sie den Proxmox-Host aktuell, ZFS-Verbesserungen kommen mit den OpenZFS-Kernelmodulen. Ein regelmäßiger Scrub liest alle Daten, gleicht Prüfsummen ab und repariert auf redundanten Pools stille Fehler.

zpool scrub tank
zpool status tank

Proxmox legt dafür einen monatlichen Cron-Job an (/etc/cron.d/zfsutils-linux); manuell starten Sie ihn wie oben gezeigt. Füllen Sie den Pool dauerhaft nicht über 80 Prozent, sonst leidet die Performance spürbar.

Backup-Hinweis

Wichtig: Snapshots sind kein Backup. Sie liegen im selben Pool und sind bei Totalausfall (Feuer, Diebstahl, mehrere Disk-Defekte) ebenfalls weg. Replizieren Sie per syncoid auf einen zweiten Host oder sichern Sie VMs zusätzlich mit Proxmox Backup Server oder einer anderen Backup-Lösung. Die 3-2-1-Regel (drei Kopien, zwei Medien, eine außer Haus) gilt auch mit ZFS.

Troubleshooting

1. „cannot create 'tank': one or more devices is currently in use“ – Auf einer Disk liegen noch Signaturen. Entfernen Sie sie mit wipefs -a /dev/disk/by-id/... (nur auf wirklich leeren Disks!) und versuchen Sie es erneut.
2. Pool nach Reboot nicht da – Importieren Sie ihn mit zpool import tank. Haben Sie beim Erstellen sdX statt by-id genutzt, hilft ein Re-Import mit zpool import -d /dev/disk/by-id tank, danach ist die Zuordnung stabil.
3. Disk im Pool als DEGRADED/FAULTED – Defekte Disk per zpool replace tank alte-id /dev/disk/by-id/neue-id tauschen und das Resilvering mit zpool status beobachten.
4. Schlechte Performance bei VMs – Pool zu voll, falscher ashift oder RAIDZ statt Mirror für Random-I/O. Prüfen Sie den Füllstand und passen Sie für VM-Workloads die volblocksize an.
5. Hoher RAM-Verbrauch durch ARC – Das ist normal: ZFS nutzt freien RAM als Cache. Bei Engpässen den ARC begrenzen über zfs_arc_max in /etc/modprobe.d/zfs.conf.

Häufige Fragen

Was bedeutet der ashift-Parameter bei ZFS genau?

Die kleinste Schreibblockgröße als Zweierpotenz; ashift=12 entspricht 4K-Sektoren. Der Wert ist unveränderlich, setzen Sie ihn explizit beim zpool create (Schritt 2).

RAIDZ1 oder RAIDZ2 – was soll ich in Proxmox nehmen?

RAIDZ1 verkraftet eine, RAIDZ2 zwei ausgefallene Disks. Bei großen Platten ab etwa 4 bis 8 TB ist das Resilvering lang und riskant, daher ab vier Disks RAIDZ2; für VM-Storage mit viel Random-I/O sind Mirror-vdevs meist besser.

Welche ZFS-Kompression ist die richtige?

Meist lz4. Nur bei stark komprimierbaren, selten geschriebenen Daten und reichlich CPU spart zstd mehr Platz.

Sind ZFS-Snapshots ein vollwertiges Backup?

Nein. Snapshots schützen vor versehentlichem Löschen oder Ransomware-Verschlüsselung auf dem Host, liegen aber im selben Pool. Replizieren Sie per Syncoid oder sichern Sie extern.

Brauche ich für ZFS in Proxmox einen Hardware-RAID-Controller?

Nein – im Gegenteil. ZFS will direkten Zugriff auf die rohen Disks. Betreiben Sie Controller im HBA-/IT-Modus (Pass-Through). Hardware-RAID verdeckt die Disks vor ZFS und nimmt ihm Self-Healing und Prüfsummen-Reparatur.

Fazit

ZFS in Proxmox liefert robusten, selbstheilenden Storage mit Snapshots, Kompression und Replikation. Die Stellschrauben: Disks per /dev/disk/by-id, ashift=12, RAID-Level nach Datenwert und Disk-Größe (Mirror für IOPS, RAIDZ2 für viele große Disks), von Anfang an lz4 und automatische Snapshots. Mit Sanoid und regelmäßigem Scrub fehlt nur noch ein echtes Off-Host-Backup.

Weiterführende Anleitungen & Quellen

Passende Anleitungen: Proxmox VE installieren und Grundkonfiguration, ZFS in der Praxis: Snapshots, Scrub, Replikation und Pool-Tuning sowie Proxmox Backup Server: S3-Offsite-Backups und Immutability. Weitere Anleitungen rund um Server, Storage und Infrastruktur finden Sie in der Kategorie Hardware auf s-edv.com.

Quellen: OpenZFS Documentation, Proxmox VE Wiki – ZFS on Linux und Sanoid/Syncoid auf GitHub.