Wiederherstellung virtueller Maschinen von fälschlicherweise initialisiertem Datastore. Eine Geschichte einer Dummheit mit Happy End

Haftungsausschluss: Die Notiz hat einen unterhaltsamen Charakter. Der Anteil an nützlichen Informationen ist gering. Sie wurde "für mich selbst" geschrieben.

Lyrische Einleitung

Die Dateimüllhalde in unserer Organisation läuft auf einer virtuellen Maschine VMware ESXi 6 unter Windows Server 2016. Und das ist nicht einfach eine Müllhalde. Es ist ein Server für den Dateiaustausch zwischen den Fachabteilungen: hier gibt es gemeinsame Arbeiten, Projektdokumentationen und Ordner von Netzwerkscannern. Kurz gesagt, hier spielt sich das gesamte Produktionsleben ab.

Und plötzlich begann dieses Reservoir des gesamten Produktionslebens zu hängen. Dabei konnte die Gastmaschine still und heimlich einfrieren, ohne die anderen zu beeinträchtigen. Sie konnte den gesamten Host und somit alle anderen Gastmaschinen zum Absturz bringen. Sie konnte selbst einfrieren und die Client-Dienste von vSphere blockieren: die Prozesse der anderen Gäste liefen zwar, die Maschinen arbeiteten einwandfrei und antworteten, aber die Dateimüllhalde war nicht mehr verfügbar und der vSphere Client konnte sich nicht mit dem Host verbinden. Kurz gesagt, es war unmöglich, ein System zu erkennen. Die Ausfälle konnten tagsüber bei geringer Auslastung auftreten. Sie konnten nachts bei Nullauslastung passieren. Sie konnten nachts während einer differenziellen Sicherung und mittlerer Auslastung auftreten. Sie konnten am Wochenende während eines vollständigen Backups und hoher Auslastung geschehen. Es wurde eine deutliche Verschlechterung der Situation festgestellt. Zunächst geschah es einmal im Jahr, dann einmal alle sechs Monate. Am Ende meines Geduld war es zweimal in der Woche.
Ich machte die RAM verantwortlich. Aber ich konnte die Müllhalde nicht einmal am Wochenende anhalten und Memtest durchführen. Man wartete auf die Maifeiertage. Während dieser Ferien führte ich Memtest durch und... es wurden keine Fehler gefunden.

Ich war erstaunt und beschloss, Urlaub zu nehmen. Während meines Urlaubs gab es keine einzigen Ausfälle an der Müllhalde. Und als ich am Montag meinen ersten Arbeitstag hatte, hing die Müllhalde. Sie hielt das vollständige Backup aus und hing genau am Ende davon. Diese herzliche Rückkehr vom Urlaub motivierte mich, die Festplatten der Gastmaschine physisch in einen anderen Host zu übertragen.

Und obwohl es schon lange bekannt ist, dass man am ersten Tag nach dem Urlaub nichts Ernstes machen sollte, obwohl ich mich während der gesamten Fahrt zur Arbeit vorgenommen hatte, nicht zu arbeiten, war mein Unmut über das erneute Hängen der Müllhalde so groß, dass ich sowohl meinen Plan als auch meine Vorsätze aus dem Kopf verlor...

Die physischen Festplatten wurden in einen anderen Host versetzt. Hot-Swap. In den Speicher-Einstellungen unter dem Tab Laufwerke Es erscheinen Datenträger. Auf dem Tab Datenspeicher sind auf diesen Datenträgern — nicht vorhanden. Aktualisieren — erscheinen nicht. Nun ja, und natürlich ist der erste Impuls — Speicher hinzufügen. Der Assistent zum Hinzufügen erklärt, dass er unterstützt. Natürlich unterstützt er auch VMFS. Daran hatte ich keinen Zweifel. Ein flüchtiger Blick auf die Meldungen des Assistenten bei jedem Schritt: Weiter, Weiter, Weiter, Fertig. Mein Blick wurde nicht einmal von dem kleinen gelben Kreis mit dem Ausrufezeichen unten im Fenster eines der Schritte des Assistenten angezogen.

Nach Abschluss des Assistenten erschien der neue Datenspeicher in der Liste… und zusammen mit ihm auch die Datenspeicher von den anderen physischen Datenträgern.

Ich wechsle zur Navigation durch den gerade hinzugefügten Datenspeicher, und er ist… leer. Natürlich war ich erneut erstaunt. Es ist 8 Uhr morgens, die ersten 15 Minuten bei der Arbeit nach dem Urlaub, ich habe noch nicht einmal den Zucker in meinem Kaffee umgerührt. Und dann so etwas. Der erste Gedanke war — nicht der richtige Datenträger vom „stammenden“ Host gezogen. Ich habe geschaut, ob der gesuchte Datenspeicher im „stammenden“ Host vorhanden ist: nein, ist nicht vorhanden. Der zweite Gedanke war: „Verdammtes Mist!“ Ich bin mir nicht sicher, aber ich glaube, dass der dritte, vierte und mindestens fünfte Gedanke ähnlich waren.

Um Zweifel auszuräumen, habe ich schnell einen neuen ESXi zur Probe installiert, habe einen anderen Datenträger genommen und bin, während ich lese, die Schritte des Assistenten durchgegangen. Ja. Beim Hinzufügen des Datenspeichers mit Hilfe des Assistenten kommt es zum Verlust aller Daten auf dem Datenträger, ohne Möglichkeit, die Operation rückgängig zu machen und die Daten wiederherzustellen. Später las ich in einem forum eine Einschätzung dieses Designs des Assistenten: shitsome crap. Und ich stimmte ihm wirklich zu.

