Wenn du einen ZFS RAID Pool in Proxmox erstellen willst, bekommst du mit dieser Anleitung einen kompletten, praxisnahen Fahrplan: vom richtigen 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 bereits integriert, du brauchst also keine Zusatzpakete für den Pool selbst. Diese Anleitung richtet sich an Einsteiger und Homeserver-Betreiber, die ihren Storage von Anfang an sauber, ausfallsicher und wartbar aufsetzen möchten – mit echten Befehlen, die du direkt auf deinem Proxmox-Host nachvollziehen kannst.

Kurzfassung: Disks per by-id ansprechen, Pool mit zpool create -o ashift=12 anlegen (Mirror für 2 Disks, RAIDZ1/Z2 ab 3 bzw. 4 Disks), compression=lz4 setzen, Pool als Proxmox-Storage einbinden und mit Sanoid automatische Snapshots einrichten.

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

ZFS ist ein kombiniertes Dateisystem und Volume-Manager. Ein ZFS-Pool (kurz: zpool) fasst eine oder mehrere physische Festplatten zu einem logischen Speicher zusammen. Auf diesem Pool legst du anschließend Datasets (für Dateien) oder ZVOLs (Block-Devices für VM-Disks) an. Im Gegensatz zu klassischem Hardware-RAID kennt ZFS den Inhalt der Daten: Es berechnet zu jedem Block eine Prüfsumme und erkennt damit stille Datenfehler (Bit Rot), die ein normaler RAID-Controller nicht bemerken würde.

Für Proxmox VE ist ZFS besonders attraktiv, weil es Copy-on-Write nutzt. Daraus ergeben sich nahezu kostenlose, atomare Snapshots, schnelle Klone von VMs und eine inkrementelle Replikation zwischen Hosts. Dazu kommen transparente Kompression, Self-Healing bei redundanten Pools und ein einfaches, 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:

TypMin. DisksAusfalltoleranzNutzkapazität (ca.)Einsatz

Mirror

1 Disk je Mirror-Paar

50 %

VMs, schnelle IOPS, kleine Hosts

RAIDZ1

1 Disk

~66–75 %

Medien, Archive, moderate Redundanz

RAIDZ2

2 Disks

~50–75 %

große Disks, wichtige Daten

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

Ein installiertes Proxmox VE mit Root-Zugriff (SSH oder Konsole).
Mindestens 2 Datenträger für einen Mirror, 3 für RAIDZ1, 4 für RAIDZ2 – idealerweise gleich groß und gleichen Typs.
Die vorgesehenen Disks dürfen keine wichtigen Daten mehr enthalten: Der Pool-Aufbau löscht sie.
Ausreichend RAM. Faustregel für ZFS: rund 1 GB pro TB Pool-Kapazität als Richtwert, deutlich mehr, wenn du Deduplikation aktivierst (was du als Einsteiger nicht tun solltest).
SSDs für VM-Workloads idealerweise mit Power-Loss-Protection; vermeide für den Pool reine SMR-Festplatten.

Schritt 1: Datenträger ermitteln und stabile IDs verwenden

Bevor du einen Pool baust, musst du wissen, welche Disks du verwendest. Klassische Kürzel wie /dev/sda sind nicht stabil: Nach einem Reboot oder einem Controller-Wechsel kann aus sdb plötzlich sdc werden. Deshalb arbeitest du in ZFS immer mit den persistenten Pfaden unter /dev/disk/by-id.

Verschaffe dir einen Überblick über alle Datenträger:

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

Liste die stabilen IDs auf und merke dir die WWN- oder Modell-Seriennummer-Pfade deiner Zieldisks:

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

Du siehst dort Einträge wie ata-CT2000MX500SSD1_2240E6XXXXXX oder wwn-0x5000c500xxxxxxxx. Diese Bezeichner ändern sich nicht und genau sie verwendest du beim Pool-Aufbau. Ignoriere die Partitions-Einträge (Endung -part1 usw.) und nimm immer die ganze Disk.

Schritt 2: ashift korrekt bestimmen

