Eine Proxmox-Vorlage von OVH von LVM auf ZFS umstellen

Die Proxmox-Vorlagen von OVH werden standardmäßig auf LVM installiert. Das ist schnell bereitgestellt, verbaut aber die Replikation zwischen Knoten, atomare Snapshots und die native Datenintegrität. Um die echte Hochverfügbarkeit von Proxmox freizuschalten, müssen Sie auf ZFS umsteigen: Hier ist das vollständige Vorgehen, in Produktion getestet auf einem OVH-Cluster mit drei Knoten.

Warum ZFS für Hochverfügbarkeit #

ZFS ermöglicht native Replikation zwischen Knoten über zfs send/receive, den Mechanismus, den das HA-Modul von Proxmox nutzt. LVM kann das nicht. Weitere Vorteile: nahezu sofortige atomare Snapshots, native Kompression (2026 mit zstd praktisch ohne CPU-Kosten) und eine regelmäßige Integritätsprüfung (Scrub), die stille Datenfehler erkennt, bevor sie sich in die Backups ausbreiten.

Die Nachteile, die Sie kennen sollten: ZFS braucht Arbeitsspeicher (mindestens 1 GB ARC pro TB Nutzdaten einplanen), kann einen Pool nicht so flexibel erweitern wie LVM (eine weitere Festplatte bedeutet ein neues vdev oder einen kompletten Austausch), und einige exotische Linux-Operationen (chmod mit POSIX-ACL, NFS-Root) erfordern besondere Einstellungen.

Voraussetzungen #

• Proxmox-8.x-Cluster mit mindestens 2 Knoten (auf einem einzelnen Knoten bleibt ZFS für Snapshots und Integrität nützlich).
• Ein eigener Datenträger für ZFS: eine zweite physische Festplatte, idealerweise NVMe bei den OVH-Serien High Grade, Scale oder Advance. LVM und ZFS können sich nicht denselben Datenträger teilen.
• Root-Zugang per SSH auf allen Knoten des Clusters.
• Ein vollständiges, getestetes Backup VOR dem Eingriff (PBS, LVM-Snapshot oder Export mit vzdump, je nach Umgebung).
• Arbeitsspeicher: mindestens 8 GB auf dem Host einplanen, davon etwa 4 GB für den ZFS-ARC (Cache). Das genaue Tuning steht in Schritt 3.

Schritt 1: ZFS bei Bedarf installieren #

Auf aktuellen Proxmox-Vorlagen von OVH ist zfsutils-linux bereits installiert. Auf älteren Images oder bei einer manuellen Installation aus Debian plus Proxmox müssen Sie es ausdrücklich nachinstallieren.

apt update && apt install -y zfsutils-linux
modprobe zfs
zfs version

Der Befehl zfs version bestätigt, dass das Kernelmodul geladen ist. Schlägt er fehl, fehlen dem laufenden Kernel typischerweise die ZFS-Header: pve-headers-$(uname -r) neu installieren und das Modul erneut laden.

Schritt 2: den ZFS-Pool anlegen #

Wir legen auf dem eigenen Datenträger einen ZFS-Speicherpool namens rpool an (Proxmox-Konvention) und setzen gleich bei der Erstellung zwei grundlegende Einstellungen.

# Zuerst das richtige Zielgerät prüfen
lsblk
parted -l

# Pool auf dem zweiten Datenträger anlegen
zpool create -o ashift=12 rpool /dev/sdb

# Kompression aktivieren und atime abschalten (Leistung)
zfs set compression=zstd rpool
zfs set atime=off rpool

# Eigenes Dataset für VMs und CTs anlegen
zfs create rpool/data

Warum ashift=12 #

ashift=12 richtet die ZFS-Blöcke auf 4 KB aus (2^12 Byte), die native Größe moderner SSDs und NVMe-Laufwerke. Ohne diesen Parameter könnte sich ZFS auf 512 Byte ausrichten, was die Schreibleistung auf Flash-Speicher durch 4 bis 8 teilt. Der Parameter wird bei der Erstellung des Pools festgeschrieben und ist danach nicht mehr änderbar, deshalb muss er von Anfang an gesetzt sein.

Kompression: zstd statt lz4 #

