ZFS Grundlagen am Beispiel Proxmox VE(Stand Dezember 2025)

Der Verfasser des Artikels, Christian-Peter Zengel, hat zum Zeitpunkt des Artikels ca 18 Jahre Erfahrung mit ZFS und Proxmox. Er betreibt aktuell ca 150 Systeme mit Proxmox und ZFS

Das Einsatzgebiet geht von Standaloneinstallation bis zu ca 10 Hosts im Cluster. Es ist keine produktive Ceph Expertise vorhanden, jedoch wird intensiv an einer Hauslösung gearbeitet.

In der Praxis zeigt sich aber ZFS einfacher, vielseitiger, schneller und günstiger als CepH zu sein.

Dieser Dokumentation basiert auf diesem online Kurse von cloudistboese.de

24. + 26.11.2025 (13.00 Uhr bis 17.00 Uhr) - ZFS Grundlagen (Onlinekurs)

Diese Kurse sind ca alle sechs Monate online buchbar. Das Wiederholen der Onlinekurse, wie auch der Zugriff auf Aufzeichnungen sind kostenlos!

ZFS ist die perfekte Grundlage für kleine und mittlere Systeme um gegen Ausfälle, Dummheit anderer und Erpressungstrojanern ideal aufgestellt zu sein.
In diesem Kurs erhalten sie Grundkenntnisse für Systeme wie Proxmox, TrueNAS oder ähnliche Systeme.

Der Fokus liegt auf der Technologie und der permanenten Sicherheit im Umgang mit Daten, Linux und dem Terminal.

Themen:

• Begrifflichkeiten und Überblick
• Aufbau von Raids mit zpool
• Basisfunktionen am Beispiel von Proxmox VE
• Erklärung und Beispiele Snapshots und Rollbacks
• Praxisbeispiele Replikation
• Prüfung der Replikationen
• Weitere Features die das Leben massiv erleichtern

Nach diesem Kurs bist Du bei Ausfällen und Datenverlust vor dem Schlimmsten geschützt und in Minuten wieder produktiv!

https://de.wikipedia.org/wiki/ZFS_(Dateisystem)

https://www.proxmox.com/de/

https://cloudistboese.de

Erstellung eines Raids mit zpool

So erstellt Proxmox VE seinen ZFS Raid

zpool create -f -o cachefile=none -o ashift=12 rpool mirror disk1 disk2

Destruktives Anlegen (-f), kein automatisches Importieren beim Start (-o cachefile=none)
-o ashift=12 ist für 4k Festplatten, ashit=9 für 512e Disks, wobei man mit 12 nichts verkehrt macht
rpool ist der Name vom künftigen Pool, mirror der Raidlevel und die Disks wurden zweifelsfrei über Ihre ID definiert

Optionen für Raidlevel wären noch: ohne als Stripe, raidz, raidz2 oder raidz3, also Raid Level 5-7

Im aktuellen Kurs verwenden wir einen älteren Supermicro Server mit 24 Einschüben plus zwei NVMe, damit wir alles abbilden können. Die Verwendung bereits benutzter Disks, die teilweise nicht getestet wurden, wird bald die Notwendigkeit von ZFS bestätigen! Die NVMe sind nach ca zwei bis drei Jahren Cachebetrieb schon am Ende ihrer Laufleistung!

Daher immer Enterprise NVMe und natürlich ECC RAM benutzen, das spart eine Menge Ärger!

Sollten sich dennoch Daten auf Ihren Datenträgern befinden taugt die Wipe Funktion in PVE gut zur Wiederinbetriebnahme belegter Disks, es sei denn es war etwas mit LVM oder CepH auf den Disks. 
Solche Datenträger sollte man z. b. mit nwipe extern erst mal löschen.

 

Proxmox, also Debian Linux, bootet aus lizenztechnischen Gründen nicht direkt von ZFS.
Daher ist zu beachten daß immer genügend Bootdisks mit einem dreiteiligen Partitionslayout vorhanden sind. Würde man im Laufe der Zeit die beiden dritten Partitionen gegen komplette Disks ersetzen, wäre nichts mehr zum für den Systemstart vorhanden. Bei Proxmox VE übernimmt diesen Teil das Tool proxmox-boot-tool (format/init/status) der auf die zweite Partition angewendet wird. Die erste Partition enthält noch Grub für Bios Boot, die Dritte dann das eigentliche ZFS mit Proxmox VE.

Hierzu empfehle ich unsere Kursreihe Proxmox Produktiv mit ZFS betreiben!

Ermittlung der Laufwerke mit der Kommandozeile

Für den Betrieb empfehlen sich einige Werkzeuge die eventuell nicht enthalten sind, daher installieren wir diese über unseren Postinstaller oder per Hand

apt install lshw iotop

#Detailierte Übersicht aller Laufwerke
lshw -class disk

#Liveansicht beim Enschieben von Platten
dmesg -Tw #time follow

