Veeam & Proxmox bei Shared Storage via FC

A

Ahtse

New Member
Feb 24, 2026
3
0
1
Hallo zusammen,

ich würde gerne ein Proxmox Cluster mit einem IBM Flashsystem via FC bereitstellen. Da werden dann thick-LVM Volumes provisioniert damit wir die Volumes in Proxmox auf alle Server teilen können für unseren HA. Bei der Einrichtung mit Multipath und so ist auch alles klar, da habe ich genug Posts gefunden.

Jetzt habe ich nur ein Problem, wir machen das Backup via Veeam und ich verstehe nicht ganz wie dann die Snapshots die Veeam benötigt funktionieren. Muss ich da dann Volume Chain Snaps auf den LVM Volumes aktivieren und eine 1TB VM ist dann mit dem Snap 2TB groß? Kann ich die Snaps einfach auf ein dafür dediziertes NAS auslagern? Oder übersehe ich hier etwas komplett?
 
Für Veeam musst Du keine Snapshots auf dem LVM-Storage aktiveren, die VM Disks können auch im raw-Format vorliegen (also ohne Snapshot-Funktion, wie bei qcow2).
Veeam macht bei der Proxmox Sicherung keine "klassischen" Snapshots wie man das aus der vmware-Sicherung mit Veeam kennt
 
  • Like
Reactions: Ahtse
Ah, ok jetzt hab ichs verstanden - danke.

Ich kann die VMs in raw bereitstellen wenn ich keine Snapshot Funktionalität oder andere Features von qcow2 benötige. Veeam nutzt dann bei Backups copy on write, und das Feature wird von Proxmox bereitgestellt.
 
Ich weiß nicht, wie Veeam arbeitet, bei ProxmoxVEs eigenen Mechanismus für VMs wird ein Feature von qemu (den eigentlichen Hypervisor) genutzt, bei dem der aktuelle Zustand der VM zwischengespeichert wird und dass dann gesichert. Das funktioniert unabhängig vom verwendeten Storage und benötigt daher keinen Snapshotsupport im Storage. Zusammen mit dem live-restore-Feature des ProxmoxBackupServers kann man damit den typischen "Snapshot vor Upgrade des VM-Systems zwecks schnellen Rollback"-Usecase gut abbilden: Vor dem Upgrade ein Backup machen, nach Upgrade testen. Ist alles gut, Backup löschen, sonst mit live-restore alten Stand starten und über (bei Performanceeinschränkungen) kurze Downtime freuen.

Es kann durchaus sein, dass Veeam damit auch arbeitet, das erklärt aber nicht, warum sie eigene Worker-VMs benötigen, @LnxBil hat im englischen Forum erwähnt, dass er sich die Funktionsweise des Veeam-Supports für ProxmoxVE mal angeschaut hat, vielleicht kann er mehr dazu sagen?

Was man generell bedenken sollte: Hier im Forum haben diverse Leute von Problemen mit den Proxmoxsupport von Veeam berichtet, ich habe daher den Eindruck, dass Veeam Proxmoxunterstützung eher den Status einer public beta hat.

Wenn ihr eh (ich vermute mal aus Kostengründen) euren Hypervisor wechselt, wäre darum in meinen Augen auch angebracht Alternativen beim Backup zu evaluieren, der ProxmoxBackupServer ist sehr gut integriert. Er bietet allerdings keine Unterstüzung (und die ist auch nicht geplant, soweit ich weiß) für application-aware Backups, wie Veeam sie für Domänencontroller oder MS SQL-Datenbanken hat. Ein möglicher Workaround ist es dafür den Veeam-Agent innerhalb der jeweiligen VM zu nutzen (die VM also wie einen baremetal-Server zu behandeln) und die VM-Backups dann mit Proxmox nativen Funktionen auf einen ProxmoxBackupServer zu machen. Ich habe damit selbst keine Erfahrungen, aber ein derartiges Setup wurde hier im Forum schon öfter beschrieben und kann (wenn man mit der Minimalsubskription von Veeam für die Minimalzahl agenten auskommt) in Verbund mit einer Subskription für den ProxmoxBackupServer noch Geld sparen in Vergleich zu einer vollen Veeam-Subskription.

