# ZFS Pools & Datasets: Strukturiertes Storage-Management in Proxmox

TL;DR / Management Summary Ein ZFS-Pool ist eine Sammlung von physischen Festplatten (VDevs). Innerhalb dieses Pools strukturieren wir den Platz durch Datasets (für Datei-Ebene, z.B. LXC) und ZVOLs (für Block-Ebene, z.B. VMs). Ein Senior Admin trennt Datenströme durch verschiedene Datasets, nutzt individuelle Einstellungen für Kompression und Recordsize pro Workload und sichert die Integrität durch hierarchisches Quota-Management.

# 1. ZFS Pool Design

Das physische Fundament.

Wählen Sie das Layout passend zur Last:

• Mirror (RAID 10-Style): Der Standard für Performance. Beliebig viele Platten-Paare.
• RAIDZ2 (RAID 6-Style): Der Standard für Kapazität. Erlaubt den Ausfall von 2 Platten. (Min. 4 Disks).
• Wichtig: Ein Pool besteht aus VDevs. Wenn ein VDev (z.B. ein Single-Disk VDev) ausfällt, ist der gesamte Pool verloren!

# 2. Datasets vs. ZVOLs

Die logischen Container.

# 1. Datasets (File-based)

Verhalten sich wie Verzeichnisse mit Superkräften.

• Ideal für: LXC-Container, ISO-Archive, Backups.
• Features: Individuelle Kompression, Quotas und Mount-Optionen.

# 2. ZVOLs (Block-based)

Verhalten sich wie eine virtuelle Festplatte (/dev/zvol/...).

• Ideal für: VM-Disks (KVM).
• Wichtig: Stellen Sie die volblocksize bei der Erstellung fest ein (Standard 8K).

# 3. Deep Dive: Quotas & Reservations

Den Platz sicher verteilen.

ZFS teilt sich den Platz im Pool dynamisch. Ohne Limits kann ein Dataset den gesamten Pool füllen.

• Quota: Die Obergrenze. “Dieses Dataset darf nicht mehr als 100 GB belegen”.
• Reservation: Die Untergrenze. “Garantiere diesem Dataset 50 GB, egal wie voll der Rest ist”.
• Refquota: Bezieht sich nur auf die Daten im Dataset, nicht auf dessen Snapshots.

# 4. Day-2 Operations: Pool-Erweiterung

Wachsen im laufenden Betrieb.

Sie können einen ZFS-Pool jederzeit vergrößern:

• Option A: Ein neues VDev (z.B. ein weiteres Mirror-Paar) zum Pool hinzufügen.
• Option B: Bestehende Platten nacheinander gegen größere tauschen (zpool replace) und danach die autoexpand Eigenschaft nutzen.

# 5. Troubleshooting & “War Stories”

Wenn die Metadaten haken.

# Top 3 Fehlerbilder

1. Symptom: Pool zeigt “I/O Error”, aber alle Platten sind grün.

   • Ursache: Kabel-Wackelkontakt oder Überhitzung des HBAs.
   • Lösung: zpool events -v prüfen.

2. Symptom: Delete-Befehl dauert Minuten.

   • Ursache: Zu viele Snapshots auf einem ZVOL (Fragmentierung).
   • Fix: Anzahl der Snapshots pro Volume auf < 100 begrenzen.

3. Symptom: “Space Mismatch” zwischen Proxmox und ZFS.

   • Lösung: Nutzen Sie zfs list -o space für die echte Wahrheit.

# “War Story”: Die “Single-Disk” Falle

Ein Admin fügte einem RAIDZ2 Pool (6 Disks) eine einzelne SSD hinzu, um den Platz schnell zu erweitern. Das Ergebnis: ZFS fügte die SSD als neues VDev hinzu. Da dieses VDev keine Redundanz hatte, hing der gesamte 60 TB Pool nun an der Lebensdauer dieser einen billigen SSD. Die Katastrophe: Die SSD starb nach 2 Monaten. Da ZFS keine Daten ohne funktionierendes VDev lesen kann, waren alle 60 TB Daten schlagartig verloren. Lehre: Prüfen Sie die VDev-Struktur immer mit zpool status, bevor Sie auf “OK” klicken. Redundanz muss auf VDev-Ebene konsistent sein.

# 6. Monitoring & Reporting

Pool-Health.

# ZFS Monitoring (CLI)

# Zeigt die Kompressionsrate pro Dataset
zfs get compression,compressratio mypool

# Zeigt alle Snapshots und deren Platzverbrauch
zfs list -t snapshot

# 7. Fazit & Empfehlung

Ein gut strukturierter ZFS-Pool ist wartungsfrei über Jahre.

• Empfehlung: Erstellen Sie für jede VM-Klasse (z.B. prod, dev, archive) ein eigenes Parent-Dataset, um globale Eigenschaften (wie Kompression) vererben zu können.
• Wichtig: Aktivieren Sie die Eigenschaft atime=off auf allen Datasets, um unnötige Schreibvorgänge beim reinen Lesen von Dateien zu vermeiden.

# Anhang: Cheatsheet (ZFS Management)

# Referenzen

• OpenZFS: Admin Guide - Datasets
• Proxmox VE: ZFS Storage Configuration
• ZFS Recordsize Tuning (Jim Salter)