Proxmox Vergleich der Storage-Varianten vs. ZFS zu Fuß

Proxmox VE Storage im Vergleich: Ceph, ZFS, SAN/iSCSI und sichere ZFS-Replikation

Stand: 31. August 2026

Welche Storage-Lösung passt zu Proxmox VE: Ceph RBD, lokales ZFS oder ein SAN mit iSCSI und klassischem LVM? Dieser Praxisvergleich erklärt die wichtigsten Unterschiede bei Hochverfügbarkeit, Snapshots, Live-Migration, Thin Provisioning und Wiederherstellung. Anschließend zeigen wir, wie automatische ZFS-Snapshots, Pull-Replikation mit zsync, GUID-Kontrolle mit checkzfs.py und der Miyagi-Workflow eine mehrstufige Backup- und Replikationsstrategie bilden.

Kurzantwort: Ceph, ZFS oder iSCSI?

Inhalt

Proxmox Storage: Ceph RBD, lokales ZFS und iSCSI/LVM im Vergleich

Ceph RBD ist ein verteilter Block-Storage mit Thin Provisioning, Redundanz, Snapshots und Clones. Lokales ZFS bietet ebenfalls Snapshots und Clones, ist jedoch kein Shared Storage. Reines iSCSI stellt LUNs bereit, definiert aber keine allgemeine Speicherplatzverwaltung. Deshalb wird häufig eine große gemeinsame iSCSI-LUN mit klassischem LVM kombiniert. Weitere Details enthält die offizielle Proxmox-VE-Storage-Dokumentation.

Direktes iSCSI, iSCSI mit LVM und ZFS over iSCSI

Welche Proxmox-Funktionen hängen vom Storage ab?

Proxmox GUI versus ZFS-Kommandozeile

Die Proxmox-Oberfläche verwaltet VMs, Container, Cluster-Locks und Storage-Zuordnungen. Die ZFS-Kommandozeile administriert dagegen den darunterliegenden Pool. Beide Ebenen ergänzen sich, dürfen aber nicht miteinander verwechselt werden.

Praxisregel für Proxmox-VMs auf ZFS

Proxmox-eigene VM-Datenträger sollten nicht unkontrolliert direkt mit zfs snapshot, zfs clone, zfs rollback, zfs rename oder zfs destroy verändert werden. Proxmox kennt diese Änderungen sonst nicht. Für VM-Operationen sind deshalb Weboberfläche, API, qm, pct und pvesm die erste Wahl. Die ZFS-CLI eignet sich besonders für Poolzustand, Scrubs, Plattentausch, Kompression, Kapazitätsanalyse und geplante externe Replikation.

Automatische ZFS-Snapshots für Proxmox einrichten

Für die relevanten ZFS-Datasets und ZVOLs verwenden wir eine gestaffelte Snapshot-Aufbewahrung. Sie bietet engmaschige Wiederherstellungspunkte für aktuelle Fehler und ein gröberes Raster für ältere Stände.

Das ergibt maximal ungefähr 131 automatische Snapshots pro Dataset oder ZVOL. Durch zeitliche Überschneidungen und das Verhalten der verwendeten Snapshot-Engine kann die tatsächliche Zahl abweichen.

Wie viel Speicher benötigen ZFS-Snapshots?

Ein ZFS-Snapshot ist keine vollständige Kopie. Beim Erstellen wird lediglich ein neuer Referenzpunkt im Blockbaum angelegt. Zusätzlicher Platz wird benötigt, sobald Daten im Live-Dataset überschrieben oder gelöscht werden und der Snapshot die alten Blöcke weiterhin referenziert. Der Speicherbedarf hängt deshalb von der Änderungsrate ab, nicht allein von der Anzahl der Snapshots.

zfs list -o name,used,available,usedbysnapshots
zfs list -t snapshot -o name,creation,used
zpool list

Snapshots auf demselben Pool sind kein vollständiges Backup. Fällt der gesamte Pool aus oder wird er zerstört, sind auch seine Snapshots verloren. Für längere Aufbewahrung und getrennte Kopien verwenden wir ZFS-Replikation und Proxmox Backup Server.

ZFS-Snapshots, Rollbacks, Clones und Snapdirs erklärt

ZFS-Snapshot erstellen

zfs snapshot rpool/data@vor-update
zfs snapshot -r rpool/data@vor-update

Snapshots entstehen nahezu sofort. Ein nativer Snapshot außerhalb von Proxmox ist jedoch zunächst nur crash-konsistent. Für Datenbanken oder VMs mit mehreren Disks können QEMU Guest Agent, Freeze/Thaw oder eine anwendungsspezifische Vorbereitung erforderlich sein.

