11
VM mit physik. LUN via BackUp Exec sichern schläg fehl
Hallo zusammen,
ich muss "mal wieder" eine BackUp Frage in die Runde werfen.
Wir sichern unser VM-Cluster mit BackUp Exec 2016, bei allen VMs funktioniert das einwandfrei nur eine ist etwas besonders.
Die VM hat 3 Festplatten, 2 davon normale VMDK-Dateien, 1 Physische LUN.
Wenn BackUp Exec jetzt versucht diese zu sichern schlägt dies fehl da kein SnapShot gesetzt werden kann.
Hard- / Softwareinfo
ESX Version 6.5
VM Version 8
BackUp Exec 2016
Ich habe bereits versucht die physische Platte aus dem BackUp auszuklammern aber er will die Maschine dennoch nicht sichern.
Wenn ich selbst einen Snapshot erstellen will muss ich den Haken bei "Snapshot des Arbeitsspeichers der virtuellen Maschine erstellen" entfernen, dann geht es.
Hat jemand einen Tipp oder kenn jemand diese Problematik?
Zum vorhandenen System muss ich leider sagen das alles so wie es ist auch bleiben muss, ich kann die 3 Festplatte nicht in eine virtuelle wandeln!
ich muss "mal wieder" eine BackUp Frage in die Runde werfen.
Wir sichern unser VM-Cluster mit BackUp Exec 2016, bei allen VMs funktioniert das einwandfrei nur eine ist etwas besonders.
Die VM hat 3 Festplatten, 2 davon normale VMDK-Dateien, 1 Physische LUN.
Wenn BackUp Exec jetzt versucht diese zu sichern schlägt dies fehl da kein SnapShot gesetzt werden kann.
Hard- / Softwareinfo
ESX Version 6.5
VM Version 8
BackUp Exec 2016
Ich habe bereits versucht die physische Platte aus dem BackUp auszuklammern aber er will die Maschine dennoch nicht sichern.
Wenn ich selbst einen Snapshot erstellen will muss ich den Haken bei "Snapshot des Arbeitsspeichers der virtuellen Maschine erstellen" entfernen, dann geht es.
Hat jemand einen Tipp oder kenn jemand diese Problematik?
Zum vorhandenen System muss ich leider sagen das alles so wie es ist auch bleiben muss, ich kann die 3 Festplatte nicht in eine virtuelle wandeln!
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 367182
Url: https://administrator.de/contentid/367182
Ausgedruckt am: 08.11.2024 um 21:11 Uhr
11 Kommentare
Neuester Kommentar
Hi,
Du wirst die RAW-Disk nicht über den ESX sichern können. Aber dann ist die Sicherung der VM auch nicht vollständig. Ist diese RAW-Disk denn unwichtig oder sicherst Du diese auf eine andere Art?
Alternative: Sicherung über LAN via klassischen Agent im Gast-OS. Dieser kann dann auch die RAW-Disk sichern.
E.
Du wirst die RAW-Disk nicht über den ESX sichern können. Aber dann ist die Sicherung der VM auch nicht vollständig. Ist diese RAW-Disk denn unwichtig oder sicherst Du diese auf eine andere Art?
Alternative: Sicherung über LAN via klassischen Agent im Gast-OS. Dieser kann dann auch die RAW-Disk sichern.
E.
Unwichtig leider nicht, die HDD müsste ich seperat betrachten.
Die Idee mit dem Agent kam mir auch aber dann muss ich für die Rücksicherung das komplette OS bereitstellen, so brauch ich erstmal "nur" die VM zurücksichern.
Geht das denn irgendwie?
Eine Strategie für die Sicherung der einzelnen Platte habe ich leider noch nicht, max. auf Dateiebene oder Freigabe oder?
Die Idee mit dem Agent kam mir auch aber dann muss ich für die Rücksicherung das komplette OS bereitstellen, so brauch ich erstmal "nur" die VM zurücksichern.
Geht das denn irgendwie?
Eine Strategie für die Sicherung der einzelnen Platte habe ich leider noch nicht, max. auf Dateiebene oder Freigabe oder?
Moin,
Auch wenn es nicht direkt zur Lösung beiträgt, sondern eher eine andere SIcht der DInge bedeutet:
Warum muss das LUN denn direkt an der VM gepappt sein?
Kann die nicht dem ESXi zugerodnet werden und dann eine VMDK darauf abgelegt werden?
Gruß
em-pie
Auch wenn es nicht direkt zur Lösung beiträgt, sondern eher eine andere SIcht der DInge bedeutet:
Warum muss das LUN denn direkt an der VM gepappt sein?
Kann die nicht dem ESXi zugerodnet werden und dann eine VMDK darauf abgelegt werden?
Gruß
em-pie
Durchaus berechtige Frage! Das wurde in der Vergangenheit mal durch eine externe Firma so eingerichtet ... welche Hintergründe das hat ist mir leider Schleierhaft.
Durchaus berechtige Frage! Das wurde in der Vergangenheit mal durch eine externe Firma so eingerichtet ... welche Hintergründe das hat ist mir leider Schleierhaft.
Und warum schreibst Du dann eingangs sowas?Zum vorhandenen System muss ich leider sagen das alles so wie es ist auch bleiben muss, ich kann die 3 Festplatte nicht in eine virtuelle wandeln!
Ich weiss nicht wie das die Aussage unterscheidet ...
Das System wurde von extern eingeführt, darf durch mich jedoch nicht bearbeitet werden.
BE-Agent installieren wäre kein Problem ... die phys. Platte in eine virtuelle zu wandeln hingegen schon.
Das System wurde von extern eingeführt, darf durch mich jedoch nicht bearbeitet werden.
BE-Agent installieren wäre kein Problem ... die phys. Platte in eine virtuelle zu wandeln hingegen schon.
Na OK, Ansichtssache.
Wenn mir ein Dienstleister nicht sachlich plausibel erklären kann, warum etwas so und nicht anders eingerichtet werden muss, und sich mir das auch selbst nicht erschließt, dann hinterfage ich das beim Dienstleister. Und ggf. verweigere ich die Implementierung oder ich gebe die Rahmenbedingungen vor. So mein Selbstverständnis. Nicht selten kommt: "Das machen wir immer so.", aber keine plausible Begründung. Nebenbei ist das auch ne einfache Methode, beim Dienstleister fachlich auf den Busch zu klopfen. Ich hatte schon SAP-zertifizierte SAP-Installer im Haus, die mir wundersame Dinge aufbinden wollten. Und denen habe ich dann den Installationsleitfaden, nach welchem sie krampfhaft installieren müssen, ein paar Seiten vorgeblättert, wo dann stand, wie es auch anders geht (passend zu unseren Bedingungen).
Wenn mir ein Dienstleister nicht sachlich plausibel erklären kann, warum etwas so und nicht anders eingerichtet werden muss, und sich mir das auch selbst nicht erschließt, dann hinterfage ich das beim Dienstleister. Und ggf. verweigere ich die Implementierung oder ich gebe die Rahmenbedingungen vor. So mein Selbstverständnis. Nicht selten kommt: "Das machen wir immer so.", aber keine plausible Begründung. Nebenbei ist das auch ne einfache Methode, beim Dienstleister fachlich auf den Busch zu klopfen. Ich hatte schon SAP-zertifizierte SAP-Installer im Haus, die mir wundersame Dinge aufbinden wollten. Und denen habe ich dann den Installationsleitfaden, nach welchem sie krampfhaft installieren müssen, ein paar Seiten vorgeblättert, wo dann stand, wie es auch anders geht (passend zu unseren Bedingungen).
Ich sehe das ähnlich/ identisch wie emeriks
Auch wenn die aktuelle DIskussion nicht akut zu deinem Problem beiträgt, aber würde das alles dennoch mal beim DL hinterfragen.
Kläre mal ab, warum die das so gemacht haben.
Spreche mit denen, dass du die Kiste nicht sauber sichern/ restoren kannst, wie es aktuell läuft und was deren Ansatz/ Best PRactice ist. Wenn die hierzu auch keine akzeptable Lösung haben, besprich mit denen, ob man das konstrukt nicht abändern kannst: LUN an den ESXi hängen -> VMDK auf die LUN ablegen. Wenn das nicht machbar ist, lass dir erklären warum das nicht machbar ist.
Auch wenn die aktuelle DIskussion nicht akut zu deinem Problem beiträgt, aber würde das alles dennoch mal beim DL hinterfragen.
Kläre mal ab, warum die das so gemacht haben.
Spreche mit denen, dass du die Kiste nicht sauber sichern/ restoren kannst, wie es aktuell läuft und was deren Ansatz/ Best PRactice ist. Wenn die hierzu auch keine akzeptable Lösung haben, besprich mit denen, ob man das konstrukt nicht abändern kannst: LUN an den ESXi hängen -> VMDK auf die LUN ablegen. Wenn das nicht machbar ist, lass dir erklären warum das nicht machbar ist.
Das System wurde vor meiner Zeit eingeführt.
Den Dienstleister was zu Fragen ist so als wenn ich quasi einen rasierten Affen nach Kernphysik aushorche.
Leider bin ich mit dem Thema allein, auf dem Gerät ist Software die lizenzmäßig irgendwie an die verfluchte Hardware geklemmt ist.
Ich würde die phys. LUN liebend gerne abschaffen, habe auch mehrfach den Versuch gewagt aber ich habe im eigenen Betrieb schon nicht genug Rückendeckung um das Projekt sauber umzusetzen ... ergo, nimm das was du hast und mach das beste draus ... es muss ALLES können, darf aber NIX kosten.
Den Dienstleister was zu Fragen ist so als wenn ich quasi einen rasierten Affen nach Kernphysik aushorche.
Leider bin ich mit dem Thema allein, auf dem Gerät ist Software die lizenzmäßig irgendwie an die verfluchte Hardware geklemmt ist.
Ich würde die phys. LUN liebend gerne abschaffen, habe auch mehrfach den Versuch gewagt aber ich habe im eigenen Betrieb schon nicht genug Rückendeckung um das Projekt sauber umzusetzen ... ergo, nimm das was du hast und mach das beste draus ... es muss ALLES können, darf aber NIX kosten.
Salutti zusammen
Wie wäre es wenn du auf dieser VM einfach den Veeam Agent for Windows installierst?
Damit kannst du die VM auch über die Recovery zurückholen.
So als Insellösung vielleicht einen Blick wert.
https://www.veeam.com/de/windows-cloud-server-backup-agent.html
gruass affabanana
Wie wäre es wenn du auf dieser VM einfach den Veeam Agent for Windows installierst?
Damit kannst du die VM auch über die Recovery zurückholen.
So als Insellösung vielleicht einen Blick wert.
https://www.veeam.com/de/windows-cloud-server-backup-agent.html
gruass affabanana
Die Lösung war leider leichter als gedacht.
Das BackUp musste so angepasst werden das nur die relevanten VMDK-Dateien gesichert werden, wählt man hier die gesamte VM so versucht er auch die RAW-HDD zu sichern.
Das BackUp musste so angepasst werden das nur die relevanten VMDK-Dateien gesichert werden, wählt man hier die gesamte VM so versucht er auch die RAW-HDD zu sichern.
