Hyper-V-VMs sichern (bkp_hyperV)

Zum Inhaltsverzeichnis

bkp_hyperV sichert eine VM unter Hyper-V als einen VM-Run: alle virtuellen Festplatten, die Konfiguration und die Zustandsdateien der VM, bei einer VM mit vTPM also auch dessen Zustand. Grundlage ist ein Recovery-Checkpoint, wie ihn Microsoft für Sicherungsprogramme vorsieht: Die VM läuft während der Sicherung weiter. Nach der ersten Sicherung liest bkp_hyperV nur noch die Bereiche, die sich seitdem geändert haben (Resilient Change Tracking, RCT); unveränderte Teile übernimmt der Store aus dem vorigen Lauf, ohne sie zu lesen.

bkp_hyperV_restore legt aus einem VM-Run eine neue VM an (neue VM-ID, ausgeschaltet) oder stellt einzelne virtuelle Festplatten als neue VHDX-Dateien her. Vorhandene VMs und Dateien werden dabei nie verändert.

20.1 Voraussetzungen#

• Windows Server 2016 oder neuer mit der Hyper-V-Rolle; gesichert wird auf dem Host, nicht im Gast.
• Die Komponenten hyperv, agent und restore (Kapitel 2). Das Setup bietet hyperv nur an, wenn die Hyper-V-Rolle installiert ist.
• Für anwendungskonsistente Sicherungen den Integrationsdienst „Sicherung (Volumeschattenkopie)“ im Gast (bei Linux-Gästen hv_vss_daemon). Ohne ihn ist die Sicherung absturzkonsistent, wie nach einem Stromausfall; Protokoll und Ergebnis nennen das.
• Ein Einzelhost. Failover-Cluster mit CSV, Pass-Through-Disks, gemeinsam genutzte VHDX und abgeschirmte VMs (Shielded VMs) werden noch nicht unterstützt.

20.2 Sichern#

Eine VM sichern (Ziele aus sinks.cfg, Kapitel 4)

bkp_hyperV --vm dc01 --sink rz1
bkp_hyperV --vm dc01 --disk scsi0-0 -- --sink rz1 --sink lokal

Ablauf eines Laufs: bkp_hyperV legt den Checkpoint „cybackup <name>“ an, liest dessen Konfiguration, hängt jede virtuelle Festplatte des Checkpoints schreibgeschützt an und lässt bkp_agent nur die geänderten Bereiche lesen. Danach folgen die Dateien der VM (vmcx, vmgs, vmrs). Ist der VM-Run gespeichert, wird der Checkpoint zum Referenzpunkt für die nächste Sicherung; ältere Referenzpunkte dieses Backup-Namens werden entfernt. Schlägt der Lauf fehl oder wird er abgebrochen, löscht bkp_hyperV den Checkpoint, und der bisherige Referenzpunkt bleibt die Grundlage.

Ganz gelesen wird eine Disk ohne Referenzpunkt (erste Sicherung), nach dem Vergrößern der Disk, nach einer Migration oder einem Speicherumzug der VM und mit --full. Das Protokoll nennt den Grund sachlich; das ist kein Fehler.

Ist ein Volume im Gast mit BitLocker verschlüsselt, sieht bkp_hyperV von außen nicht, welcher Platz darin frei ist: Das Volume wird beim ersten Mal so weit gelesen, wie die VHDX Daten enthält, danach wie immer nur die geänderten Bereiche. Verschlüsselte Daten lassen sich weder komprimieren noch deduplizieren; im Store belegen sie etwa so viel wie in der VHDX.

20.3 Einstellungen je VM und Job im Planer#

%ProgramData%\AegisGrid\bkp_hyperv.cfg

[dc01]
vm=dc01
consistency=app
sinks=rz1,lokal
retention=30d

Mit diesem Abschnitt genügt bkp_hyperV --name dc01. Ziele, Zertifikate und Schlüssel stehen wie beim Agent in sinks.cfg. Geplant wird die Sicherung im Job-Planer mit command=hyperv; der Profilname geht als --name an bkp_hyperV:

%ProgramData%\AegisGrid\bkp_sched.cfg

[dc01-nachts]
command=hyperv
profile=dc01
schedule=0 1 * * *

