Proxmox 9.1 und Shared Storage mit iSCSI und LVM-Snapshots

M

Manaburner

New Member
Nov 25, 2025
8
1
3
Hallo zusammen,

wir planen eine Migration von vSphere nach Proxmox und haben als neue Umgebung Folgendes aufgebaut:

- Proxmox Cluster mit 3 Nodes in Version 8.4
- Shared Storage Dorado OceanStore All Flash über iSCSI angebunden und LVM Volumes
- geplantes Backup Tool Veeam

Bei meiner Recherche habe ich herausgefunden, dass Proxmox in v8 keine Snapshots mit LVM Volumes unterstützt. Version 9.x soll das wohl können, aber es ist aktuell nur eine Tech Preview, wobei ich hier keine belastbare Aussage finden konnte, ob das noch mit der 9.1. gilt. Auch las ich von Data Corruption und sehr langen Laufzeiten, wenn es um das Auflösen der Snapshots geht (letzteres ist aber anscheinend in 9.1 repariert).

Haltet Ihr Proxmox 9.1 in unserer Konstellation für Production-ready oder sollten wir lieber noch auf eine 9.2 (oder später) warten, bis LVM Snapshots sauber funktionieren?

Vielen Dank :)
 
Hallo @Manaburner,

Das Feature "Snapshots as volume chains" für LVM ist auch in PVE 9.1 weiterhin als Technology Preview markiert. Es ist für den produktiven Einsatz nicht empfohlen, da es noch bekannte Probleme gibt (z. B. extrem langsame Laufzeiten beim Löschen/Wipen von Disks mit Snapshots).
Für Production-Stability: Entweder bei Shared-LVM ohne Snapshots bleiben oder auf Storage-Backends wechseln, die das nativ unterstützen (Ceph, ZFS-over-iSCSI, NFS/qcow2).
 
  • Like
Reactions: Johannes S and Manaburner
Manaburner said:
Hallo zusammen,

wir planen eine Migration von vSphere nach Proxmox und haben als neue Umgebung Folgendes aufgebaut:

- Proxmox Cluster mit 3 Nodes in Version 8.4
- Shared Storage Dorado OceanStore All Flash über iSCSI angebunden und LVM Volumes
- geplantes Backup Tool Veeam

Bei meiner Recherche habe ich herausgefunden, dass Proxmox in v8 keine Snapshots mit LVM Volumes unterstützt. Version 9.x soll das wohl können, aber es ist aktuell nur eine Tech Preview, wobei ich hier keine belastbare Aussage finden konnte, ob das noch mit der 9.1. gilt. Auch las ich von Data Corruption und sehr langen Laufzeiten, wenn es um das Auflösen der Snapshots geht (letzteres ist aber anscheinend in 9.1 repariert).

Haltet Ihr Proxmox 9.1 in unserer Konstellation für Production-ready oder sollten wir lieber noch auf eine 9.2 (oder später) warten, bis LVM Snapshots sauber funktionieren?

Vielen Dank :)
Click to expand...
Warum willst du auf das Snapshot Feature warten? Veeam kann wie der PBS von jedem Storage, egal ob es Snapshots unterstützt, Snapshot Backups machen. Veeam nutzt da einen meiner Meinung nach nicht so eleganten Weg wie der PBS, aber funktioniert und das auch schon mit PVE8.
 
  • Like
Reactions: Johannes S
Falk R. said:
Warum willst du auf das Snapshot Feature warten? Veeam kann wie der PBS von jedem Storage, egal ob es Snapshots unterstützt, Snapshot Backups machen. Veeam nutzt da einen meiner Meinung nach nicht so eleganten Weg wie der PBS, aber funktioniert und das auch schon mit PVE8.
Click to expand...
Vielleicht bin ich VMware-versaut, aber soweit mir bekannt, wird bei Backup einer laufenden VM ein Snapshot gemacht, die virtuelle Platte wird abgezogen, während die Quell-VM weiterlaufen kann und dann wird der Snapshot aufgelöst.
Dass der Storage einen Snapshot kann ist gut, aber der muss ja irgendwie konsistent sein, sodass der Hypervisor auch was davon weiss.
Macht Proxmox hier etwas anders als VMware?
Und die Aussage "egal ob es Snapshots unterstützt" irritiert mich etwas. Der Storage sollte schon Snapshots können, wenn ich sowas nutzen will.
 