Einzelne Dateien aus einem Snapshot wiederherstellen

cp /daten/.zfs/snapshot/daily-2026-08-31/datei /daten/datei

Eine einzelne Datei zu kopieren ist meist sicherer als ein Rollback des gesamten Datasets, weil alle anderen aktuellen Änderungen erhalten bleiben.

Snapdir sichtbar machen

zfs set snapdir=visible pool/daten

snapdir gilt für ZFS-Dateisysteme. Proxmox-VM-Disks sind üblicherweise ZVOLs und besitzen kein durchsuchbares Dateiverzeichnis. Für ZVOL-Snapshot-Geräte existiert stattdessen snapdev. Siehe OpenZFS-Dokumentation zu Snapshots, Clones und Snapdir.

ZFS-Rollback

zfs rollback pool/daten@vor-update

Ein Rollback verwirft alle Änderungen nach dem gewählten Snapshot. Standardmäßig ist nur der neueste Snapshot zulässig. zfs rollback -r kann neuere Snapshots löschen; -R kann zusätzlich abhängige Clones betreffen. Vor einem Rollback sollte der aktuelle Zustand deshalb separat gesichert werden.

ZFS-Clone

zfs clone pool/daten@vor-update pool/test

Ein Clone ist eine sofort beschreibbare Kopie eines Snapshots. Anfangs teilen sich Snapshot und Clone die unveränderten Blöcke. Neue Schreibvorgänge benötigen zusätzlichen Platz. Typische Anwendungen sind Tests, Updates, Datenrettung und isolierte Kopien. Der Clone bleibt von seinem Ursprungssnapshot abhängig, bis die Beziehung gegebenenfalls mit zfs promote umgekehrt wird.

ZFS-Platte schnell ersetzen und RAIDZ erweitern

Defekte ZFS-Platte mit Replace austauschen

zpool replace tank alte-platte neue-platte
zpool status tank

ZFS rekonstruiert die benötigten Blöcke aus den verbliebenen Geräten und schreibt sie auf die neue Platte. Ist die alte Platte noch lesbar, sollte die neue möglichst zuerst angeschlossen und der Replace kontrolliert gestartet werden. So bleibt die vorhandene Redundanz länger erhalten. Bei Mirrors kann zpool replace -s eine sequenzielle Rekonstruktion starten; für RAIDZ ist diese Option nicht verfügbar. Details stehen in der OpenZFS-Referenz zu zpool replace.

RAIDZ-Expansion: RAIDZ um eine Platte erweitern

zpool attach tank raidz2-0 neue-platte

Mit aktuellen OpenZFS-Versionen kann ein bestehendes RAIDZ-vdev schrittweise um einzelne Platten verbreitert werden. Die Feature-Flag raidz_expansion muss vorhanden und aktiviert sein. Die neue Platte muss mindestens so groß wie die kleinste vorhandene Platte sein.

Weitere technische Hintergründe bietet die OpenZFS-Dokumentation zur Änderung des Pool-Layouts.

ZFS Spares, L2ARC, SLOG und Special Devices richtig einsetzen

Hot Spare

zpool add tank spare /dev/disk/by-id/...

Ein Hot Spare verkürzt die Zeit im degradierten Zustand, erhöht aber nicht die Fehlertoleranz. Ein RAIDZ2 bleibt trotz Spare ein RAIDZ2. Die ausgefallene Platte muss dauerhaft ersetzt werden.

L2ARC als ZFS-Lesecache

zpool add tank cache /dev/nvme0n1

Der primäre ZFS-Cache ist der ARC im RAM. L2ARC auf SSD oder NVMe ist nur die zweite Stufe. Er lohnt sich vor allem bei wiederkehrenden zufälligen Lesezugriffen und einem Arbeitsdatensatz, der nicht vollständig in den RAM passt. L2ARC beschleunigt keine Schreibvorgänge; mehr RAM ist häufig die bessere erste Maßnahme.

SLOG für synchrone Schreibvorgänge

zpool add tank log mirror /dev/nvme0n1 /dev/nvme1n1

Ein SLOG ist kein allgemeiner Schreibcache. Es beschleunigt nur synchrone Schreibvorgänge, etwa bei NFS, Datenbanken oder VM-Storage mit häufigem fsync(). Geeignete Geräte benötigen geringe Latenz und Power-Loss-Protection. Wichtige SLOGs sollten gespiegelt werden. sync=disabled ist kein pauschaler Tuningtrick, weil dabei zugesagte Schreibsicherheit verloren geht.