Alle Angaben basieren auf hier angelesenen Halbwissen ohne Gewähr, da ich keine eigene Erfahrung mit Veeam habe.
 
  • Like
Reactions: Ahtse
Entscheident ist tatsächlich nur wo der Veeam Worker liegt, also auf welchem Storage (falls auf dem Proxmox Cluster).
Dieses Storage muss SnapShots unterstützt.
:)
 
  • Like
Reactions: Ahtse
Die Backups mit dem PBS sind soweit schon "application aware", wenn der qemu-guest-agent auf den VM's installiert ist, weil ja - wie Du schon geschrieben hast - ein freeze mit dem qemu-agent ausgeführt wird und somit in der "Luft" befindliche Daten auf die Platten geschrieben werden.
Application aware wäre hier für mich also: das Backup hat einen "konsistenten" Zustand.

Was mit dem PBS nicht passiert, was man aber von Veeam kennt, der PBS greift nicht in die Maschine ein und sagt den Applikationen "ich hab dich jetzt gesichert, du kannst z.B. deine transaction logs wegwerfen" - Dies ist z.B. bei on premise Exchange Servern oder MSSQL-Servern wichtig, weil man sich ansonsten um die Bereinigung der transaction logs selbst kümmern muss.

Soweit ich das mit Veeam verstanden habe, schiebt der veeam worker den "Agenten" auf die zu sichernde VM und kümmert sich um das "Application Aware" - der qemu-guest-agent wird hier nicht verwendet (habe ich in einem anderen Thread von Falk R. gelernt).

Ich sichere hier mit dem PBS und Veeam 13. Der Hauptgrund warum ich überhaupt noch Veeam habe, ist der oben schon erwähnte Exchange und DB-Server. Der Item-Restore bei Veeam ist wirklich nice, wenn es darum geht z.B. einzelne E-Mails wieder zurückzuholen. Ansonsten würde mir der PBS völlig ausreichen und es ist auch wesentlich schöner Backups an andere Orte zu bekommen mit zusätzlichen PBS-Maschinen.
Zur Fairness muss ich noch sagen, dass ich hier mit Veeam keine Probleme habe - so geschmeidig wie die Sicherungen ohne retries laufen, kenne ich das mit vmware nicht. Da hatte ich sehr häufig retries in den Backups und auch hin und wieder nicht gelöschte veeam Snapshots der Maschinen.
 
Last edited:
  • Like
Reactions: Ahtse and Johannes S
Hallo @Ahtse,

die Kernfrage ist schon gut beantwortet — für die VM-Disks auf eurem shared LVM via FC braucht ihr keine Snapshot-Funktionalität, raw reicht. Veeam nutzt für die Sicherung den QEMU Dirty Bitmap Mechanismus (CBT), keine Storage-Level-Snapshots.

Was @Medo-Luki angesprochen hat, ist für euer Setup aber der entscheidende Punkt: Die Veeam Worker VM selbst braucht ein Storage mit Snapshot-Support (qcow2). Auf eurem thick-LVM über FC geht das nicht. Ihr braucht dafür also ein separates Storage — z.B. lokales LVM-Thin oder ein NFS/CIFS-Share, auf dem qcow2-Images liegen können. Das solltet ihr bei der Planung direkt berücksichtigen.

Unabhängig davon: Wenn ihr ohnehin neu aufbaut, schaut euch den Proxmox Backup Server als Alternative oder Ergänzung an. Die Integration ist nativ, performant und gerade bei SAN-Setups deutlich unkomplizierter als Veeam. Wie @aL1aL7 schon geschrieben hat — für application-aware Szenarien (Exchange, MSSQL) kann man den Veeam Agent innerhalb der betroffenen VMs nutzen und den Rest über PBS abdecken.

