Haftungsausschluss: Die Notiz dient der Unterhaltung. Die spezifische Dichte nützlicher Informationen darin ist gering. Es wurde „für mich selbst“ geschrieben.
Lyrische Einführung
Der Datei-Dump in unserer Organisation läuft auf einer virtuellen VMware ESXi 6-Maschine mit Windows Server 2016. Und das ist nicht nur ein Müll-Dump. Dies ist ein Dateiaustauschserver zwischen strukturellen Abteilungen: Es gibt Zusammenarbeit, Projektdokumentation und Ordner von Netzwerkscannern. Im Allgemeinen ist hier das gesamte Produktionsleben.
Und dieser Behälter allen Produktionslebens begann zu hängen. Darüber hinaus konnte sich der Gast ruhig erhängen, ohne die anderen zu beeinträchtigen. Er könnte den gesamten Host und dementsprechend alle anderen Gastmaschinen herunterfahren. Ich könnte mich selbst aufhängen und die vSphere-Client-Dienste hängen lassen: Das heißt, die Prozesse der anderen Gäste sind aktiv, die Maschinen funktionieren ordnungsgemäß und reagieren, aber es gibt keinen Dateiwascher und der vSphere-Client klammert sich nicht an den Host. Generell konnte kein System identifiziert werden. Tagsüber kann es bei geringer Auslastung zu Einfrierungen kommen. Sie könnten es nachts ohne Last tun. Könnte nachts bei differenziellem Backup und durchschnittlicher Auslastung möglich sein. Könnte an Wochenenden bei Vollsicherungen und hoher Auslastung möglich sein. Und es kam zu einer deutlichen Verschlechterung der Lage. Zuerst einmal im Jahr, dann alle sechs Monate. Am Ende meiner Geduld – zweimal pro Woche.
Ich hatte ein Gedächtnisproblem. Aber sie erlaubten mir nicht einmal am Wochenende, den Müllhaufen zu stoppen und Memtest durchzuführen. Wir warteten auf die Maiferien. Während der Maiferien habe ich Memtest ausgeführt und ... es wurden keine Fehler gefunden.
Ich war erstaunt und beschloss, in den Urlaub zu fahren. Während meines Urlaubs gab es keinen einzigen Aufhänger auf der Mülldeponie. Und als ich am Montag am ersten Tag wieder zur Arbeit ging, war dort ein Müllhaufen. Ich habe ein vollständiges Backup über mich ergehen lassen und habe mich direkt nach Abschluss aufgehängt. Ein so herzlicher Empfang aus dem Urlaub veranlasste mich zu der Entscheidung, die Festplatten mit dem Gastrechner physisch auf einen anderen Host zu übertragen.
Und obwohl es schon lange bekannt ist, dass man am ersten Tag nach dem Urlaub nichts Ernstes unternehmen kann, obwohl ich mich darauf vorbereitet habe, nicht den ganzen Weg zur Arbeit zu arbeiten, hat meine Empörung über ein weiteres Einfrieren sowohl meine als auch meine Stimmung getrübt Gelübde aus meinem Kopf...
Physische Festplatten wurden auf einen anderen Host verschoben. Heiße Verbindung. In den Speichereinstellungen auf der Registerkarte Antriebe / Festplatten erscheinen. Auf der Registerkarte Datenspeicher Auf diesen Datenträgern ist kein Speicherplatz vorhanden. Inspiration - erscheint nicht. Nun, natürlich der erste Impuls - Speicher hinzufügen. Der Add-Assistent erklärt, was er unterstützt. Natürlich unterstützt es auch VMFS. Ich habe nicht daran gezweifelt. Ein kurzer Blick auf die Meldungen des Assistenten bei jedem Schritt: Weiter, Weiter, Weiter, Fertig. Das Auge konnte den kleinen gelben Kreis mit einem Ausrufezeichen am unteren Rand des Fensters einer der Stufen des Meisters nicht einmal annähernd erkennen.
Am Ende des Assistenten erschien der neue Datenspeicher in der Liste … und zusammen mit ihm die Datenspeicher der verbleibenden physischen Festplatten.
Ich navigiere weiter durch den neu hinzugefügten Datenspeicher und er ist ... leer. Natürlich geriet ich wieder ins Staunen. Es ist 8 Uhr morgens, die ersten 15 Minuten auf der Arbeit nach dem Urlaub, ich habe noch nicht einmal den Zucker in meinem Kaffee gerührt. Und hier ist es. Der erste Gedanke war, dass ich die falsche Festplatte vom „nativen“ Host gezogen habe. Ich habe nachgeschaut, ob der erforderliche Datenspeicher im „nativen“ Host vorhanden war: Nein, er war nicht vorhanden. Der zweite Gedanke war: „Scheiße!“ Ich bin mir nicht sicher, aber es scheint mir, dass der dritte, vierte und zumindest fünfte Gedanke derselbe war.
Um Zweifel auszuräumen, installierte ich schnell einen neuen ESXi zum Testen, nahm die linke Diskette und ging, nachdem ich sie bereits gelesen hatte, die Schritte des Assistenten durch. Ja. Wenn Sie mit dem Assistenten einen Datenspeicher hinzufügen, gehen alle Daten auf der Festplatte verloren, ohne dass der Vorgang rückgängig gemacht und die Daten wiederhergestellt werden können. Später las ich in einem der Foren die Bewertung dieses Entwurfs durch einen Meister: Scheißer Mist. Und ich stimmte wirklich zu.
Ab dem sechsten gingen die Gedanken in eine konstruktivere Richtung. OK. Die Initialisierung dauert selbst bei einer 3-TB-Festplatte nur wenige Sekunden. Das ist also eine Formatierung auf hoher Ebene. Das bedeutet, dass die Partitionstabelle einfach neu geschrieben wurde. Die Daten sind also noch da. Also, jetzt suchen wir nach etwas Unformat und voilà.
Ich boote die Maschine vom Strelec-Boot-Image ... Und finde heraus, dass Programme zur Partitionswiederherstellung alles außer VMFS kennen. Sie kennen beispielsweise das Partitionslayout von Synology, nicht jedoch VMFS.
Das Durchsuchen von Programmen ist nicht beruhigend: GetDataBack und R.Saver finden bestenfalls NTFS-Partitionen mit einer Live-Verzeichnisstruktur und Live-Dateinamen. Aber das passt mir nicht. Ich benötige zwei VMDK-Dateien: die Systemfestplatte und die Papierkorbdatei.
Und dann verstehe ich, dass es so aussieht, als würde ich jetzt Windows installieren und von einem Datei-Backup aus ausrollen. Und gleichzeitig erinnere ich mich, dass ich dort einen DFS-Root hatte. Und auch ein System von Zugriffsrechten auf Abteilungsordner, das in seinem Umfang und seinen Auswirkungen absolut wild ist. Keine Option. Die einzig akzeptable Option besteht darin, den Zustand des Systems und der Festplatte mit Daten und allen Rechten wiederherzustellen.
Wieder Google, Foren, KB'shki und wieder Jaroslawnas Weinen: VMware ESXi bietet keinen Datenwiederherstellungsmechanismus. Alle Diskussionsthreads haben zwei Enden: Jemand wurde mit der teuren DiskInternals VMFS Recovery wiederhergestellt, oder jemandem wurde von einem Softwarespezialisten geholfen, der seine Dienste aktiv bewirbt vmfs-tools и dd. Die Option, eine DiskInternals VMFS Recovery-Lizenz für 700 US-Dollar zu erwerben, ist keine Option. Auch einem Außenstehenden aus dem „Territorium eines potenziellen Feindes“ den Zugriff auf Unternehmensdaten zu gestatten, ist keine Option. Es wurde aber gegoogelt, dass VMFS-Partitionen auch vom UFS-Explorer gelesen werden können.
DiskInternals VMFS-Wiederherstellung
Die Testversion wurde heruntergeladen und installiert. Das Programm hat die leere VMFS-Partition erfolgreich erkannt:
der Modus Wiederherstellen (Schnellscan) Ich habe auch einen schäbigen Datenspeicher mit Ordnern virtueller Maschinen mit Festplatten darin gefunden:
Die Vorschau zeigte, dass die Dateien lebendig sind:
Das Mounten der Partition in das System war erfolgreich, aber aus einem unbekannten Grund enthielten alle drei Ordner dieselbe virtuelle Maschine. Gemeinheit ist laut Gesetz natürlich nicht das Gebot der Stunde.
Drei Zeilen der SchandeDer Versuch, die Software schamlos zu sperren, scheiterte. Aber UFS Explorer ist blockiert.
Ich habe eine äußerst negative Einstellung gegenüber Softwarediebstahl. Ich ermutige in keiner Weise dazu, den Schutz vor unlizenzierter Nutzung zu umgehen.
Ich befand mich in einer katastrophalen Situation und war überhaupt nicht stolz auf die Maßnahmen, zu denen ich gegriffen hatte.
UFS-Explorer
Ein Festplattenscan ergab das Vorhandensein von 7 Knoten. Die Anzahl der Knoten stimmte „überraschenderweise“ mit der Anzahl der von VMFS Recovery erkannten *-flat.vmdk-Dateien überein:
Auch ein Vergleich von Dateigrößen und Knotengrößen ergab eine Übereinstimmung bis auf das Byte. Gleichzeitig wurden die Namen der *-flat.vmdk-Dateien und dementsprechend ihre Zugehörigkeit zu virtuellen Maschinen wiederhergestellt.
Im Allgemeinen bestehen vmdk-Festplatten aus ESXi-Sicht aus zwei Dateien: einer Datendatei (<Maschinenname>-flat.vmdk) und einer „physischen“ Festplattenlayoutdatei (<Maschinenname>.vmdk). Wenn Sie eine *-flat.vmdk-Datei von einem lokalen Computer in den Datenspeicher hochladen, erkennt ESXi sie nicht als gültige Festplattendatei. In der VMware-Wissensdatenbank finden Sie einen Artikel zum manuellen Erstellen einer Festplattendeskriptordatei: , aber ich musste das nicht tun, ich habe einfach den Inhalt der entsprechenden Dateien aus dem Dateiinhaltsvorschaubereich in DiskInternals VMFS Recovery kopiert:
Nach 4 Stunden Entladen eines 2,5-TB-Knotens aus UFS Explorer und 20 Stunden Laden in den Datenspeicher des Hypervisors wurden die abgestürzten Festplattendateien mit der neu erstellten virtuellen Maschine verbunden. Die Scheiben hoben an. Es wurde kein Datenverlust beobachtet.
Source: habr.com