Proxmox Backup/Migration mit Veeam

[Grisu76]

Hallo zusammen,

Ich stehe vor einer Problemstellung, die mich in den Wahnsinn treibt (oder seh den Wald vor lauter Bäumen nicht).

Folgende Situation:

Einer unserer Kunden ist von VMWare zu Proxmox gewechselt (Gründe kann sich jeder vorstellen).

Zur Migration von VMWare zu Proxmox gibt es bekanntermaßen mehrere Wege.

1. Direkter Import vom ESX nach Proxmox mit entsprechenden Anleitungen.
2. Sicherung der VMs unter VMWare und restore unter Proxmox.

Einzelne VMs sind bereits auf dem Proxmox, diese konnten teilweise direkt importiert werden, wurden aber auch bereits durch Backup&Restore migriert. Achtung auf erstem Backupserver, damals noch ohne Proxmoxjob.

Der aktuelle Backupserver ist wieder als VM auf Proxmox installiert. Allerdings ist das schon der zweite. Die erste Version dieses Servers wurde durch eine Datensicherung zerstört-

Also:

1. Backupserver -> Veeam B&R 13 -> sichert Proxmox, auf dem sich der Backupserver befindet -> Backupserver verliert unkontrolliert und nicht direkt nachstellbar IP-Adressen, ISCSI-Targets und friert ein, dass nur noch ein Hard-Stop möglich ist.
Auch der von Veeam auf Proxmox genutzte Worker ist nicht mehr nutzbar.