Der Parameter ashift legt die kleinste Blockgröße fest, mit der ZFS auf die Disk schreibt – als Zweierpotenz. ashift=12 bedeutet 2^12 = 4096 Byte (4K) und ist heute der Standard für nahezu alle modernen Platten und SSDs. Falsch gesetzt (z. B. ashift=9 für 512-Byte-Sektoren auf einer 4K-Disk) verlierst du dauerhaft Performance, und ändern lässt sich der Wert nach dem Erstellen nicht mehr.

Prüfe die physische Sektorgröße deiner Disk (Beispielpfad anpassen):

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

Im Zweifel ist -o ashift=12 die sichere Wahl. Nur bei sehr modernen SSDs mit 8K-Pages kann ashift=13 sinnvoll sein – für Einsteiger bleib bei 12.

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

Jetzt baust du den Pool. Wir nennen ihn tank – wähle einen kurzen, klaren Namen ohne Sonderzeichen. Wichtig: Du verwendest 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

Das -f erzwingt das Erstellen, falls ZFS noch Reste alter Signaturen findet. Setze es nur, wenn du sicher bist, dass die Disks leer sein dürfen. Nach dem Befehl ist der Pool sofort unter /tank eingehängt.

Schritt 4: Kompression und sinnvolle Pool-Defaults setzen

Aktiviere als Erstes Kompression. lz4 ist extrem schnell, kostet praktisch keine CPU und überspringt nicht-komprimierbare Blöcke automatisch – es gibt kaum einen Grund, es nicht zu nutzen.

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

Kurz erklärt: atime=off spart unnötige Schreibzugriffe (Zugriffszeitstempel braucht fast niemand), und xattr=sa speichert erweiterte Attribute effizienter. Diese Werte vererben sich an alle künftigen Datasets unterhalb von tank.

Schritt 5: Pool in Proxmox als Storage einbinden

Damit Proxmox VM-Disks und Container auf dem Pool ablegen kann, fügst du ihn als ZFS-Storage hinzu. Über die Weboberfläche geht das unter Rechenzentrum > Storage > Hinzufügen > ZFS. Auf der Kommandozeile geht es genauso schnell:

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

Damit steht tank-vmdata in Proxmox zur Verfügung. VM-Disks landen dann als ZVOLs im Pool und profitieren automatisch von Snapshots und Kompression.

Schritt 6: Automatische ZFS-Snapshots mit Sanoid einrichten

Snapshots sind das Killer-Feature von ZFS: Sie sind in Sekunden erstellt und belegen anfangs keinen zusätzlichen Platz. Für regelmäßige, automatische ZFS-Snapshots ist Sanoid der De-facto-Standard; alternativ gibt es zfs-auto-snapshot. Sanoid übernimmt die Rotation (stündlich/täglich/wöchentlich) und das Aufräumen alter Stände.

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

apt update
apt install sanoid

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

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

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

Sanoid bringt einen systemd-Timer mit, der den Cron-Lauf in der Regel minütlich auslöst. Kontrolliere ihn mit systemctl status sanoid.timer. Möchtest du Snapshots zusätzlich auf einen zweiten Host replizieren, nutzt du syncoid – das geht inkrementell und ist ideal für ein Off-Host-Backup.

Schritt 7: Verifikation und erster Test

Prüfe nun, ob alles sauber steht. Diese drei Befehle solltest du dir merken:

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

Bei zpool status -v muss der Zustand ONLINE lauten und unter errors: sollte No known data errors stehen. Achte darauf, dass die Disks dort mit ihren by-id-Namen erscheinen – das bestätigt die stabile Identifikation. Lege testweise ein Dataset an und erzeuge einen manuellen Snapshot:

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

Erscheint tank/test@erster-snap in der Liste, funktioniert die Snapshot-Mechanik. Das Test-Dataset kannst du danach mit zfs destroy -r tank/test wieder entfernen.

Updates & Wartung

Halte den Proxmox-Host regelmäßig aktuell, denn ZFS-Verbesserungen kommen über die OpenZFS-Kernelmodule mit den Updates. Plane zusätzlich einen wöchentlichen Scrub ein – er liest alle Daten, gleicht Prüfsummen ab und repariert auf redundanten Pools stille Fehler automatisch.