Special vdev für Metadaten und kleine Blöcke

zpool add tank special mirror /dev/nvme0n1 /dev/nvme1n1
zfs set special_small_blocks=32K tank/daten

Ein Special vdev speichert Metadaten, indirekte Blöcke, gegebenenfalls Dedup-Tabellen und optional kleine Datenblöcke dauerhaft. Es ist kein Cache. Deshalb muss es mindestens so redundant wie der normale Pool aufgebaut werden. Geht das vollständige Special vdev verloren, kann der gesamte Pool verloren sein. Siehe OpenZFS-Dokumentation zu Special vdevs.

ZFS Pull-Replikation mit bashclub zsync

zsync läuft auf dem Zielserver und holt markierte ZFS-Dateisysteme und ZVOLs über SSH von der Quelle. Das Ziel initiiert also die Replikation:

ZFS-Quelle ── SSH und zfs send ──▶ ZFS-Ziel
                    ▲
                    │
             Ziel startet Pull

Dieses Pull-Modell reduziert die Rechte der Quelle auf dem Sicherungsziel. Ein kompromittierter Proxmox-Server soll weder ältere Replikate löschen noch die Retention auf dem Ziel verändern können.

Datasets mit dem ZFS-Attribut bashclub:zsync markieren

zfs set bashclub:zsync=all rpool/data

Der Attributname kann geändert werden. Dadurch lassen sich verschiedene Replikationsziele mit unterschiedlichen Tags steuern.

Ablauf der zsync-Replikation

source=root@pve01
target=backup/repl/pve01
tag=bashclub:zsync
snapshot_filter=hourly|daily|weekly|monthly
min_keep=3
zfs_auto_snapshot_keep=14
zfs_auto_snapshot_label=zsync

Installation, Tags und Snapshot-Filter beschreibt die deutsche bashclub-zsync-Dokumentation. Das frühere GitHub-Repository verweist inzwischen auf das GitLab-Projekt.

ZFS-Replikation per Snapshot-GUID mit checkzfs.py überwachen

Eine erfolgreiche Script-Ausgabe beweist noch nicht, dass ein aktuelles und brauchbares Replikat existiert. checkzfs.py vergleicht deshalb die Snapshots auf Quelle und Ziel anhand ihrer ZFS-GUID. Gleiche Snapshot-Namen reichen als Nachweis nicht aus.

Die Prüfung kann unter anderem folgende Fehler erkennen:

Wunschalter der Replikation festlegen

threshold: 1500,2000

Im Beispiel wird nach 1.500 Minuten gewarnt und nach 2.000 Minuten ein kritischer Zustand gemeldet. Zusätzlich lassen sich maximale Snapshotzahlen, Dataset-Filter, Snapshot-Filter, SSH-Key und Servicename definieren.

source: pve01
remote: backup01
filter: rpool/data
replicafilter: backup/repl/pve01
snapshotfilter: zsync|daily|weekly|monthly
threshold: 1500,2000
maxsnapshots: 140,160
prefix: REPLICA

Die Ausgabe eignet sich unter anderem für Tabellen, JSON, CSV, E-Mail und lokale Checkmk-Checks. Der Quellcode von checkzfs.py zeigt die verfügbaren Parameter und Prüfungen.

Wichtig: Ein GUID-Vergleich bestätigt die gemeinsame Snapshot-Identität. Er ersetzt weder den regelmäßigen ZFS-Scrub noch einen getesteten Restore.

Trojanerresistentes Proxmox-Backup mit dem Miyagi-Workflow

Der Miyagi-Workflow verbindet zwei unterschiedliche Sicherungsmethoden auf einem getrennten System:

Das Ziel sind mindestens drei Datenkopien, zwei Standorte, zwei Sicherungsmethoden, automatische Kontrolle und eine möglichst kurze Netzwerk-Erreichbarkeit des Sicherungsservers.

Typischer Ablauf des Miyagi-Servers

Miyagi-Server startet
        │
        ├─ Updates und Zustandsprüfung
        ├─ ZFS-Replikation per Pull
        ├─ PBS-Backup koordinieren
        ├─ Verify, Wartung und Monitoring
        ├─ GUID und Alter der Replikate prüfen
        └─ Sicherungsserver herunterfahren