2. Backupserver Nr. 2 -> Veeam B&R13 -> sichert Proxmox (Backupserver ist von der Sicherung ausgenommen -> Sicherung erfolgreich. Auch die VMWarejobs laufen durch.


Heute wollte ich einen Testrestore machen. Dieser schlägt aber fehl, nachdem der Worker gestartet wurde und die Platten der VM mit dieser hotadd-Funktion erstellt werden sollten. Die eigentlich schon erstellte VM wird von Veeam aufgrund failed wieder gelöscht.

Bei einigen Recherchen wurde empfohlen, den Worker auf einem anderen Datastore laufen zu lassen als die zu erstellende VM. Nun der kleine Haken. Der local-Datastore ist nur 32GB, da dieser Server eigentlich für eine erneute VMWareinstallation vorgesehen war und die 32GB für VMWare ausreichend wären.

Ich habe mir überlegt von einer der vorhandenen NAS ein NFS-SHare in den Proxmox einzuhängen und darauf mit dem Worker zu arbeiten. Testen konnte ich es leider noch nicht.

Es wurde in einigen Recherchen auch geraten, eine separate DebianVM als Proxy zu nutzen. Diese VM habe ich erstellt, bei einem Restore greift Veeam aber trotzdem auf den hauseigenen Worker zurück.

Hatte von euch vielleicht schon jemand ein ähnliches Problem und wie konntet ihr es lösen. Anderes Programm? Anderes Migrationsvorgehen?

Ich bin für jede Hilfe dankbar.

Gruß Markus

 

[ThoSo]

Zum thema migration findest hier im forum und wiki mit sicherheit mehr als genug material.
Ob jetzt veeam mit proxmox optimal läuft kann ich nicht sagen, aber migration wird hier i.d.R von ESXi nach Proxmox anderst gemacht.
Was auch hilfreich wäre, mal eine beschreibung der Hardware und deines netwerkes, damit man auch mal abschätzen kann, warum es zu einem freez kommt bzw ob da andere Optionen zielführender wären.

 

[aL1aL7]

Welche Version der virtio Treiber hast Du in der Veeam-Maschine installiert?

 

[ITMader]

Hallo Grisu,

ähnliche Probleme kenne ich auch mit Proxmox + Veeam.

Eine Ursache für Backup-Fehler, v.a. wenn Speicherplatz volläuft/zu viele Snapshots entstehen, sind Konfigurationen verschiedener Backup-Systeme, die nichts voneinander wissen und nicht miteinander funktionieren.

Soll der Veeam-Server als VM auf dem selben Host laufen, von dem er die VMs sichert? Die Infrastruktur würde ich ggfs. Überdenken.

Empfohlene Infrastruktur:
- Veeam-Server läuft direkt auf eigener Hardware und ist an 2 dedizierte Speichergeräte angeschlossen(z.B. ext. HDD, iSCSI LUN,...)
-Veeam ist sowohl mit PVE als auch mit ESXi Host veebunden
- Veeam sichert in einem Job PVE-VMs, im anderen die ESXi-VMs

-Proxmox nutzt einen eigenen LVM mit lv für die raw-disks der VMs
Wichtig: zusätzlich genügend großer File-Level Datastore. Den braucht der Veeamworker. Also dein Ansatz mit dem NFS Share auf der NAS ist da richtig.
Es wird empfohlen, auf jedem PVE Host einen Veeamworker zu deployen.

Der Veeam Server sollte den Worker übers Netz erreichen können.

Manchmal sieht man auch in der konsole auf dem veeamworker interessante Infos wenn das Backup läuft.


Migration ablauf:
-Active Full-Backup von einer VM des ESXi erstellen
-das neue Backup auswählen
-daraus Restore entire VM -> PVE
-speicher (lv) auswählen, raw als disktype wählen, netzwerk wählen und los
-Warten...
Wenn keine direkte Fehlermeldung: später erneut versuchen
-->einfach laufen lassen auch wenn die Operation ohne Fortschrittsanzeige lange läuft. Es kann sensibel reagieren.
-wenn die VM dann in PVE startet: vioscsi treiber nachinstallieren

Bei einem Fehler-> Protokolle und Fehlermeldungen teilen

 

[Johannes S]

Zur Migration von VMWare zu Proxmox gibt es bekanntermaßen mehrere Wege.

1. Direkter Import vom ESX nach Proxmox mit entsprechenden Anleitungen.
2. Sicherung der VMs unter VMWare und restore unter Proxmox.

Naja für 1. gibt es außer den Import-Wizard von ProxmoxVE auch noch mehr Möglichkeiten. Eine davon ist ideal, wenn man eine möglichst geringe Downtime will und setzt außerdem keine Software außer ESX und ProxmoxVE voraus, benötigt aber ein NFS-netzwerklaufwerk (dafür kann man sich ja eine VM mit passender Freigabe erstellen):
https://pve.proxmox.com/wiki/Migrate_to_Proxmox_VE#Attach_Disk_&_Move_Disk_(minimal_downtime)

Siehe auch https://forum.proxmox.com/posts/835620/ wie man die nötigen Treiber mit minimalen Aufwand zum Fliegen kriegt.


Hier wird immer mal wieder von Problemen mit Veeam und ProxmoxVE berichtet. Darum habe den Eindruck, dass Veeams Proxmoxsupport noch eine public beta ist, die nur rausgebracht wurde, damit die Kundschaft nicht zum ProxmoxBackupServer wechselt

Envtl. ist also eine der im wiki beschriebenen Alternativen ein besserer Weg zur Migration?

Für das eigentliche Backup würde ich mir überlegen, ob man nicht (wenn man wegen Vmware eh schon Teile der Infrastruktur migriert) auch die Backupstrategie überarbeitt. Hier im Forum gibt es einige Leute, die auch zum ProxmoxBackupServer gewechselt sind und Veeam entweder gar nicht mehr oder (in Form einer günstigeren Subscription für VeeamAgenten) nur noch für die application-awaren Backups ihres Domain-Controllers und MS-SQL-Datenbanken einsetzen.

 

[ITMader]

Naja für 1. gibt es außer den Import-Wizard von ProxmoxVE auch noch mehr Möglichkeiten. Eine davon ist ideal, wenn man eine möglichst geringe Downtime will und setzt außerdem keine Software außer ESX und ProxmoxVE voraus, benötigt aber ein NFS-netzwerklaufwerk (dafür kann man sich ja eine VM mit passender Freigabe erstellen):
https://pve.proxmox.com/wiki/Migrate_to_Proxmox_VE#Attach_Disk_&_Move_Disk_(minimal_downtime)

Siehe auch https://forum.proxmox.com/posts/835620/ wie man die nötigen Treiber mit minimalen Aufwand zum Fliegen kriegt.


Hier wird immer mal wieder von Problemen mit Veeam und ProxmoxVE berichtet. Darum habe den Eindruck, dass Veeams Proxmoxsupport noch eine public beta ist, die nur rausgebracht wurde, damit die Kundschaft nicht zum ProxmoxBackupServer wechselt

Envtl. ist also eine der im wiki beschriebenen Alternativen ein besserer Weg zur Migration?

Für das eigentliche Backup würde ich mir überlegen, ob man nicht (wenn man wegen Vmware eh schon Teile der Infrastruktur migriert) auch die Backupstrategie überarbeitt. Hier im Forum gibt es einige Leute, die auch zum ProxmoxBackupServer gewechselt sind und Veeam entweder gar nicht mehr oder (in Form einer günstigeren Subscription für VeeamAgenten) nur noch für die application-awaren Backups ihres Domain-Controllers und MS-SQL-Datenbanken einsetzen.

Der ein- oder andere hat auch Alternativen, Windows-VMs besser zu migrieren. Wir gehen übers Backup, da es gleich auch die komplette Backupinfrastruktur testet und verschiedene Rollback-Möglichkeiten bietet.

Ich hoffe, dass Veeam das Proxmox-Plugin noch ausbaut. Treiberunterstützung wäre natürlich ein Traum..

Wenn man nur PVE rücksichern möchte, ist Proxmox Backup bestimmt eine super Wahl.

 

[Grisu76]

Zum thema migration findest hier im forum und wiki mit sicherheit mehr als genug material.
Ob jetzt veeam mit proxmox optimal läuft kann ich nicht sagen, aber migration wird hier i.d.R von ESXi nach Proxmox anderst gemacht.
Was auch hilfreich wäre, mal eine beschreibung der Hardware und deines netwerkes, damit man auch mal abschätzen kann, warum es zu einem freez kommt bzw ob da andere Optionen zielführender wären.

Hallo ThoSo:

wie machst du die Migration von VMware zu proxmox? Einen Link dazu wäre schick.

Welche Informationen hättest du gerne? Die vom benutzten Backupserver oder generell vom Hardwareserver, Switchen und Co?

Die Hardware ist folgende:
Lenovo SR665
1CPU mit 16 Cores
8x32GB Ram
2 M2 SataSSD 32GB (Raid 1) als local. Ich weiss, das ist eigentlich zu wenig, aber der Server war für VM-Ware konfiguriert und der Kunde wollte dann doch Proxmox)
12 x 1TB Raid 6 als Datastore

