Wiederherstellung virtueller Maschinen aus einem fälschlicherweise initialisierten Datastore. Eine Geschichte von einem Missgeschick mit Happy End

Haftungsausschluss: Diese Notiz dient zu Unterhaltungszwecken und enthält wenig nützliche Informationen. Sie wurde "für mich selbst" geschrieben.

Lyrische Einleitung

Unser Dateispeicher läuft auf einer virtuellen Maschine mit VMware ESXi 6 unter Windows Server 2016. Und es ist nicht einfach ein Speicher. Es ist ein Austauschserver für Dateien zwischen unseren Abteilungen: hier finden gemeinsame Arbeiten, Projektdokumentationen und Ordner von Netzwerkscannern statt. Kurz gesagt, hier läuft das gesamte Produktionsleben.

Und so begann der gesamte Produktionsbetrieb zu stocken. Der Gast konnte dabei still hängen bleiben, ohne die anderen zu beeinträchtigen. Er konnte den gesamten Host mit sich ins Abseits ziehen und damit alle anderen Gastmaschinen zum Stillstand bringen. Ein einzelner Gast konnte hängen bleiben und die vSphere-Dienste der Kunden lahmlegen: Das heißt, die Prozesse der anderen Gäste liefen weiter, die Maschinen arbeiteten aktiv und reagierten, aber der Dateiserver war nicht erreichbar und der vSphere-Client konnte sich nicht mit dem Host verbinden. Kurz gesagt, es war unmöglich, ein System zu identifizieren. Die Ausfälle konnten tagsüber bei geringer Auslastung auftreten. Sie traten nachts bei null Auslastung auf. Sie konnten nachts während des differenziellen Backups und bei mittlerer Auslastung geschehen. An Wochenenden während vollständiger Backups und hoher Auslastung wurden sie ebenfalls beobachtet. Es gab eine deutliche Verschlechterung der Situation. Zuerst einmal im Jahr, dann alle sechs Monate. Gegen Ende meiner Geduld — zweimal pro Woche.
Ich vermutete ein Problem mit dem Arbeitsspeicher. Doch man ließ mich auch am Wochenende nicht die Junk-Files anhalten und Memtest durchführen. Wir warteten auf die Maifeiertage. In den Maifeiertagen führte ich Memtest aus und… es wurden keine Fehler gefunden.

Ich war erstaunt und beschloss, Urlaub zu nehmen. Während meines Urlaubs gab es an der Mülltonne keine Ausfälle. Doch als ich am Montag wieder zur Arbeit kam, war die Mülltonne abgestürzt. Sie hat das vollständige Backup überstanden und genau nach dessen Abschluss ist sie hängen geblieben. Diese herzliche Rückkehr aus dem Urlaub hat mich dazu bewegt, die Festplatten der virtuellen Maschine auf einen anderen Host zu verschieben.

Und obwohl es bekannt ist, dass man am ersten Tag nach dem Urlaub nichts Ernstes tun sollte, habe ich mir den ganzen Weg zur Arbeit vorgenommen, nicht zu arbeiten. Mein Unmut über den erneuten Ausfall hat mir jedoch den Fokus und meine Vorsätze aus dem Kopf geschlagen...

Die physischen Festplatten wurden auf einen anderen Host verschoben. Heißes Pluggen. In den Speicher-Einstellungen unter dem Tab Drives erscheinen die Festplatten. Im Tab Datastores gibt es diese Festplatten – nicht. Aktualisieren – erscheinen nicht. Und natürlich ist der erste Impuls – Add Storage. Der Assistent für das Hinzufügen erklärt, dass er unterstützt. Natürlich unterstützt er auch VMFS. Das habe ich mir schon gedacht. Ein flüchtiger Blick auf die Nachrichten des Assistenten bei jedem Schritt: Weiter, Weiter, Weiter, Fertig. Mein Blick blieb nicht einmal ansatzweise an dem kleinen gelben Kreis mit dem Ausrufezeichen unten im Fenster eines der Schritte des Assistenten hängen.

Nachdem der Assistent abgeschlossen war, erschien der neue Datenspeicher in der Liste… und zusammen mit ihm auch die Datenspeicher von den anderen physischen Festplatten.

Ich gehe zur Navigation des gerade hinzugefügten Datenspeichers, und er ist… leer. Natürlich war ich wieder erstaunt. Es ist 8 Uhr morgens, die ersten 15 Minuten im Büro nach dem Urlaub, ich habe nicht einmal den Zucker in meinen Kaffee gerührt. Und dann das. Der erste Gedanke war – nicht die richtige Festplatte vom 'stammenden' Host gezogen. Ich habe geschaut, ob der gesuchte Datenspeicher im 'stammenden' Host vorhanden ist: Nein, er ist nicht vorhanden. Der zweite Gedanke war: 'Verdammtes!' Ich bin mir nicht sicher, aber ich glaube, der dritte, vierte und mindestens fünfte Gedanke waren ähnlich.

Um Zweifel auszuräumen, habe ich schnell eine frische ESXi-Version installiert, eine beliebige Festplatte verwendet und bin währenddessen die Schritte des Assistenten durchgegangen. Ja. Beim Hinzufügen eines Datastores über den Assistenten werden alle Daten auf der Festplatte ohne Möglichkeit zur Rückgängigmachung der Operation und Wiederherstellung der Daten gelöscht. Später habe ich in einem Forum eine Bewertung dieses Designs des Assistenten gelesen: shitsome crap. Dem kann ich nur zustimmen.