Falls ihr bei der Planung oder Umsetzung des FC-Clusters Unterstützung braucht: Wir bei B1 Systems sind offizieller Proxmox-Partner und machen genau solche Setups regelmäßig.
 
  • Like
Reactions: Ahtse and Johannes S
Und noch eine Ergänzung: Bei MS SQL Servern unterstützt Veeam auch das Backup von Clustern, bei anderen Datenbankengines (Postgres, MySQL/mariadb) nicht. Das wäre für mich ein Grund auf Veeams application-aware Backups zu Gunsten von datenbankspezifischen Tools zu verzichten.
 
  • Like
Reactions: Ahtse, aL1aL7 and Bu66as
Bu66as said:
Hallo @Ahtse,

die Kernfrage ist schon gut beantwortet — für die VM-Disks auf eurem shared LVM via FC braucht ihr keine Snapshot-Funktionalität, raw reicht. Veeam nutzt für die Sicherung den QEMU Dirty Bitmap Mechanismus (CBT), keine Storage-Level-Snapshots.

Was @Medo-Luki angesprochen hat, ist für euer Setup aber der entscheidende Punkt: Die Veeam Worker VM selbst braucht ein Storage mit Snapshot-Support (qcow2). Auf eurem thick-LVM über FC geht das nicht. Ihr braucht dafür also ein separates Storage — z.B. lokales LVM-Thin oder ein NFS/CIFS-Share, auf dem qcow2-Images liegen können. Das solltet ihr bei der Planung direkt berücksichtigen.

Unabhängig davon: Wenn ihr ohnehin neu aufbaut, schaut euch den Proxmox Backup Server als Alternative oder Ergänzung an. Die Integration ist nativ, performant und gerade bei SAN-Setups deutlich unkomplizierter als Veeam. Wie @aL1aL7 schon geschrieben hat — für application-aware Szenarien (Exchange, MSSQL) kann man den Veeam Agent innerhalb der betroffenen VMs nutzen und den Rest über PBS abdecken.

Falls ihr bei der Planung oder Umsetzung des FC-Clusters Unterstützung braucht: Wir bei B1 Systems sind offizieller Proxmox-Partner und machen genau solche Setups regelmäßig.
Click to expand...
Hi @Bu66as - kann ich auf dem thick-LVM nicht Volume Chain Snaps aktivieren und die Veeam VM da mit qcow2 drauf legen und die anderen VMs einfach in raw?

Weißt du warum die Veeam VM das benötigt? Nur für sich selber oder wird da Platz abhängig von den zu sichernden VMs benötigt?

Veeam ist als Backup Lösung gesetzt, eine Migration auf den PBS ist erstmal nicht vorgesehen.
 
@Ahtse,

nein, das geht so nicht. Ein LVM-Storage (thick) in Proxmox unterstützt ausschließlich das raw-Format — qcow2 ist dort nicht möglich, unabhängig von irgendwelchen Einstellungen. Das ist eine Limitation des Storage-Typs in Proxmox, nicht der einzelnen VM.

Für die Worker VM braucht ihr ein Storage, das qcow2 bzw. Snapshots unterstützt, z.B.:
  • Lokales LVM-Thin auf den Nodes
  • NFS- oder CIFS-Share
  • Directory-Storage

Zum Warum: Veeam nutzt Snapshots der Worker VM für das interne Lifecycle-Management des Workers während des Backup-Prozesses. Der Platzbedarf richtet sich dabei nach der Worker VM selbst (Snapshot-Delta), nicht nach der Größe der zu sichernden VMs. Die eigentlichen Backup-Daten fließen durch den Worker hindurch zum Veeam Repository — dafür wird kein Platz auf dem Worker-Storage benötigt.

Ein lokales LVM-Thin auf jedem Node ist dafür die pragmatischste Lösung — das habt ihr vermutlich ohnehin schon für ISO-Images o.ä. und der Overhead für die Worker VM ist minimal.
 
  • Like