Die ältere Proxmox-Dokumentation empfahl lz4. Auf Kerneln ab 6.5 mit ZFS ab 2.2 (Standard seit Proxmox 8.1) bietet zstd mit der Standardstufe 3 eine bessere Kompressionsrate bei kaum höheren CPU-Kosten und bleibt dank Multithreading beim Lesen schneller als lz4. Ohne besonderen Grund (sehr schwache CPU, extreme synchrone Last) setzen Sie direkt auf zstd.

Schritt 3: den ZFS-ARC (Arbeitsspeicher) einstellen #

Standardmäßig belegt ZFS bis zu 50 % des gesamten Arbeitsspeichers des Hosts für seinen ARC-Cache (Adaptive Replacement Cache). Auf einem OVH-Server mit 32 GB Arbeitsspeicher für 8 VMs würde ZFS beim Start 16 GB beanspruchen und nur 16 GB für die VMs und den Hypervisor selbst übrig lassen. Das ist fast immer zu viel, vor allem wenn die VMs im Gast ihren eigenen Dateisystem-Cache haben.

Pragmatische Regel: den ARC auf 1 GB pro TB tatsächlich genutzter ZFS-Daten festlegen, höchstens 25 % des gesamten Arbeitsspeichers des Hosts. Bei 32 GB Arbeitsspeicher ergibt das je nach Poolgröße 4 bis 8 GB ARC.

# ARC auf 4 GB begrenzen (Wert in Byte: 4 * 1024^3)
echo 'options zfs zfs_arc_max=4294967296' > /etc/modprobe.d/zfs.conf
update-initramfs -u
systemctl reboot

# Nach dem Neustart die tatsächlichen Werte prüfen
awk '/^c_max|^size/ {print $1, $3}' /proc/spl/kstat/zfs/arcstats

Schritt 4: den Speicher in Proxmox hinzufügen #

Über die Weboberfläche: Datacenter → Storage → Add → ZFS. Den Pool rpool/data auswählen, eine lesbare ID vergeben (z. B. local-zfs), Thin provision ankreuzen, um Platz zu sparen. Shared NICHT ankreuzen, außer Sie haben einen synchronen Pool zwischen den Knoten (selten, etwa Ceph auf ZFS). Für die klassische asynchrone Replikation von Proxmox bleibt dieses Feld leer.

Schritt 5: bestehende VMs umziehen #

Annahme: Die OVH-Vorlage hat einen Speicher local-lvm auf LVM angelegt, auf dem Ihre VMs derzeit liegen. Die folgenden Befehle verschieben eine VM (VMID 100) von LVM in den neuen ZFS-Pool, je nach Lage im laufenden oder im ausgeschalteten Zustand.

# Aktuelle Datenträger der VM 100 ermitteln
qm config 100 | grep -E '^(scsi|virtio|sata|ide)[0-9]'

# Online-Migration (VM läuft, Kopie ohne Unterbrechung ~ 1 bis 3 GB/min)
qm move-disk 100 scsi0 local-zfs --delete

# Offline-Migration (VM ausgeschaltet, deutlich schneller)
qm shutdown 100 && qm move-disk 100 scsi0 local-zfs --delete && qm start 100

Schritt 6: Replikation zwischen Knoten aktivieren #

Liegt die VM auf ZFS, ist die Replikation einfach. In der Weboberfläche die VM öffnen → Replication → Add → Zielknoten und Häufigkeit wählen (Cron im Proxmox-Format: */15 = alle 15 Minuten, 0 */6 = alle 6 Stunden zur vollen Stunde).

Prüfen Sie in den Logs (/var/log/pve/replicate-*), ob die erste Replikation durchläuft. Die erste Synchronisierung überträgt das gesamte Dataset, die folgenden nur noch die geänderten Blöcke (Delta mit zfs send -i), typischerweise 50 bis 500 MB pro Durchlauf bei einer mäßig aktiven VM.

Überwachung und Wartung des Pools #

Ein ZFS-Pool ohne Überwachung ist eine stille Falle: Datenfehler auf einem Datenträger können wochenlang unbemerkt bleiben, bis sie bei einer Replikation oder einem Backup auftauchen, zu einem Zeitpunkt, an dem es für eine Wiederherstellung zu spät ist, weil die Backups die beschädigten Blöcke bereits enthalten.