Manaburner said:
Vielleicht bin ich VMware-versaut, aber soweit mir bekannt, wird bei Backup einer laufenden VM ein Snapshot gemacht, die virtuelle Platte wird abgezogen, während die Quell-VM weiterlaufen kann und dann wird der Snapshot aufgelöst.
Dass der Storage einen Snapshot kann ist gut, aber der muss ja irgendwie konsistent sein, sodass der Hypervisor auch was davon weiss.
Macht Proxmox hier etwas anders als VMware?
Und die Aussage "egal ob es Snapshots unterstützt" irritiert mich etwas. Der Storage sollte schon Snapshots können, wenn ich sowas nutzen will.
Click to expand...
Du bist es nur einfach gewohnt, dass da immer ein Dateisystem dazwischen sitzt, wo du Snapshotdateien ablegen kannst/musst.
Um ein Snapshot Backup zu machen muss das Storage kein Snapshot unterstützen. Fürs Backup wir der Snapshot im qemu Layer gemacht. Das ganze kann man in der Doku nachlesen und wurde auch schon oft im Forum detailliert beschrieben.
Also löse dich von der alten Denke mit massiv Abhängigkeiten, oder frage direkt deinen Dienstleiter deiner Wahl. Der richtet das dann auch optimal ein.
 
  • Like
Reactions: Johannes S
Um das technisch zu untermauern: Proxmox verwendet für das Backup QEMU-seitige dirty-bitmaps. Der Hypervisor trackt geänderte Blöcke im Arbeitsspeicher, völlig unabhängig vom darunterliegenden Storage.

Dein OceanStore muss also gar keine Snapshots können, damit Veeam konsistente Backups ziehen kann. Die von dir genannte "Tech Preview" bezieht sich auf Storage-basierte Snapshots für Rollbacks (z. B. "Revert to Snapshot"), was für deine Backup-Strategie aber nicht relevant ist.
 
  • Like
Reactions: Johannes S
@Bu66as und @Falk R. liegen im Allgemeinen richtig mit ihrer Beschreibung der PBS-Funktionalität (vorausgesetzt, meine Browserübersetzung ist einigermaßen genau).

Es gibt jedoch einige technische Punkte, die eine Klarstellung verdienen:
  • Storage-Snapshot: Die Fähigkeit eines Speichersystems (mit oder ohne Dateisystem), schnelle und effiziente Snapshots unabhängig vom Client-Betriebssystem zu erstellen.
  • PVE Backup-Snapshot (wie im Backup-Assistenten GUI sichtbar): Ein Aufruf von "guest-fs-freeze/thaw/unfreeze"-Befehlen über den QEMU-Guest, um eine konsistente Sicht auf die Festplatte zu erhalten.
  • QEMU Dirty-Bit-Integration mit PVE/PBS-Backups basiert auf der Möglichkeit, geänderte/ändernde Blöcke nachzuverfolgen. Wenn ein Schreibvorgang auf einen Block erfolgt, der noch nicht gesichert wurde, wird dieser Schreibvorgang gehalten, bis der Block asynchron an den Backup-Server gesendet wird. Ist der Backup-Server/die Verbindung/das Verfahren langsam, kann dies ernsthafte Auswirkungen auf den Schreibvorgang/Client haben.
  • Fleecing-Storage-Funktion wurde entwickelt, um den oben genannten Mangel auszugleichen. Sie ermöglicht, dass alte Daten auf einen temporären, schnellen lokalen Speicher kopiert werden, bevor der Schreibvorgang abgeschlossen wird. Der alte Block wird später vom Fleecing-Speicher gesichert.
  • PVE9 QEMU LVM Snapshots: Neue Tech-Preview-Funktionalität, die QCOW2-Snapshots direkt über LVM-Blockgeräte legt. Diese sind Snapshots auf Storage-Ebene und integrieren sich nicht in den Backup-Workflow.
Veeam und einige andere Backup-Produkte können Snapshots/Klone direkt auf Storage-Ebene bei bestimmten Storage-Produkten nutzen und lokal sichern. PVE/PBS ist speicherunabhängig. Vorteile der Snapshot/Klon-Methode:

a) Sie reduziert den Netzwerk-Datentransfer.
b) Sie entfernt vollständig die CPU-/Datenverarbeitungsanforderungen vom produktiven Hypervisor.
c) Sie vermeidet mögliche QEMU-Prozesskorruption: https://forum.proxmox.com/threads/data-lost-for-time-window.171779/#post-800416


Jetzt, da Sie mit diesem Wissen ausgestattet sind, liegt die Entscheidung, welchen Weg Sie einschlagen, vollständig bei Ihnen.


Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox
 
  • Like
Reactions: bl1mp and Johannes S
Das ganze stimmt, bis auf die Storage Snapshots von Veeam. Das geht nur mit vSphere und keinem anderen Hypervisor. Das Feature ist beim Restore vom VMware VDDK abhängig.
Beim derzeitigen Stand der Technik ist man mit einem vernünftig konfigurierten PBS am besten aufgestellt. Wer einen langsamen PBS nutzen möchte, sollte Fleecing SSDs einplanen.
 
  • Like
Reactions: Johannes S
Falk R. said:
Das ganze stimmt, bis auf die Storage Snapshots von Veeam. Das geht nur mit vSphere und keinem anderen Hypervisor.
Click to expand...
Ich habe mich möglicherweise unklar ausgedrückt bzw. falsch übersetzt. Ich wollte nicht andeuten, dass diese Funktion für etwas anderes als ESXi verfügbar ist. Veeam würde eine ähnliche Möglichkeit für PVE sicherlich begrüßen, aber das ist keine Option.

