Veeam & Proxmox bei Shared Storage via FC

[Ahtse]

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?

 

[aL1aL7]

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

 

[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.

 

[Johannes S]

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.

 

[Medo-Luki]

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.

 

[aL1aL7]

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.