Gesichert wird auf eine Synology NAS per ISCSI. Zirektes kopieren vom Backupserver zur Syno läuft mit 1GB lesend und schreibend.

Backupserver:

Virtio-win-guest-tools

0.1.240

Switche sind Aruba InstantON. Firewall Opensense. Portfreigaben und entsprechende VLANs sind passend konfiguriert, das haben wir schon getestet.


Wenn du noch mehr Infos brauchst, einfach melden.

Gruß Markus

 

[aL1aL7]

Du kannst in Proxmox den esxi als Storage einbinden. Danach kannst Du die esxi-Maschinen (wenn die VM aus ist) einfach importieren.

Wenn Du auf ein iSCSI - Ziel sicherst und Veeam virtualisiert in Proxmox ist, wäre der verwendete virtio-Treiber (sofern Du als Netzwerkgerät die virtio-Karte eingerichtet hast) wichtig.
Ich hatte massive Probleme mit Veeam -> Sicherung auf iSCSI - Ziel und den Treibern in Version 0.1.285-1. Mit den Treibern Version 0.1.271-1 läuft alles sehr geschmeidig.

 

[ITMader]

3. In VEEAM  Home  Backups  Disks VM auswählen  Rechtsklick  Full Restore VM  Proxmox VE  Richtige Konfigurationen auswählen (Full Backup auswählen nicht vergessen / Dateiformat RAW)