#Auflösung von symbolischen Links im System - Hier werden teilweise mehrere Namenskonventionen angeboten, pro Disk und pro Parition
ls -althr /dev/disk/by-id

Beispiel lshw

Beispiel by-id Ordner

Die Optionen der Raidanlage

Die wichtigsten Parameter sind RAID Level, Compression und Ashift. Alle drei Parameter können bei Fehlentscheidungen zu langfristigen Konsequenzen führen.

Beispiel Fehlentscheidung Raidlevel

• Mirror oder Striped Mirror (Raid 10) sind niemals eine falsche Entscheidung, jedoch verlieren wir hier immer 50% unserer Kapazität. Der entscheidende Vorteil bei einer Erweiterung ist daß man nur zwei Platten aus einem Spiegel ersetzen muss. Beim einfachen Mirror kann eine verdächtige Platte auch einfach entnommen und in die Schublade gelegt werden. Beim Austausch von Disks kann man auch einfach eine dritte Platte einspiegeln und später die Alte entfernen, so verliert man nie den Schutz beim Tausch und kann die alte Disk archivieren.
  • Vorteile: Schnell, einfach, problemlos
  • Nachteile: Hoher Verlust der Kapazität, 50% immer für Spiegel 
  • Optionen: Bei SATA / SAS Raids gut mit Cache und LOG per NVMe zu beschleunigen
• RaidZ Level 1-3 kann bei drehenden Festplatten eine fatale Entscheidung sein. Die Nutzlast entspricht immer der Anzahl der Platten minus ein bis drei Paritäten. Also RaidZ2 entspricht Raid6 und bei acht Platten würde die Kapazität von zwei Platten für Parität verloren gehen, bei RaidZ1 eine und natürlich bei RaidZ3 drei.
  • Vorteile: Mehr Platz, mehr Sicherheit, Erweiterbarkeit mit einzelnen Disks oder weiteren VDevs
  • Nachteile: Für VMs und LXCs nur bedingt als Datengrab, NAS, Fileserver geeignet
    
  • Optionen: Bei SATA / SAS HDDs und SSDs sind diese Raids gut mit Cache und LOG per NVMe zu beschleunigen. Zusätzlich besteht auch die Möglichkeit eines Special Devices, welches Metadaten und kleine Blöcke auf SSDs oder NVMes ablegt.
• Pool aus mehreren RaidZ-VDev kann als Kompromiss zwischen Platz und Leistung gewertet werden. Eine Vergrößereung des Pools ist dann an mehreren Stellen möglich
  • Vorteile: Mehr Platz, mehr Sicherheit, Erweiterbarkeit mit einzelnen Disks oder weiteren VDevs und schneler als ein RaidZ mit nur einem VDev bei gleicher Anzahl von Disks
  • Nachteile: Für VMs und LXCs nur bedingt als Datengrab, NAS, Fileserver geeignet
    
  • Optionen: Bei SATA / SAS HDDs und SSDs sind diese Raids gut mit Cache und LOG per NVMe zu beschleunigen. Zusätzlich besteht auch die Möglichkeit eines Special Devices, welches Metadaten und kleine Blöcke auf SSDs oder NVMes ablegt.
    

Virtuelle Maschinen im Normalfall nie auf drehende Disks mit RaidZ ablegen. Als Kompromiss kann man gut SATA RaidZ plus Cache & LOG Beschleunigung verwenden um Platz zu gewinnen

Die Analge von Raids per Proxmox ist möglich, jedoch ist man mit der Konfiguration per Kommandozeile viel flexibler!

Beispiel Fehlentscheidung Ashift

Hier etwas technischer Hintergrund im Vorfeld

Bei ZFS bezeichnet ashift die Blockgröße (Sektorgröße), mit der ZFS intern auf einem vdev arbeitet.Üblicherweise arbeiteten wir früher mit ashift=9 (512b) oder ashift=12 (4096b, also 4k)...

Daher aktuel immer ashift=12 nehmen um alle aktuell angesagten Disks in allen Raidlevel zu unterstützen.
Setzt man diesen Wert oder auch den volblocksize Wert kleiner als 16, schreibt zfs einzelne Blöcke auf mehr als Einen!

Die Konsequenz sind massive Leistungseinbusen und Platzverschwendung von bis zu 50%!

Beispiel der unspektakulären Raidanlage unter ProxmoxVE

Nach der Anlage eines Raid mit ProxmoxVE empfiehlt sich die Basis nicht wie hier auf mirror500g zu setzen, sondern die zu erwartenden Dateisysteme und Volumes zu strukturieren und dann dort den Proxmox Storage zu definieren

zfs create mirror500g/data
zfs create mirror500g/clone
zfs create -o com.sun:auto-snapshot=false mirror500g/repl #die option sorgt dafür daß das Tool zfs-auto-snapshot hier nicht arbeitet

Danach den Storage unter Cluster in ProxmoxVE definieren, z. b. als mirror500g-data