Mein Punkt war lediglich, dass Veeam und einige ähnliche Backup-Produkte diese Funktionalität für VMware anbieten.

Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox
 
  • Like
Reactions: bl1mp, Johannes S and Falk R.
Bu66as said:
Die von dir genannte "Tech Preview" bezieht sich auf Storage-basierte Snapshots für Rollbacks (z. B. "Revert to Snapshot"), was für deine Backup-Strategie aber nicht relevant ist.
Click to expand...
Jetzt muss ich nochmal doof nachfragen, sorry. Backups sollten also funktionieren, aber ein On-Demand-Snapshot einer VM, z.B. vor einem OS-Update, würde dann nach wie vor nicht gehen richtig?

Weitere, doofe Anschlussfrage: Hier wird im Wizard beim Deployment des Veeam Plugins verlangt, einen Storage anzugeben, der verwendet werden soll, wenn der Original-VM-Storage keine Snapshots unterstützt (was bei uns der Fall wäre): https://helpcenter.veeam.com/docs/vbproxmoxve/userguide/server_add_storage.html?ver=3

Das hiesse, ich müsste entweder lokal auf jedem Cluster Node oder über eine weitere Storage LUN allen drei Cluster Nodes Storage vom Typ "Directory" bereitstellen, damit dort temporär die Snapshots abgelegt werden können, bis Veeam diese auf das Backu Repo kopiert hat oder verstehe ich das falsch?
 
Manaburner said:
Jetzt muss ich nochmal doof nachfragen, sorry. Backups sollten also funktionieren, aber ein On-Demand-Snapshot einer VM, z.B. vor einem OS-Update, würde dann nach wie vor nicht gehen richtig?
Click to expand...
Deshalb nutze ich immer den PBS und mache einfach Snapshot Backups vor Updates, statt Snapshots. So ein Backup kann man auch gern länger leigen lassen als man es mit einem Snapshot tun sollte.
Manaburner said:
Weitere, doofe Anschlussfrage: Hier wird im Wizard beim Deployment des Veeam Plugins verlangt, einen Storage anzugeben, der verwendet werden soll, wenn der Original-VM-Storage keine Snapshots unterstützt (was bei uns der Fall wäre): https://helpcenter.veeam.com/docs/vbproxmoxve/userguide/server_add_storage.html?ver=3
Click to expand...
Veeam macht da etwas eigenes, was ich nicht so Charmant finde. Daher sollte dann die OS Disk etwas größer sein oder einen extra lokalen Datastore für Veeam einplanen.
Manaburner said:
Das hiesse, ich müsste entweder lokal auf jedem Cluster Node oder über eine weitere Storage LUN allen drei Cluster Nodes Storage vom Typ "Directory" bereitstellen, damit dort temporär die Snapshots abgelegt werden können, bis Veeam diese auf das Backu Repo kopiert hat oder verstehe ich das falsch?
Click to expand...
Was Veeam genau im Hintergrund macht, ist nicht dokumentiert und lässt sich schwer nachvollziehen, aber vermutlich so wie du es beschreibst.
 
  • Like
Reactions: Johannes S
Falk R. said:
Deshalb nutze ich immer den PBS und mache einfach Snapshot Backups vor Updates, statt Snapshots. So ein Backup kann man auch gern länger leigen lassen als man es mit einem Snapshot tun sollte.

Veeam macht da etwas eigenes, was ich nicht so Charmant finde. Daher sollte dann die OS Disk etwas größer sein oder einen extra lokalen Datastore für Veeam einplanen.

Was Veeam genau im Hintergrund macht, ist nicht dokumentiert und lässt sich schwer nachvollziehen, aber vermutlich so wie du es beschreibst.
Click to expand...
Danke Dir
 
@Manaburner,

korrekt, VM-Snapshots (mit RAM/State) sind unter Shared-LVM technisch nicht möglich.

Zu Veeam: Ja, deine Annahme stimmt. Da der Storage in dieser Konfiguration keine Snapshots liefert, benötigt der Veeam-Worker zwingend einen Staging-Bereich. Du musst dafür einen Directory-Storage (lokal je Node oder shared) bereitstellen.
 
  • Like
Reactions: Manaburner
Bu66as said:
@Manaburner,

korrekt, VM-Snapshots (mit RAM/State) sind unter Shared-LVM technisch nicht möglich.

Zu Veeam: Ja, deine Annahme stimmt. Da der Storage in dieser Konfiguration keine Snapshots liefert, benötigt der Veeam-Worker zwingend einen Staging-Bereich. Du musst dafür einen Directory-Storage (lokal je Node oder shared) bereitstellen.
Click to expand...
Vielen Dank :)
 
You must log in or register to reply here.
Top Bottom