4. FÜR WINDOWS RECHNER: Nach Migration in die Proxmox VE Oberfläche einloggen.  VM auswählen  Hardware  SCSI Controller  Zu VirtIO SCSI ändern.

5. Hardware  CD/DVD Drive (ide2) hinzufügen  Win Server 2019 ISO (oder entsprechende Windows Version) auswählen  Hinzufügen

6. Hardware  CD/DVD Drive (sata0) hinzufügen  Virtio-win-0.1.. iso auswählen  hinzufügen

7. VM starten  Boot Menü  Aus Windows ISO booten SHIFT+10 oder Computer Reparatur Command Shell

8. In das directory von VirtIO wechseln, meist „e:“ also Eingabe  „e:“  mit „dir“ überprüfen (Wir gehen für die Beispiele von „e:“ als das VirtIO directory aus)

9. „cd amd64\2k19“ ODER „cd amd64/2k16“ je nach Windows Version. (Wir gehen für die Beispiele von 2k19 aus.)

10. „drvload vioscsi.inf“  Überprüfen „diskpart“  „list disk“  Windows Platte sollte angezeigt werden  „exit“

11. Zur VM Windows Directory wechseln (meist „f:“) also Eingabe  „f:“  mit „dir“ überprüfen (Wir gehen für die vorausgehenden Beispiele von „f:“ aus)

12. „e:“ (Nach Überprüfung / Feststellung der VM Windows Directory Location  Zurück zur VirtIO.iso directory)

13. „dism /image:f: /Add-Driver:e:\ /recurse”

14. „copy *.inf f:\windows\inf“ (Falls vorhanden NICHT überschreiben)

15. „copy *.sys f:\windows\system32\drivers“ (Falls vorhanden NICHT überschreiben)

PRÜFUNG:

16. „reg load HKLM\offline f:\windows\system32\config\system”

17. “regedit”  Registry Fenster öffnet sich  offline  ControlSet001  Services  vioscsi

Es müssen folgende Daten vorhanden sein:

NAME | TYPE | Data

Group | REG_SZ | SCSI miniport

Start | REG_DWORD | 0

Type | REG_DWORD | 1

Wenn nicht vorhanden  ERSTELLEN

18. “regedit”  Registry Fenster öffnet sich  offline  ControlSet001  Services  viostor

Es müssen folgende Daten vorhanden sein:

NAME | TYPE | Data

Group | REG_SZ | SCSI miniport

Start | REG_DWORD | 0

Type | REG_DWORD | 1

Wenn nicht vorhanden  ERSTELLEN

19. Registry schließen und dann  “reg unload HKLM\offline”

20. VM neu booten, VM sollten nun booten, wenn nicht nochmal Video checken :

Migrate Windows Server 2016 from ESXi 7 to Proxmox 8 – Step-by-Step Walkthrough ️

 

[Grisu76]

@ITMader Das Problem ist, dass der Import, wie er im Video beschrieben ist, nicht korrekt durchläuft. Dieser bricht nach einiger Zeit ab und die VM ist defekt. Warum der Abbruch stattfindet konnte ich noch nicht herausfinden, da es nicht immer bei XX % abbricht. Das letzte Mal konnte ich zufällig sehen, dass er ungefähr bei 30% abgebrochen ist, ein anderes Mal war er bereits bei über 70% und nach der Mittagspause hatte ich KEIN Ok und weder eine defekte VM.

Ich hab jetzt parallen auch mal ein Ticket bei Veeam aufgemacht.

Das Interessante war: Ich konnte, bevor es mir den ersten Backupserver zerhäckselt hat, bereits mehrere VMs durch Backup VMWare -> Restore Proxmox migrieren. Der einzige Unterschied, dass auf dem ersten Backupserver Veeam12.3 installiert war und auf dem zweiten Veeam 13.



Gruß Markus

 

[ITMader]

Okay, dann machst du es richtig. Den Fehler konnte ich auch beobachten. Hat bei mir aber wieder funktioniert. Ist wahrscheinlich ein Problem im Veeam Plugin

 

[Grisu76]

