Skip to main content
  • EN

Hallo zusammen,

 

viele meiner Kunden setzen VBR mittlerweile - auf meinen Rat hin - in eine VM, um somit flexibel zu sein und z.B. auch via Replication die VM selbst in ein zweites Datacenter (z.B. auf lokale Disks eines ESXi-Servers) zu kriegen und im K-Fall mit wenigen Klicks die Replika-VM hochzufahren - so weit so gut.

 

Einer meiner Kunden betreibt ein auf Nutanix AHV basiertes Cloud-RZ und auf der primären Site vSphere. Die Herausforderung ist nun, mit sehr geringer RTO im Falle eines Ausfalls der Primärsite auf der DR-Site (AHV) Instant Recovery zu fahren - das geht ja gegen alle Hypersivoren, also alles gut - nur ohne Veeam-Instanz nicht machbar.

 

Möglichkeit 1: Spricht etwas dagegen, den VBR Server als VM von vorn herein auf AHV laufen zu lassen (dort stehen dann auch S3 Tiers mit Immutability und ggf. auch andere Repos) und eben über eine Site-to-Site-VPN o.ä. die Repos und Proxies in der Primärsite anzusprechen? Was benötigt man da für Performance / Latenz oder seht ihr Vor- und Nachteile?

 

Möglichkeit 2: Replication...aber das geht eben nur von vSphere zu vSphere oder AHV zu AHV...also keine echte Alternative.

 

Möglichkeit 3: Im K-Fall muss Veeam auf einer vorbereiteten VM auf AHV neuinstalliert werden, dann das Config-Backup zurückgesichert werden. Ist für meinen Geschmack aber zu manuell und hat wenig mit Low-RTO zutun.

 

Habt ihr Ideen, wie man das lösen kann? vSphere auf der Primärsite und AHV auf der DR-Site (“Cloud”) sind definitiv gesetzt, das ist eine Vorgabe.

 

Danke vorab!

Hallo Lukas,
sind deine Repos auf der primären Seite von Repository Servern verwaltet?

Wenn die Repos eigenständig sind und nicht direkte Laufwerke des Veeam Server sind, laufen ja nur Meta Daten an den Veeam Server und die Backup Daten direkt zu den Repository Servern, bzw. die Object Storages. Dann ist es durchaus denkbar den Veeam Server auf die DR Seite zu stellen, denn es werden nur wenige Daten an den Server gesendet und der Hauptdatenverkehr geht direkt zu den jeweiligen Repos.

In dem Fall hast du den funktionierenden Veeam Server im Katastrophenfall schon auf der DR Seite laufen - Voraussetzung ist natürlich, dass du die Backups auch auf die DR Seite kopiert hast.

 

Möglichkeit 3 ist auch denkbar. Das kommt aber darauf an wie viele Aktionen zweischen den Configuration backups laufen. Wenn du “nur” in der Nacht sicherst und danach ein Config Backup machst, verlierst du nichts oder nicht viel, wenn du eine neue VM aufsetzt, Veeam installierst und die DB zurücksicherst.

Solltest du aber rund um die Uhr sichern, brauchst du entweder viele Config Backups in kurzen Abständen oder du verlierst relativ viele Einträge in der Datenbank. Die erstellten Backups kannst du allerdings durch Rescans der Repositories wieder einlesen. Dieses Vorgehen ist bei Cloud Object Storage Repos nicht zu empfehlen, weil sie viele API Calls verursacht.

 

Es kommt also auf deine Umgebung und deine Sicherungsmethode an...

Hallo @JMeixner,

danke für den Input! Es ist tatsächlich so gedacht, dass Proxies und Repos (Standalone, also losgelöst von dem Backupserver) auf der primären Site laufen und somit lediglich die VBR-Instanz und natürlich S3-basierte Copies auf der DR-Seite betrieben werden.

Klingt doch wunderbar!

Fein, schön, wenn es dir geholfen hat. 😎 Freut mich.

 

Hast du schon praktische Erfahrungen gemacht mit dem Restore von VMs von VMware zu Nutanix?
Das habe ich zum Beispiel noch nie gemacht. Gibt es dort noch was zu beachten?

Leider auch noch nicht, aber wollte das nach der VeeamON mal nachbauen, hab alles an Laborumgebungen hier...kann gerne berichten!

Gerne, sowas ist doch immer interessant. 😁

Comment


Terms & Conditions