Reactions: Ahtse and Johannes S
LVM-Storage (thick) unterstützt doch seit PVE 9.X Snapshots wenn als Disk-Format qcow2 gewählt wird - oder stehe ich jetzt kpl. am Schlauch

@Ahtse

Du musst doch in deinem Host eine HDD drin haben, das OS kann ja nicht von FC starten - ist da kein Platz für den veeam wokrer?
 
  • Like
Reactions: Ahtse
Bu66as said:
Ein LVM-Storage (thick) in Proxmox unterstützt ausschließlich das raw-Format — qcow2 ist dort nicht möglich, unabhängig von irgendwelchen Einstellungen. Das ist eine Limitation des Storage-Typs in Proxmox, nicht der einzelnen VM.
Click to expand...
Strenggenommen ist es so, dass beim Snapshot as volume-chain Format die Daten intern als qcow2 gespeichert werden, das wird eben nur für genau den Usecase genommen. Für Veeam hilft das nicht ;)

Und danke für die Erklärung der Rolle der worker-vm, ich kann mir nicht helfen, aber das klingt für mich nach einer sehr abenteuerlichen Architektur, wie kommt man auf sowas und vor allen, warum macht man das?!?
 
  • Like
Reactions: Ahtse
@aL1aL7, stimmt, da war ich gerade wo anderster. Seit PVE 9 unterstützt thick LVM über Volume-Chain-Snapshots tatsächlich qcow2 mit Snapshot-Funktionalität.

@Ahtse, damit ist deine ursprüngliche Idee prinzipiell nicht falsch: Volume Chain Snaps auf dem thick LVM aktivieren und die Worker VM dort als qcow2 anlegen sollte funktionieren, da Proxmox dem Storage dann Snapshot-Fähigkeit attestiert und Veeam das über die API prüft. Ich würde das aber explizit testen, bevor ihr euch darauf verlasst — die Veeam-Proxmox-Integration ist noch relativ jung und nicht jede Storage-Kombination ist ausgiebig erprobt.

Der pragmatischere Weg bleibt wie @aL1aL7 schon angemerkt hat: Ihr habt auf den Nodes lokale Platten fürs OS — ein kleines LVM-Thin oder Directory-Storage dort ist für die Worker VM absolut ausreichend und ihr müsst euch nicht auf die Volume-Chain-Snapshots verlassen.

@Johannes S, zur Worker-Architektur: Das ist ein Überbleibsel aus der VMware-Welt. Dort fungierte der „Proxy" als Vermittler zwischen vSphere API und Repository (VADP/HotAdd/NBD). Bei Proxmox hat Veeam das Konzept übernommen — der Worker wird pro Backup-Job auf dem jeweiligen Node deployt, liest die Daten über QEMU und schiebt sie ans Repository. Der Vorteil ist, dass Veeam damit Storage-agnostisch arbeiten kann, ohne tief in die jeweilige Storage-Schicht eingreifen zu müssen. Elegant ist anders, aber es entkoppelt Veeam von den Storage-Interna des Hypervisors.
 
  • Like
Reactions: Ahtse and Johannes S
Bu66as said:
damit ist deine ursprüngliche Idee prinzipiell nicht falsch: Volume Chain Snaps auf dem thick LVM aktivieren und die Worker VM dort als qcow2 anlegen sollte funktionieren, da Proxmox dem Storage dann Snapshot-Fähigkeit attestiert und Veeam das über die API prüft. Ich würde das aber explizit testen, bevor ihr euch darauf verlasst — die Veeam-Proxmox-Integration ist noch relativ jung und nicht jede Storage-Kombination ist ausgiebig erprobt.
Click to expand...

Sie hat außerdem eine schlechtere Performance zur Folge, das muss man also benchmarken und dann schauen, ob es das einen wert ist:
https://kb.blockbridge.com/technote/proxmox-qcow-snapshots-on-lvm/index.html
Und ein grundsätzliches Problem (ganz unabhängig vom aktuellen Feature):
bbgeek17

[TUTORIAL] Thread 'Understanding QCOW2 Risks with QEMU cache=none in Proxmox'