Ab dem sechsten — flossen die Gedanken in konstruktivere Bahnen. Gut. Die Initialisierung dauert nur wenige Sekunden, selbst für eine 3-TB-Disk. Das bedeutet, es handelt sich um eine hochgradige Formatierung. Das heißt, die Partitionstabelle wurde einfach überschrieben. Das bedeutet, die Daten sind noch da. Das bedeutet, jetzt suchen wir nach einem unformat und voila.

Ich lade die Maschine mit dem Startimage von Strelec… und stelle fest, dass die Wiederherstellungsprogramme für Partitionen alles wissen, außer VMFS. Die Partitionierung von Synology zum Beispiel ist bekannt, aber VMFS nicht.

Die Suche nach Programmen ist nicht vielversprechend: bestenfalls finden GetDataBack und R.Saver NTFS-Partitionen mit einer intakten Verzeichnisstruktur und gültigen Dateinamen. Aber das reicht mir nicht. Ich brauche zwei vmdk-Dateien: mit der Systemdisk und der Disk für temporäre Dateien.

Und hier wird mir klar, dass ich wohl jetzt Windows installieren und aus einem Datei-Backup wiederherstellen werde. Gleichzeitig erinnere ich mich daran, dass ich dort den DFS-Wurzel hatte. Und noch ein völlig wildes System von Zugriffsrechten auf die Ordner der Abteilungen, das in seinem Umfang und seiner Komplexität enorm ist. Keine Option. Die einzige zeitlich akzeptable Option ist die Wiederherstellung des Systems und der Datenplatte mit allen Rechten.

Wieder Googeln, Foren, KB-Artikel und wieder das Wehklagen der Jaroslawa: VMware ESXi sieht keinen Mechanismus zur Datenwiederherstellung vor. Alle Diskussionsstränge haben zwei Enden: Jemand hat sich mit der nicht günstigen DiskInternals VMFS Recovery wiederhergestellt oder einer wurde von einem Spezialisten, der seine Dienstleistungen aktiv anbietet, unterstützt. vmfs-tools und dd. Die Option, eine Lizenz für DiskInternals VMFS Recovery für 700 $ zu kaufen – ist keine Option. Den Zugang einer dritten Person aus dem "Gebiet eines potenziellen Gegners" zu Unternehmensdaten zu ermöglichen – ist ebenfalls keine Option. Allerdings wurde herausgefunden, dass UFS Explorer VMFS-Partitionen ebenfalls lesen kann.

DiskInternals VMFS Recovery

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

Im Modus Undelete (Schnellscan) fand auch den beschädigten Datastore mit Ordnern virtuelle Maschinen mit Platten darin:

Die Vorschau zeigte, dass die Dateien intakt sind:

Das Einbinden der Partition ins System war erfolgreich, aber aus unerklärlichen Gründen waren in allen drei Ordnern dieselbe virtuelle Maschine. Natürlich war es nach dem Gesetz der Schikane nicht die benötigte.

Drei Zeilen des SchamsDer Versuch, die Software schamlos zu piratieren, endete in einer Katastrophe. Allerdings konnte ich UFS Explorer verwenden.

Ich lehne Softwarediebstahl äußerst negativ ab. Ich fordere auf keinen Fall dazu auf, Mittel zu verwenden, um Schutzmaßnahmen gegen unlizenzierte Nutzung zu umgehen.

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

UFS Explorer

Das Scannen der Festplatte ergab, dass 7 Knoten vorhanden sind. Die Anzahl der Knoten stimmte "erstaunlicherweise" mit der Anzahl der *-flat.vmdk-Dateien überein, die von VMFS Recovery gefunden wurden:

Der Vergleich der Dateigrößen und der Knoten zeigte ebenfalls eine Übereinstimmung bis ins Byte. Zudem wurden die Namen der *-flat.vmdk-Dateien wiederhergestellt und somit deren Zugehörigkeit zu den virtuellen Maschinen.

Im Allgemeinen bestehen vmdk-Diskdateien aus Sicht von ESXi aus zwei Dateien: einer Datei mit den Daten (-flat.vmdk) und einer Datei mit der „physikalischen“ Struktur der Festplatte (.vmdk). Wenn die *-flat.vmdk-Datei von einem lokalen Rechner in den Datastore hochgeladen wird, erkennt ESXi sie nicht als gültige Festplattendatei. In der VMware-Wissensdatenbank gibt es einen Artikel, wie man die Deskriptordatei manuell erstellt: kb.vmware.com/s/article/1002511, aber das musste ich nicht tun, ich habe einfach den Inhalt der entsprechenden Dateien aus der Vorschau im DiskInternals VMFS Recovery kopiert:

Nach 4 Stunden, in denen 2,5 TB des Knotens aus dem UFS Explorer exportiert wurden, und 20 Stunden, in denen sie in den Datastore des Hypervisors hochgeladen wurden, wurden die beschädigten Festplattendateien an eine frisch erstellte virtuelle Maschine angeschlossen. Die Festplatten wurden erkannt. Es wurden keine Datenverluste festgestellt.

Quelle: habr.com