In der Verwaltungskonsole heißt der Befehl „Hyper-V-VM sichern (bkp_hyperV)“; das Feld „Weitere Parameter“ nimmt z. B. --vm dc01 auf, wenn das Profil keine VM nennt. Die Benachrichtigungsmail und die Laufliste der API nennen je Lauf Disks, Dateien der VM und die erreichte Konsistenz. Wird ein Job abgebrochen, entfernt der Planer danach den Checkpoint (--discard-interrupted); die VM bleibt unverändert.

20.4 Wiederherstellen#

Eine VM als neue VM herstellen

bkp_hyperV_restore --name dc01 --dest D:\VMs --dry-run
bkp_hyperV_restore --name dc01 --dest D:\VMs
bkp_hyperV_restore --name dc01 --at "2026-10-19 22:00" --switch LAN=LAN-Test --new-name dc01-test

Die neue VM heißt <name>_bkp01, beim nächsten Restore <name>_bkp02 usw. (die erste freie Nummer); --new-name gibt einen anderen Namen vor, ein vergebener Name wird abgelehnt. Unter --dest entsteht der Ordner der VM mit „Virtual Machines“ und „Virtual Hard Disks“. Bootreihenfolge, Secure Boot, CPU, Arbeitsspeicher und der vTPM-Zustand kommen mit. Die VM bleibt ausgeschaltet, damit Netzwerk und Einstellungen vor dem ersten Start geprüft werden können.

Wird ein Restore abgebrochen, entfernt bkp_hyperV_restore alles, was er angelegt hat. Eine einzelne Disk geht auch mit bkp_restore --disk scsi0-0 (Kapitel 7); bkp_restore --disk vmgs holt eine einzelne Datei der VM zurück.

20.5 vTPM und Guardian#

Der vTPM-Zustand einer VM ist mit ihrem Schlüsselschutz verschlüsselt. Öffnen kann ihn nur ein Host, der die Zertifikate eines Guardians dieses Schlüsselschutzes samt privatem Schlüssel hat, auf einem Einzelhost der eigene Guardian „UntrustedGuardian“ im Zertifikatspeicher „Shielded VM Local Certificates“ des lokalen Computers. Auf dem Host, auf dem gesichert wurde, startet die wiederhergestellte VM deshalb mit ihrem TPM; ein Gast mit BitLocker braucht keinen Wiederherstellungsschlüssel.

bkp_hyperV_restore prüft vor dem ersten Schritt, ob der Host einen Guardian der VM hat, und nennt ihn im Protokoll. Fehlt er, legt der Restore nichts an und sagt, was zu tun ist. Ohne die Zertifikate könnte Hyper-V die VM nicht starten („Die Schlüsselschutzvorrichtung konnte nicht entpackt werden“).

• Für einen Totalausfall vorsorgen: bkp_hyperV --with-guardian (im Profil with-guardian=yes) sichert die beiden Zertifikate des Guardians mit privatem Schlüssel als vierte Datei der VM (guardian). Weil damit jede VM dieses Guardians geöffnet werden kann, geht das nur in verschlüsselte Sinks (encryption= und key= in sinks.cfg, Kapitel 4). Ist ein Sink unverschlüsselt, sichert bkp_hyperV nichts und sagt, welcher; die VM bleibt unberührt.
• Auf einem neuen Host wiederherstellen: bkp_hyperV_restore --import-guardian übernimmt die gesicherten Zertifikate zuerst in den Zertifikatspeicher und legt dann die VM an. Die Zertifikate bleiben dort; sie öffnen danach auch die anderen gesicherten VMs desselben Guardians. Der eigene Guardian des Hosts bleibt unverändert.
• Zertifikate von Hand: Wer sie selbst verwahrt (PFX mit privatem Schlüssel), importiert sie in „Shielded VM Local Certificates“ des lokalen Computers und stellt danach wie gewohnt wieder her.
• --without-guardian legt die VM trotzdem an, etwa um an ihre Daten zu kommen; starten lässt sie sich erst mit den Zertifikaten.

Guardian mitsichern und auf einem neuen Host übernehmen

bkp_hyperV --vm dc01 --with-guardian -- --sink rz1-verschluesselt
bkp_hyperV_restore --name dc01 --sink rz1-verschluesselt --import-guardian