Proxmox VE: Storage mit ZFS, Ceph und Replikation
Auf einen Blick
| Gilt für | Proxmox VE 9.1 und 9.2 (ZFS 2.4, Ceph Squid 19.2 und Tentacle 20.2); Einzelserver, 2-Knoten- und 3-Knoten-Cluster |
|---|---|
| Bereich | Server-Software |
| Dauer | Planung 1–2 Stunden; Einrichtung je nach Storage 30 Minuten bis einen Tag |
| Rechte | root@pam bzw. Rolle Administrator; für Ceph Zugriff auf alle Knoten |
| Stand | Oktober 2026 |
Den passenden Storage für Proxmox VE wählen – ZFS, LVM-thin, NFS, iSCSI oder Ceph – entscheidet über Leistung, Snapshots, Replikation und Hochverfügbarkeit. Dieser Artikel vergleicht die Storage-Typen, zeigt lokalen Storage mit ZFS und LVM-thin, gemeinsamen Storage per NFS, iSCSI und Ceph sowie die ZFS-Replikation für kleine Cluster. Dazu kommen Empfehlungen zu Snapshots, Thin Provisioning und zum Begrenzen des ZFS-ARC.
Storage-Typen in Proxmox VE im Überblick
Alle Speicherziele stehen in /etc/pve/storage.cfg, die im Cluster auf alle Knoten verteilt wird. Verwaltet werden sie unter Datacenter › Storage.
| Storage | Plugin | Ebene | Gemeinsam | Snapshots | Typischer Einsatz |
|---|---|---|---|---|---|
| ZFS (lokal) | zfspool | Datei und Block | nein | ja | Standard für Einzelserver und Replikation |
| Verzeichnis | dir | Datei | nein | ja (qcow2) | ISO-Images, Vorlagen |
| LVM-Thin | lvmthin | Block | nein | ja | lokal auf Hardware-RAID |
| LVM | lvm | Block | ja, auf SAN-LUN | ja, als Volume-Chain (seit 9.0, Tech Preview) | iSCSI- oder FC-SAN |
| NFS / CIFS | nfs / cifs | Datei | ja | ja (qcow2) | NAS, ISOs, Backups |
| iSCSI | iscsi / iscsidirect | Block | ja | nein (direkt), meist mit LVM darüber | Anbindung von SAN-LUNs |
| Ceph RBD | rbd | Block | ja | ja | hyperkonvergenter Cluster ab 3 Knoten |
| CephFS | cephfs | Datei | ja | ja | ISOs, Vorlagen, Dateiablage im Ceph-Cluster |
| ZFS over iSCSI | zfs | Block | ja | ja | Speichersysteme mit ZFS und iSCSI |
| Proxmox Backup Server | pbs | Datei und Block | ja | – | ausschließlich Backups |
BTRFS ist weiterhin Tech Preview. Snapshots auf Datei-Storage nutzen das qcow2-Format; interne qcow2-Snapshots halten eine laufende VM kurz an und können bei großen Platten oder Netz-Storage dauern.
pvesm status # alle Storages mit Belegung
pvesm list local-zfs # Inhalt eines Storage
cat /etc/pve/storage.cfg # Konfiguration
Lokal: ZFS oder LVM-thin?
| Kriterium | ZFS | LVM-thin |
|---|---|---|
| Controller | HBA bzw. Controller im IT-Modus, kein Hardware-RAID | Hardware-RAID mit Cache und BBU |
| Datenintegrität | Prüfsummen, Selbstheilung bei Mirror/RAIDZ | keine eigenen Prüfsummen |
| Kompression | ja (lz4 empfohlen) | nein |
| Replikation | ja (Storage Replication) | nein |
| RAM-Bedarf | hoch (ARC), Faustregel 2 GiB + 1 GiB je TiB | gering |
Für VMs empfiehlt Proxmox bei ZFS Mirror bzw. RAID10 (gestreifte Mirrors) statt RAIDZ: Für VMs zählen IOPS mehr als Kapazität. Pools mit ashift=12 anlegen; ein zu kleiner Wert lässt sich später nicht ändern. ECC-RAM ist dringend empfohlen.
# RAID10 aus vier SSDs (Geräte über /dev/disk/by-id ansprechen)
zpool create -o ashift=12 tank \
mirror /dev/disk/by-id/nvme-A /dev/disk/by-id/nvme-B \
mirror /dev/disk/by-id/nvme-C /dev/disk/by-id/nvme-D
zfs set compression=lz4 tank
pvesm add zfspool tank-vm --pool tank --content images,rootdir --sparse 1
zpool status
Einfacher geht es in der Oberfläche unter <Knoten> › Disks › ZFS › Create: ZFS mit Add Storage.
ZFS-ARC begrenzen
ZFS nutzt freien Arbeitsspeicher als Lesecache (ARC). Bei Neuinstallationen ab Proxmox VE 8.1 begrenzt der Installer den ARC auf 10 % des RAM, höchstens 16 GiB; ältere Installationen haben keinen eigenen Grenzwert, der ARC kann dann einen großen Teil des RAM belegen und mit den VMs konkurrieren. Grenzwert dauerhaft auf 8 GiB setzen:
echo "options zfs zfs_arc_max=8589934592" > /etc/modprobe.d/zfs.conf
update-initramfs -u -k all # nötig, wenn das System auf ZFS startet
# sofort wirksam ohne Neustart:
echo 8589934592 > /sys/module/zfs/parameters/zfs_arc_max
arc_summary | head -30
Gemeinsamer Storage: NFS und iSCSI
Gemeinsamer Storage ermöglicht Live-Migration ohne Kopieren der Platten und ist Voraussetzung für Hochverfügbarkeit ohne Datenverlust.
NFS ist der einfachste Weg zu einem vorhandenen NAS:
pvesm add nfs nas01 --server 10.10.40.20 --export /mnt/pool/pve \
--content images,iso,vztmpl,backup
VM-Disks liegen dort als qcow2-Dateien (Snapshots möglich). Das NAS wird damit zum Single Point of Failure – für HA sollte es selbst redundant sein.
iSCSI und Fibre Channel: Eine LUN wird unter Datacenter › Storage › Add › iSCSI eingebunden (Use LUNs directly aus) und darauf ein LVM-Storage mit Option Shared angelegt. Proxmox teilt die LUN dann in logische Volumes je VM-Disk. Bei mehreren Pfaden zum SAN ist Multipathing einzurichten. Seit Proxmox VE 9.0 sind auf solchem LVM Snapshots als Volume-Chains möglich (Tech Preview; gilt nur für neu angelegte Disks). Klassisches LVM-thin ist dagegen nicht clusterfähig.
Ceph: hyperkonvergenter Storage im Cluster
Mit Ceph stellen die Proxmox-Knoten selbst einen verteilten, gemeinsamen Storage bereit (Hyperkonvergente Infrastruktur). Proxmox VE 9.2 installiert bei neuen Clustern standardmäßig Ceph Tentacle 20.2; Squid 19.2.3 ist weiter verfügbar, bestehende Cluster bleiben auf ihrer Version.
Mindestanforderungen laut Proxmox-Dokumentation:
- mindestens drei möglichst gleiche Knoten; drei Monitore für das Quorum;
- ein Netz mit mindestens 10 Gbit/s exklusiv für Ceph; bei NVMe-Systemen mindestens 25 Gbit/s für den Cluster-Verkehr, dazu Corosync auf eigenem 1-Gbit/s-Netz. Bei drei bis fünf Knoten ohne passenden Switch ist ein vollvermaschtes Netz (Full Mesh) möglich;
- je OSD mindestens 8 GiB RAM und einen CPU-Kern bzw. Thread (NVMe-OSDs eher vier bis sechs);
- eine OSD pro Platte, gleich große Platten gleichmäßig verteilt, im kleinen Cluster SSDs statt HDDs; kein RAID-Controller, sondern HBA.
Einrichtung über <Knoten> › Ceph (Assistent) oder per Kommandozeile:
pveceph install # auf jedem Knoten (Version wählbar)
pveceph init --network 10.10.50.0/24 # einmalig
pveceph mon create # auf drei Knoten
pveceph mgr create # mindestens zwei Knoten
pveceph osd create /dev/nvme1n1 # je Datenplatte
pveceph pool create vmpool --add_storages # Pool mit size 3 / min_size 2
ceph -s # Status: HEALTH_OK
Ein neuer Pool hat standardmäßig size 3 (drei Kopien) und min_size 2: Fällt ein Knoten aus, läuft alles weiter. min_size 1 niemals setzen – das kann zu Datenverlust führen. Von der Rohkapazität bleibt bei drei Kopien gut ein Drittel nutzbar; Ceph sollte zudem nie über etwa 80 % gefüllt werden, damit nach einem Ausfall Platz für die Wiederherstellung bleibt. Platzsparender ist Erasure Coding, für VM-Disks im kleinen Cluster aber meist die schlechtere Wahl.
ZFS-Replikation für 2-Knoten-Cluster
Für zwei Server ohne gemeinsamen Storage ist die Storage Replication (Proxmox-Replikation) die wirtschaftliche Lösung: Proxmox überträgt ZFS-Snapshots der VM-Disks zeitgesteuert auf den zweiten Knoten. Voraussetzungen: lokaler ZFS-Storage mit gleicher Storage-ID auf beiden Knoten und ein Cluster.
- Einrichtung: VM › Replication › Add, Ziel-Knoten und Zeitplan wählen. Standard ist alle 15 Minuten, möglich ist minütlich bis wöchentlich, optional mit Bandbreitenlimit.
- Bei einer Migration auf den Zielknoten werden nur die Änderungen seit der letzten Replikation übertragen; die Richtung kehrt sich automatisch um.
- Mit HA kombinierbar – aber bei einem Ausfall gehen die Daten seit dem letzten Lauf verloren.
pvesr create-local-job 100-0 pve2 --schedule "*/5" --rate 50 # alle 5 Min., Limit 50 MB/s
pvesr status
Ein Cluster aus zwei Knoten braucht für ein stabiles Quorum zusätzlich ein QDevice als dritte Stimme, siehe Proxmox VE: Cluster und Hochverfügbarkeit.
Snapshots und Thin Provisioning
- Thin Provisioning: Eine 100-GB-Disk belegt nur den tatsächlich geschriebenen Platz. Damit freigegebener Platz zurückkommt, an der VM-Disk Discard aktivieren und im Gast TRIM nutzen (unter Linux
fstrim, unter Windows automatisch). Achtung: Läuft ein thin belegter Storage voll, erhalten alle VMs darauf I/O-Fehler. Überbuchung überwachen, etwa mit Zabbix. - Snapshots sind für kurzfristige Rücksprünge gedacht (vor Updates), nicht als Backup. Viele oder alte Snapshots kosten Platz und auf qcow2 Leistung. Backups gehören auf den Proxmox Backup Server.
- Snapshots mit vTPM: seit 9.1 auch auf Datei-Storage, weil der TPM-State als qcow2 abgelegt werden kann, siehe Proxmox VE: Windows-VMs mit VirtIO, TPM und Secure Boot.
Hinweise
- Entscheidungshilfe: Einzelserver – ZFS-Mirror. Zwei Knoten – ZFS mit Replikation plus QDevice. Drei oder mehr Knoten mit 10/25-GbE – Ceph. Vorhandenes SAN – iSCSI/FC mit Shared LVM.
- Platten: Für ZFS und Ceph Enterprise-SSDs mit Power-Loss-Protection verwenden; Consumer-SSDs brechen bei synchronen Schreibzugriffen stark ein.
- Bei Auswahl, Dimensionierung und Aufbau von ZFS- und Ceph-Umgebungen unterstützen Sie die Proxmox-Leistungen von m.a.x. it.
Siehe auch
- Proxmox im Unternehmen – Überblick und alle Artikel der Reihe
- Proxmox VE: Cluster und Hochverfügbarkeit
- Proxmox VE: Netzwerk mit Bridges, VLANs, Bonds und SDN
- Proxmox Backup Server: Einrichtung und Backup-Strategie
- Proxmox VE: Windows-VMs mit VirtIO, TPM und Secure Boot
Links und Quellen
Über m.a.x. it Die m.a.x. Informationstechnologie AG ist seit über 30 Jahren IT-Partner mittelständischer und großer Unternehmen in München und bietet maßgeschneiderte Lösungen und Services in den Bereichen Cloud, Cybersecurity, Netzwerk, Windows, Linux und Softwareentwicklung. Sie haben eine Frage zu diesem Artikel oder brauchen Unterstützung?
