Der Austausch von Festplatten bei einem stand-alone Hyper-V Host erschien zunächst recht einfach, allerdings kam es im Laufe des Vorgangs zu unerwarteten Komplikationen die glücklicherweise gelöst werden konnten.

Die Aufgabe

Bei einem stand-alone Hyper-V Host sollten die vier Festplatten eines RAID10 von SATA- durch SAS-Festplatten ersetzt werden. Dies sollte in der Art erfolgen, das zunächst alle virtuellen Computer gespeichert werden, dann eine Datensicherung des Hosts erfolgt, die Festplatten ausgetauscht und die Datensicherung wieder eingespielt wird.

Zu Bemerken ist, das auf dem RAID10 zwei Partitionen vorhanden sind: Eine Partition für die Parent Partition des Hyper-V, der Rest für die virtuellen Computer.

Die Datensicherung

Die Datensicherung erfolgte mit Drive Snapshot zunächst schnell und erfolgreich. Insgesamt musste gut 1 TB gesichert werden.

Die Wiederherstellung, Teil I

Während die Wiederherstellung der Windows-Partition erfolgreich und schnell verlief, kam es beim Wiederherstellen der Daten-Partition zu einem Checksum-Error:

17:34:04 Snapshot error RESTORE, line 1258
17:34:04 illegal checksum error at offset 47bc3f4736
         recordsize e595 - checksum is dc95397a - should be a6fb3e63

Aufgrund dieses Fehlers wurde die Wiederherstellung zunächst abgebrochen, wohlgemerkt durch den Benutzer, denn scheinbar lief Drive Snapshot weiter. Allerdings war unklar, was dann das Endergebnis sein würde.

Bemerkung: Da dieser Fehler im Nachhinein nicht mehr reproduziert werden konnte, handelt es sich vermutlich um einen Übertragungsfehler am USB, da eine externe Festplatte für die Datensicherung zum Einsatz kam.

Die Wiederherstellung, Teil II

Da die eigentlich angedachte Wiederherstellung scheiterte wurde auf Plan B zurückgegriffen, der vorsah, den Host zu starten, die Datensicherung einzuhängen und die virtuellen Computer über den Explorer zu kopieren.

Diese wurde so durchgeführt und schien zunächst erfolgreich zu sein bis zu dem Moment, an dem man versuchte die gespeicherten virtuellen Computer zu starten. Es kam zu einer Meldung die unter anderem “Fehler beim Initialisieren” enthielt.

Schnell war klar, das wohl beim simplen Kopieren etwas verloren gegangen sein muss. Ein Blick auf die Berechtigungen der *.vsv-Dateien in der Datensicherung, Diese gehören zum gespeicherten Zustand von virtuellen Computern, zeigt das dort Rechte gesetzt waren, die man so einfach im System nicht findet:

Hyper-V - *.vsv-Rechte

Ferner findet man auf diversen Ordnern noch weitere Rechte:

Hyper-V Ordner-RechteDamit war geklärt, das es sich um ein Zugriffsproblem mangels Berechtigung handelte. Da diese Gruppen im System nicht auffindbar sind, wurde kurzerhand per robocopy ein erneuter Kopiervorgang gestartet. Allerdings wurde angegeben, das die Berechtigungen mit kopiert werden sollten:

@echo off

set source="Z:\Hyper-V" 
set destination="D:\Hyper-V"

robocopy %source% %destination% /mir /copyall /r:0 /w:0 /log:robocopy-log.txt /tee

Die Option “/copyall” sorgt dafür, das alle Attribute, Berechtigungen, Zeitstempel usw. kopiert werden.

Damit das Kopieren überhaupt möglich ist, muss der Dienst “Hyper-V-Verwaltung für virtuelle Computer” zuvor beendet werden.

Nach dem erfolgreichen Kopieren und dem Starten des Dienstes, ist dann das Starten der  gespeicherten virtuellen Computer ebenfalls möglich.

Persönliche Bemerkung

“Erstens kommt es anders und zweitens als man denkt!” sagt man so schön. Das gilt auch für diesen Fall, wenigstens gab es sonst keine Überraschungen mehr und man hat sogar noch etwas dazu gelernt.

Meine grösste Sorge war ursprünglich das Windows womöglich auf dem neuen RAID nicht booten möchte. So stellte ich mich seelisch und moralisch auf eine Startreparatur ein. Als dann allerdings der Checksum-Error auflief, war die Überraschung groß.

Windows wiederum startete ohne Probleme. Die Rechte-Thematik bei den virtuellen Computern war letztlich lehrreich.