Das ZFS-Replikat kann einen schnellen Wiederanlauf ermöglichen, weil Datasets und ZVOLs bereits auf dem Ziel liegen. Das PBS-Backup bietet die längere, deduplizierte Historie, benötigt für die produktive Nutzung aber einen Restore.

Wann ist der Workflow gegen Ransomware und Trojaner widerstandsfähig?

„Trojanersicher“ ist keine einzelne Produkteigenschaft. Die Schutzwirkung entsteht durch technische Trennung und minimale Berechtigungen:

Der dokumentierte Workflow kombiniert Backups, startfähige ZFS-Replikate, Monitoring, Wartung und automatisches Herunterfahren. Die vollständige Einrichtung beschreibt die Anleitung Backup und Replikation für Proxmox VE mit dem Miyagi-Workflow.

Welche Proxmox-Storage-Lösung ist die richtige?

Häufige Fragen zu Proxmox, ZFS, Ceph und Replikation

Ist ein ZFS-Snapshot bereits ein Backup?

Nein. Ein Snapshot liegt normalerweise auf demselben ZFS-Pool wie die produktiven Daten. Er schützt gut vor versehentlichem Löschen oder unerwünschten Änderungen, aber nicht vor dem vollständigen Verlust oder der Zerstörung des Pools.

Was ist für Proxmox besser: Ceph oder ZFS?

Für einzelne Server und kleine Cluster ist lokales ZFS meist einfacher. Ceph eignet sich für mehrere Nodes, verteilten Shared Storage und hohe Verfügbarkeit ohne einzelnen Storage-Kopf. Ceph benötigt dafür mehr Hardware, Netzwerkleistung und Betriebsaufwand.

Kann Proxmox mit lokalem ZFS live migrieren?

Ja, eine laufende VM kann migriert werden. Da lokales ZFS kein Shared Storage ist, muss der VM-Datenträger dabei jedoch auf den Ziel-Node kopiert werden. Bei Ceph oder gemeinsamem iSCSI-Storage entfällt diese Storage-Kopie in der Regel.

Was ist der Unterschied zwischen ZFS-Replikation und Proxmox Backup Server?

ZFS-Replikation überträgt native Datasets, ZVOLs und Snapshots und ermöglicht dadurch einen schnellen Wiederanlauf. Proxmox Backup Server erstellt deduplizierte Backups mit längerer Historie und integriertem Restore für VMs und Container. Beide Verfahren ergänzen sich.

Warum ist Pull-Replikation sicherer als Push-Replikation?

Bei Pull-Replikation startet das Ziel die Verbindung und holt Daten von der Quelle. Die Quelle benötigt dadurch keine administrativen Rechte auf dem Sicherungsziel. Wird sie kompromittiert, kann sie ältere Ziel-Snapshots nicht ohne Weiteres löschen.

Wozu vergleicht checkzfs.py Snapshot-GUIDs?

Ein Snapshot-Name kann auf zwei Systemen identisch sein, ohne denselben Snapshot zu bezeichnen. Die GUID ermöglicht eine eindeutige Zuordnung und zeigt, ob Quelle und Ziel tatsächlich einen gemeinsamen replizierten Snapshot besitzen.

Beschleunigt ein ZFS-SLOG alle Schreibvorgänge?

Nein. Ein SLOG hilft nur bei synchronen Schreibvorgängen. Asynchrone Writes werden dadurch nicht grundsätzlich schneller. Ein geeignetes SLOG benötigt geringe Latenz und Power-Loss-Protection.

Kann der Verlust eines Special vdev den ZFS-Pool zerstören?

Ja. Ein Special vdev speichert bestimmte Blöcke dauerhaft und nicht nur als Cache. Es muss deshalb mindestens so redundant wie die normalen Daten-vdevs aufgebaut werden.

Fazit: Proxmox-Storage mit überprüfbarer Backup-Strategie

Ceph, lokales ZFS und iSCSI erfüllen unterschiedliche Aufgaben. Entscheidend ist nicht nur die Storage-Technik, sondern der vollständige Wiederherstellungsweg. Automatische ZFS-Snapshots liefern schnelle lokale Zeitpunkte, zsync erzeugt getrennte native Replikate, checkzfs.py kontrolliert deren Aktualität und der Miyagi-Workflow kombiniert ZFS-Replikation mit Proxmox Backup Server, Monitoring und zeitweiser Offline-Sicherung.

So entsteht aus einzelnen Storage-Funktionen eine mehrstufige Strategie gegen Hardwareausfälle, Fehlbedienung, spät erkannte Datenfehler und kompromittierte Produktivsysteme.