Täglicher Zustandscheck #

# Zustand des Pools und der Datenträger, Erkennung von Datenfehlern
zpool status -v rpool

# Alles in Ordnung, wenn die Ausgabe zeigt:
#   state: ONLINE
#   errors: No known data errors

Automatischer monatlicher Scrub #

Ein Scrub liest den gesamten Pool und vergleicht die Prüfsummen: Nur so lassen sich stille Datenfehler (Bit Rot) erkennen, bevor sie sich ausbreiten. Proxmox 8 bringt einen systemd-Timer zfs-scrub-monthly@rpool.timer mit: Prüfen Sie, ob er aktiviert ist.

# Automatischen monatlichen Scrub auf dem Pool rpool aktivieren
systemctl enable --now zfs-scrub-monthly@rpool.timer

# Manuellen Scrub bei Bedarf starten (dauert auf großen Pools mehrere Stunden)
zpool scrub rpool

# Fortschritt verfolgen
zpool status rpool

E-Mail-Alarm bei degradiertem Pool #

Der Pool kann in den Zustand DEGRADED (eine ausgefallene Festplatte in einem Mirror) oder FAULTED (Redundanz verloren, Daten möglicherweise unzugänglich) wechseln, ohne dass es jemand bemerkt. Konfigurieren Sie den Daemon zed (ZFS Event Daemon) so, dass er bei jeder kritischen Zustandsänderung eine E-Mail schickt.

# zed mit der Empfängeradresse für Warnungen konfigurieren
sed -i 's|^#ZED_EMAIL_ADDR=.*|ZED_EMAIL_ADDR="admin@exemple.fr"|' /etc/zfs/zed.d/zed.rc
sed -i 's|^#ZED_NOTIFY_INTERVAL_SECS=.*|ZED_NOTIFY_INTERVAL_SECS=3600|' /etc/zfs/zed.d/zed.rc
systemctl restart zfs-zed

# Mit einem simulierten Ereignis testen (ohne den Pool zu beschädigen)
zpool events rpool

Typische Fallstricke #

• Zu niedriges ashift: Pool ohne ashift=12 auf SSD oder NVMe angelegt. Schreibleistung geteilt durch 4 bis 8, nur durch Neuanlage des Pools zu beheben.
• ARC frisst den Arbeitsspeicher: Ohne zfs_arc_max kann der ARC verhindern, dass VMs mangels freien Arbeitsspeichers starten. Symptom: VMs werden ohne Ursache in der Anwendung vom OOM-Killer beendet.
• Datenträger ohne Planung hinzugefügt: zpool add fügt ein neues vdev hinzu (erweitert also den Pool). Ist der neue Datenträger nicht gespiegelt, zerstört der Ausfall einer einzigen Festplatte den gesamten Pool. Immer die Topologie des bestehenden vdev nachbilden.
• Kein Scrub: Ohne Scrub fallen stille Datenfehler erst bei der Wiederherstellung eines Backups auf… das die beschädigten Blöcke inzwischen ebenfalls enthält.
• Replikation ohne Überwachung: Die Replikation kann still scheitern (Netzwerk, Platz auf dem Ziel, auseinanderlaufende Datasets). /var/log/pve/replicate-*.log überwachen und bei Fehlern warnen.

Fazit #

Wer eine OVH-Vorlage von LVM auf ZFS umstellt, schaltet drei Funktionen frei, die das Hochverfügbarkeitsversprechen von Proxmox erst wirklich nutzbar machen: Replikation zwischen Knoten, atomare Snapshots und regelmäßige Integritätsprüfung. Der Anfangsaufwand (1 bis 2 Stunden pro Knoten) rechnet sich spätestens beim ersten vermiedenen Festplattenausfall oder beim ersten stillen Datenfehler, den ein Scrub erkennt, bevor er die Backups verseucht.

Zur Backup-Strategie, die die ZFS-Replikation ergänzt, beschreibt die PBS-Anleitung die Deduplizierung an der Quelle, die mehrstufige Aufbewahrung und den Schutz vor Ransomware. Und wer dieses Setup auf einem Hetzner-Server statt bei OVH aufbauen möchte, findet in der Installation von Proxmox 8 auf Hetzner den passenden Einstieg vor dieser Anleitung.