Ab der sechsten - die Gedanken flossen in eine konstruktivere Richtung. Gut. Die Initialisierung dauert nur wenige Sekunden, selbst bei einer 3TB-Festplatte. Das bedeutet, es handelt sich um eine Hochformatierung. Das bedeutet, die Partitionstabelle wurde einfach neu geschrieben. Das bedeutet, die Daten sind noch da. Das bedeutet, wir suchen jetzt nach einem unformat und voila.

Ich lade die Maschine mit einem Boot-Image von Strelec... und stelle fest, dass die Wiederherstellungsprogramme für Partitionen alles wissen, außer VMFS. Die Partitionierung von Synology kennen sie, aber VMFS – nicht.

Die Auswahl der Programme ist wenig tröstlich: Im besten Fall finden GetDataBack und R.Saver NTFS-Partitionen mit einer aktiven Verzeichnisstruktur und aktiven Dateinamen. Aber das reicht mir nicht. Ich benötige zwei vmdk-Dateien: eine für das Systemlaufwerk und eine für das Schrott-Laufwerk.

Und da wird mir klar, dass ich anscheinend jetzt Windows installieren und aus einem Datei-Backup wiederherstellen werde. Gleichzeitig erinnere ich mich, dass ich dort ein DFS-Wurzelverzeichnis hatte. Außerdem gibt es ein völlig verrücktes System von Zugriffsrechten für die Ordner der Abteilungen, das sehr umfangreich und kompliziert ist. Das ist keine Option. Die einzige akzeptable Option, die zeitlich sinnvoll ist, besteht darin, den Zustand des Systems und der Datenplatten mit allen Rechten wiederherzustellen.

Wieder googeln, Foren durchsuchen, KB-Artikel und erneut das Wehklagen von Jammern: VMware ESXi bietet keinen Mechanismus zur Datenwiederherstellung. Alle Gesprächsstränge haben zwei Enden: Jemand hat sich mit dem nicht günstigen DiskInternals VMFS Recovery wiederhergestellt oder jemanden hat ein Spezialist geholfen, der seine Dienste aktiv anbietet. vmfs-tools und dd. Die Option, eine Lizenz für DiskInternals VMFS Recovery für 700 $ zu kaufen, ist keine Option. Der Zugang einer dritten Person aus "dem Gebiet eines potenziellen Gegners" zu Unternehmensdaten ist ebenfalls keine Option. Allerdings wurde recherchiert, dass UFS Explorer auch VMFS-Partitionen lesen kann.

DiskInternals VMFS Recovery

Die Testversion wurde heruntergeladen und installiert. Das Programm hat erfolgreich die leere VMFS-Partition erkannt:

Im Modus Undelete (Schnellscan) wurde auch der beschädigte Datenspeicher mit Ordnern virtuellen Maschinen und Platten darin gefunden:

Die Vorschau hat gezeigt, dass die Dateien intakt sind:

Das Einbinden der Partition in das System war erfolgreich, aber aus unerklärlichen Gründen gab es in allen drei Ordnern dieselbe Virtual Machine. Natürlich ist es ironisch – nicht die, die benötigt wird.

Drei Zeilen der SchandeDer Versuch, die Software dreist zu piratieren, endete in einem Fiasko. Stattdessen wurde UFS Explorer aktiviert.

Ich stehe dem Softwarediebstahl äußerst negativ gegenüber. Auf keinen Fall fordere ich zur Nutzung von Methoden zur Umgehung des Schutzes vor illegaler Nutzung auf.

Ich befand mich in einer katastrophalen Lage und war keineswegs stolz auf die Maßnahmen, zu denen ich gegriffen habe.

UFS Explorer

Der Scan der Festplatte zeigte 7 Nodes. Die Anzahl der Nodes stimmte «überraschenderweise» mit der Anzahl der *-flat.vmdk Dateien, die in VMFS Recovery gefunden wurden, überein:

Der Vergleich der Dateigrößen und der Größen der Nodes zeigte ebenfalls eine Übereinstimmung bis auf das Byte. Zudem wurden die Namen der *-flat.vmdk Dateien wiederhergestellt und damit auch ihre Zuordnung zu den virtuellen Maschinen.

Im Allgemeinen bestehen vmdk-Disketten aus der Sicht von ESXi aus zwei Dateien: einer Datendatei (<Maschinenname>-flat.vmdk) und einer Datei für die "physikalische" Disk-Layout (<Maschinenname>.vmdk). Wenn die *-flat.vmdk-Datei von einem lokalen Rechner in den Datastore hochgeladen wird, erkennt ESXi diese nicht als gültige Disk-Datei. In der VMware-Wissensdatenbank gibt es einen Artikel darüber, wie man manuell eine Disk-Descriptor-Datei erstellt: kb.vmware.com/s/article/1002511, aber ich musste das nicht tun; ich habe einfach den Inhalt der entsprechenden Dateien aus dem Vorschau-Bereich in DiskInternals VMFS Recovery kopiert:

Nach 4 Stunden Export einer 2,5 TB Node aus UFS Explorer und 20 Stunden Upload in den Datastore wurden die beschädigten Disk-Dateien an eine neu erstellte virtuelle Maschine angeschlossen. Die Disketten wurden erkannt. Es wurden keine Datenverluste festgestellt.

Quelle: habr.com