zpool scrub tank
zpool status tank

Proxmox legt für regelmäßige Scrubs bereits einen monatlichen Cron-Job an (/etc/cron.d/zfsutils-linux). Behalte außerdem den Füllstand im Blick: Ein ZFS-Pool sollte dauerhaft nicht über 80 Prozent gefüllt sein, sonst leidet die Performance spürbar.

Backup-Hinweis

Wichtig: Snapshots sind kein Backup. Sie liegen im selben Pool und sind bei einem Totalausfall (Feuer, Diebstahl, mehrere Disk-Defekte gleichzeitig) ebenfalls weg. Repliziere Snapshots per syncoid auf einen zweiten Host oder sichere deine VMs zusätzlich mit dem Proxmox Backup Server bzw. einer dedizierten Backup-Lösung. Die 3-2-1-Regel (drei Kopien, zwei verschiedene Medien, eine Kopie außer Haus) gilt auch mit ZFS – ganz gleich, ob du Proxmox Backup Server, Veeam oder eine andere Lösung einsetzt.

Troubleshooting

"cannot create 'tank': one or more devices is currently in use" – Auf einer Disk liegen noch Signaturen. Prüfe mit wipefs -a /dev/disk/by-id/... (nur auf wirklich leeren Disks!) und versuche es erneut.
Pool nach Reboot nicht da – Importiere ihn mit zpool import tank. Hast du 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.
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.
Schlechte Performance bei VMs – Pool zu voll, falscher ashift oder RAIDZ statt Mirror für Random-I/O. Prüfe Füllstand und passe für VM-Workloads die volblocksize an.
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?

ashift definiert die kleinste Schreibblockgröße als Zweierpotenz. ashift=12 entspricht 4K-Sektoren und ist heute Standard. Der Wert ist nach dem Erstellen unveränderlich, deshalb prüfst du ihn vorher und setzt ihn explizit beim zpool create.

RAIDZ1 oder RAIDZ2 – was soll ich in Proxmox nehmen?

RAIDZ1 toleriert den Ausfall einer Disk, RAIDZ2 zweier Disks. Bei großen Festplatten ab etwa 4 bis 8 TB ist das Resilvering lang und riskant, daher empfiehlt sich RAIDZ2 ab vier Disks. Für VM-Storage mit viel Random-I/O sind Mirror-vdevs meist besser als jedes RAIDZ.

Welche ZFS-Kompression ist die richtige?

Für die allermeisten Fälle lz4: sehr schnell, minimaler CPU-Aufwand, automatischer Skip nicht-komprimierbarer Daten. Nur bei stark komprimierbaren, selten geschriebenen Daten und reichlich CPU kann zstd mehr Platz sparen.

Sind ZFS-Snapshots ein vollwertiges Backup?

Nein. Snapshots schützen vor versehentlichem Löschen oder Ransomware-Verschlüsselung innerhalb des Hosts, liegen aber im selben Pool. Für echten Schutz replizierst du sie per Syncoid auf einen zweiten Host oder sicherst zusätzlich extern.

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

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

Fazit

Einen ZFS RAID Pool in Proxmox zu erstellen ist mit den richtigen Befehlen schnell erledigt und gibt dir einen robusten, selbstheilenden Storage mit Snapshots, Kompression und einfacher Replikation. Die wichtigsten Stellschrauben: Disks immer per /dev/disk/by-id ansprechen, ashift=12 setzen, das RAID-Level nach Datenwert und Disk-Größe wählen (Mirror für IOPS, RAIDZ2 für viele große Disks) und von Anfang an lz4 sowie automatische Snapshots aktivieren. Mit Sanoid und einem regelmäßigen Scrub hast du eine wartungsarme Basis, die du nur noch um ein echtes Off-Host-Backup ergänzen musst.

Weiterführende Anleitungen & Quellen

Weitere Anleitungen rund um Server, Storage und Infrastruktur findest du in der Kategorie Hardware auf s-edv.com.

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