Ich habe ein Problem mit Veeam Bare-Metal Desaster Recovery (12.3.2) betreffend SUSE Linux Leap 15.6 auf einem HPE Proliant Gen9 Server.
Bei einer Sicherung mit dem aktuellen Veeam Linux Agent 6 und einer Wiederherstellung mit dem Veeam Recovery Image 6.3.2.1207_x86_64 tritt folgender Effekt auf:
Eine Desaster Recoveri im “Legacy Mode” funktioniert einwandfrei und wie in der Anleitung beschrieben.
Wird allerdings ein Server im UEFI Modus gesichert, stertet er nach dem Recovery mit einen “grub” Prompt.
Laut den Anleitungen muss der Bootloader wieder hergestellt werden. Hat hier jemand Erfahrungen und kann sie mir (mögl- einfach ;-) ) erklären?
Schöne Grüße
Marcus
Best answer by Michael Melter
Hallo @Mavo66.
Du stehst hier gleich vor mehreren Herausforderungen.
Wenn Du, was bei SuSE Default ist, BTRFS auf LVM für den Boot verwendest, wirst Du kein Glück haben. Das wird aktuell nicht unterstützt: Feature Request - BTRFS with LVM - R&D Forums Ich habe es selbst kürzlich nochmal als Feature Request eingekippt, da mir permanent HANA Systeme mit entsprechendem Setup begegnen.
Das ISO unterstützt keine Secure-Boot Umgebung. Du musst Secure-Boot vor dem Recovery deaktivieren und danach wieder aktivieren. Aber wenn ich deinen Satz zu “Legacy” richtig interpretiere, hast Du das gemacht. Für’s ISO mit Secure-Boot wäre ein weiterer UEFI Key und MOKUTIL nötig, den es aber offenbar nicht gibt. Bad shim signature while booting custom Linux recovery ISO - R&D Forums
Hoffe es hilft. Ich vermute mal es ist BTRFS auf LVM bei Euch. Dann → Feature Request… ;)
Du stehst hier gleich vor mehreren Herausforderungen.
Wenn Du, was bei SuSE Default ist, BTRFS auf LVM für den Boot verwendest, wirst Du kein Glück haben. Das wird aktuell nicht unterstützt: Feature Request - BTRFS with LVM - R&D Forums Ich habe es selbst kürzlich nochmal als Feature Request eingekippt, da mir permanent HANA Systeme mit entsprechendem Setup begegnen.
Das ISO unterstützt keine Secure-Boot Umgebung. Du musst Secure-Boot vor dem Recovery deaktivieren und danach wieder aktivieren. Aber wenn ich deinen Satz zu “Legacy” richtig interpretiere, hast Du das gemacht. Für’s ISO mit Secure-Boot wäre ein weiterer UEFI Key und MOKUTIL nötig, den es aber offenbar nicht gibt. Bad shim signature while booting custom Linux recovery ISO - R&D Forums
Hoffe es hilft. Ich vermute mal es ist BTRFS auf LVM bei Euch. Dann → Feature Request… ;)
Sehr ähnlich sieht es in der betroffenen SUSE SAP Hana Umgebung tatsächlich aus.
Zumindest bin ich aber so weit, das es wohl eine Möglichkeit gibt, den Rechner erneut mit einem Linux-Live System zu starten und einen Eintrag in den EFI manuell nachzutragen, wie es hier: https://www.veeam.com/kb2669 beschrieben wird. Allerdings frage ich mich, warum dies nicht automatisch vom Veeam Linux Agent durchgeführt wird, bzw. wieso dies nicht vom Recovery Linux Medium aus machbar ist. Bei einer “typischen” SAP Hana Maschine mit 8TB RAM und 4 Prozessoren dauert der Reboot gerne einmal 45 Minuten. Aufgrund dieser dauer wäre es vermutlich schneller das SUSE Linux mit einem Script komplett neu zu installieren, anstelle ein Desaster Recovery durchzuführen… :-(
Bin komplett bei Dir. Ich habe schon mal einen Feature Request dafür eingestellt. Du könntest es für den nötigen Rückhalt auch via Support und Veeam Vertrieb eskalieren. Das sind ja keine kleinen Umgebungen, um die es hier geht.