Hey everyone,

A few recent developments prompted us to examine QCOW2’s behavior and reliability characteristics more closely:

1. Community feedback
  • There are various community discussions questioning the reliability of QCOW2. We have customers (predating our native integration) interested in using QCOW on LVM.
2. Integrity testing failures with QCOW/LVM snapshots
  • When we ran our data integrity tests against the tech preview of QCOW2/LVM snapshots, we observed consistent failures starting immediately after the first snapshot was taken.
3. Confusing...
  • Like
 
  • Like
Reactions: Ahtse, aL1aL7 and Bu66as
Ahtse said:
Hallo zusammen,

ich würde gerne ein Proxmox Cluster mit einem IBM Flashsystem via FC bereitstellen. Da werden dann thick-LVM Volumes provisioniert damit wir die Volumes in Proxmox auf alle Server teilen können für unseren HA. Bei der Einrichtung mit Multipath und so ist auch alles klar, da habe ich genug Posts gefunden.

Jetzt habe ich nur ein Problem, wir machen das Backup via Veeam und ich verstehe nicht ganz wie dann die Snapshots die Veeam benötigt funktionieren. Muss ich da dann Volume Chain Snaps auf den LVM Volumes aktivieren und eine 1TB VM ist dann mit dem Snap 2TB groß? Kann ich die Snaps einfach auf ein dafür dediziertes NAS auslagern? Oder übersehe ich hier etwas komplett?
Click to expand...
Ich würde beim Flashsystem lieber auf NVMe over FC gehen, dann sparst du dir auch die extra Multipath Konfiguration, da das bei NVMe schon im Protokoll integriert ist.
 
  • Like
Reactions: Ahtse
@Ahtse , der Hinweis von @Johannes S ist wichtig: Die von Blockbridge dokumentierten Datenintegritätsprobleme bei qcow2/LVM-Snapshots mit cache=none relativieren meine Aussage von vorhin deutlich. Ich würde von Volume-Chain-Snapshots auf dem shared LVM für die Worker VM abraten und bei der Empfehlung bleiben: lokales LVM-Thin oder Directory-Storage auf den Nodes. Das ist erprobt und risikolos.

Zum Vorschlag von @Falk R. — NVMe over FC (NVMe/FC) statt klassischem SCSI over FC ist bei einem IBM Flashsystem definitiv die bessere Wahl, wenn eure FC-Infrastruktur das unterstützt (ab 32G FC in der Regel kein Problem). Multipathing ist bei NVMe nativ im Protokoll (ANA), ihr spart euch die komplette multipathd-Konfiguration und habt gleichzeitig niedrigere Latenzen. Das Flashsystem unterstützt NVMe/FC — prüft, ob eure HBAs und Switches das ebenfalls können.
 
  • Like
Reactions: Ahtse
Bu66as said:
@Ahtse , der Hinweis von @Johannes S ist wichtig: Die von Blockbridge dokumentierten Datenintegritätsprobleme bei qcow2/LVM-Snapshots mit cache=none relativieren meine Aussage von vorhin deutlich. Ich würde von Volume-Chain-Snapshots auf dem shared LVM für die Worker VM abraten und bei der Empfehlung bleiben: lokales LVM-Thin oder Directory-Storage auf den Nodes. Das ist erprobt und risikolos.
Click to expand...
Das bringt ja nix, weil man dann kein shared Storage mehr hat.
Veeam ist nicht auf eine Diskbasierte Snapshotfunktion angewiesen, also schön klassisch LVM shared nutzen und das läuft auch mit Veeam.
Ich persönlich nutze Veeam nur noch Agent Basiert für DB VMs und der Rest wird per PBS gemacht.
Bei Veeam habe ich immer wieder Stabilitätsprobleme, welche ich bei VMware mit Veeam nie hatte und der Veeam Agent läuft da viel stabiler.
 
  • Like
Reactions: Johannes S, Ahtse and Bu66as
You must log in or register to reply here.
Top Bottom
Back