Okay, dann machst du es richtig. Den Fehler konnte ich auch beobachten. Hat bei mir aber wieder funktioniert. Ist wahrscheinlich ein Problem im Veeam Plugin

Was ich schon überlegt habe:

bevor es den ersten Backupserver geshreddert hat, habe ich bereits 2 VMs mit Backup & Restore zum Proxmox migrieren können (und hab dann blöderweise den Proxmoxjob laufen lassen :-( ) . Da war rückblickend Veeam 12.3 auf der Kiste. Wäre doch mal ein Versuch wert, den jetzigen , funktionierenden, Backupserver zu klonen, Veeam 13 zu deinstallieren und 12.3 zu installieren. Danach eine Sicherung der VMWarekisten zu machen und diese zu restoren. Wenn dann alle Server auf Proxmox sind, kann ich (vielleicht) wieder auf 13 upgraden.

Wäre ein Versuch wert, bis Veeam mal in die Pötte kommt.

Was ich übrigens auch noch feststellen konnte. Ein restore einer VM, die bereits auf Proxmox ist und über Veeam gesichert wurde, ist problemlos möglich. Ich habe fast den Verdacht, dass die Importfunktion von Proxmox da auch noch einen Bug hat.

schönen Abend

Markus

 

[Falk R.]

3. In VEEAM  Home  Backups  Disks VM auswählen  Rechtsklick  Full Restore VM  Proxmox VE  Richtige Konfigurationen auswählen (Full Backup auswählen nicht vergessen / Dateiformat RAW)

4. FÜR WINDOWS RECHNER: Nach Migration in die Proxmox VE Oberfläche einloggen.  VM auswählen  Hardware  SCSI Controller  Zu VirtIO SCSI ändern.

5. Hardware  CD/DVD Drive (ide2) hinzufügen  Win Server 2019 ISO (oder entsprechende Windows Version) auswählen  Hinzufügen

6. Hardware  CD/DVD Drive (sata0) hinzufügen  Virtio-win-0.1.. iso auswählen  hinzufügen

7. VM starten  Boot Menü  Aus Windows ISO booten SHIFT+10 oder Computer Reparatur Command Shell

8. In das directory von VirtIO wechseln, meist „e:“ also Eingabe  „e:“  mit „dir“ überprüfen (Wir gehen für die Beispiele von „e:“ als das VirtIO directory aus)

9. „cd amd64\2k19“ ODER „cd amd64/2k16“ je nach Windows Version. (Wir gehen für die Beispiele von 2k19 aus.)

10. „drvload vioscsi.inf“  Überprüfen „diskpart“  „list disk“  Windows Platte sollte angezeigt werden  „exit“

11. Zur VM Windows Directory wechseln (meist „f:“) also Eingabe  „f:“  mit „dir“ überprüfen (Wir gehen für die vorausgehenden Beispiele von „f:“ aus)

12. „e:“ (Nach Überprüfung / Feststellung der VM Windows Directory Location  Zurück zur VirtIO.iso directory)

13. „dism /image:f: /Add-Driver:e:\ /recurse”

14. „copy *.inf f:\windows\inf“ (Falls vorhanden NICHT überschreiben)

15. „copy *.sys f:\windows\system32\drivers“ (Falls vorhanden NICHT überschreiben)

PRÜFUNG:

16. „reg load HKLM\offline f:\windows\system32\config\system”

17. “regedit”  Registry Fenster öffnet sich  offline  ControlSet001  Services  vioscsi

Es müssen folgende Daten vorhanden sein:

NAME | TYPE | Data

Group | REG_SZ | SCSI miniport

Start | REG_DWORD | 0

Type | REG_DWORD | 1

Wenn nicht vorhanden  ERSTELLEN

18. “regedit”  Registry Fenster öffnet sich  offline  ControlSet001  Services  viostor

Es müssen folgende Daten vorhanden sein:

NAME | TYPE | Data

Group | REG_SZ | SCSI miniport

Start | REG_DWORD | 0

Type | REG_DWORD | 1

Wenn nicht vorhanden  ERSTELLEN

19. Registry schließen und dann  “reg unload HKLM\offline”

20. VM neu booten, VM sollten nun booten, wenn nicht nochmal Video checken :

Migrate Windows Server 2016 from ESXi 7 to Proxmox 8 – Step-by-Step Walkthrough ️

Warum so extrem umständlich?

 

[Falk R.]

Was ich schon überlegt habe:

bevor es den ersten Backupserver geshreddert hat, habe ich bereits 2 VMs mit Backup & Restore zum Proxmox migrieren können (und hab dann blöderweise den Proxmoxjob laufen lassen :-( ) . Da war rückblickend Veeam 12.3 auf der Kiste. Wäre doch mal ein Versuch wert, den jetzigen , funktionierenden, Backupserver zu klonen, Veeam 13 zu deinstallieren und 12.3 zu installieren. Danach eine Sicherung der VMWarekisten zu machen und diese zu restoren. Wenn dann alle Server auf Proxmox sind, kann ich (vielleicht) wieder auf 13 upgraden.

Wäre ein Versuch wert, bis Veeam mal in die Pötte kommt.

Was ich übrigens auch noch feststellen konnte. Ein restore einer VM, die bereits auf Proxmox ist und über Veeam gesichert wurde, ist problemlos möglich. Ich habe fast den Verdacht, dass die Importfunktion von Proxmox da auch noch einen Bug hat.

schönen Abend

Markus

Veeam hat da noch ein paar kleine Bugs. Daher migriere ich im Moment gar nicht mehr mit Veeam.
Tatsächlich lief der Restore mit 12.3 etwas stabiler. Leider ist Veeam nicht so gesprächig, wo das Problem ist. Das was die Worker VM macht ist auch nicht so 100% klar. Ich vermute sogar die Probleme kommen erst mit den 13er Workern.
Der importer von Proxmox läuft dafür extrem zuverlässig und wenn du vSphere8 hast auch gar nicht so langsam. Mit vSphere7 und älter macht das keinen Spaß.
Ich mag ja keine langen Downtimes und Wochenendarbeit, daher migriere ich 90% mit der im Wiki beschriebenen Methode mit minimaler Downtime. Ich passe die VMs beim migrieren auch immer an, daher stört es mich nicht, neue VMs generieren zu müssen, bei den anderen Methoden muss ich im Nachgang wieder einiges anpassen.
Wenn du weiterhin mit Veeam kämpfen möchtest, dann viel Erfolg. Ich habe das Kapitel vorerst abgeschlossen.

 

[ITMader]

Veeam hat da noch ein paar kleine Bugs. Daher migriere ich im Moment gar nicht mehr mit Veeam.
Tatsächlich lief der Restore mit 12.3 etwas stabiler. Leider ist Veeam nicht so gesprächig, wo das Problem ist. Das was die Worker VM macht ist auch nicht so 100% klar. Ich vermute sogar die Probleme kommen erst mit den 13er Workern.
Der importer von Proxmox läuft dafür extrem zuverlässig und wenn du vSphere8 hast auch gar nicht so langsam. Mit vSphere7 und älter macht das keinen Spaß.
Ich mag ja keine langen Downtimes und Wochenendarbeit, daher migriere ich 90% mit der im Wiki beschriebenen Methode mit minimaler Downtime. Ich passe die VMs beim migrieren auch immer an, daher stört es mich nicht, neue VMs generieren zu müssen, bei den anderen Methoden muss ich im Nachgang wieder einiges anpassen.
Wenn du weiterhin mit Veeam kämpfen möchtest, dann viel Erfolg. Ich habe das Kapitel vorerst abgeschlossen.

So wie ich es gemacht habe, hat es mit Veeam funktioniert. Das habe ich unter anderem gemacht, weil die kurzen Anleitungen, welche ich auf Anhieb gefunden hatte, nicht funktionierten. Dann kam ich auf die Idee, dass sowieso das Zusammenspiel von Proxmox und Veeam getestet werden sollte. Also erst Mal ein paar Maschinen so migrieren.
Ich schaue mir Mal die von dir empfohlene Methode mit der überarbeiteten iso für die restlichen VMs an. Danke für den Input.