Hallo an alle. Dies mag jemandem eine lehrreiche Geschichte darüber erscheinen, wie es sich nicht lohnt, etwas zu tun, und warum einige wichtige technische Arbeiten um ein Uhr morgens (in einem System, in dem Sie wenig verstehen) zu einem großen Zusammenbruch und Ausfallzeiten für zwei Tage führen können.
Eine kurze Notiz ist die Geschichte eines Amateur-Systemadministrators, der gerade erst anfängt, in die Welt der Virtualisierung einzutauchen. Die Geschichte, wie Schnappschüsse nicht geholfen haben, sondern das System gestört und einen Monat lang zurückgesetzt haben, und dann mit Ausfallzeiten in 2 Tagen alle Dateien von dort herausgezogen und das System zurückgegeben habe.
Hintergrund
Nachdem ich zwei Jahre auf nix- Systemen und insbesondere auf dem Ubuntu-Server (16.04 LTS) gesessen hatte, entschied ich mich, die Virtualisierung auszuprobieren. Ein Freund empfahl ESXi als kostenlose Lösung für kleine Server (mein Fall: 1 Prozessor + nur 8 GB RAM). Der Umzug wurde durch die Tatsache erschwert, dass Sie zuerst die VMware-Workstation mit dem VMware-Konverter auf dem Windows-Computer anheben, das fertige System dorthin übertragen, es dann auf den ESXI-Server heben und nach dem bekannten Konverter das System auf ESXI übertragen mussten. Dies ist eine so lange und schmerzhafte Reise. Der Hauptfehler während der Übertragung, den ich gemacht habe und der immer noch auf mir auftaucht, ist, dass ich eine dünne Festplatte verwendet habe. Das heißt, auf einem sauberen Ubuntu-Server mit einer in exfat-4 formatierten Festplatte hatte ich irgendwo 223,8 GB Speicherplatz auf ssd. Als ich zu esxi wechselte und die Festplatte für alles in ein unverständliches Format formatierte, verlor ich nur 300 MB, aber aufgrund dieser konnte ich keine dicke Festplatte erstellen, die ich (wie sich später herausstellte) so sehr brauchte.
Starten Sie
Früher habe ich mit einem Ubuntu-Server Brennholz zerbrochen (als ich es gerade „studiert“ habe), das System ein oder zwei Mal im Monat zurückgesetzt und neu installiert. Jetzt breche ich mit ESXi Brennholz. Ich denke, es besteht keine Notwendigkeit, das Problem der dünnen Festplatten zu beschreiben (kurz gesagt, nachdem sie ihren Speicherplatz erweitert haben, „verengen“ sie ihn nicht in die entgegengesetzte Richtung. Sie können auch über die physische Speichermenge auf der Festplatte hinausgehen). Erstens habe ich Swap auf demselben SSD-Laufwerk verwendet, ohne es in ESXi richtig eingerichtet zu haben. Er aß Erinnerung, schrieb dort einige temporäre Dateien und wurde inzwischen dünn.
Zweitens habe ich aus irgendeinem Grund Schnappschüsse gemacht. In diesem Moment ließ ich mich von der Tatsache leiten, dass "es praktisch, schnell und so ist". Ich ahnte immer noch nicht, was für ein Cack und was für eine langsame Bombe sie für mich gepflanzt haben. Drittens habe ich die schnell abnehmende Speichermenge auf der Festplatte nicht verfolgt.
Krawatte
Die erste Glocke war der Stopp des Hauptwagens am 17. Juli. In der Mail ist eine Benachrichtigung über den Sturz des Hosts eingegangen. Als ich in esxi ging, um es abzuholen (nun, plötzlich könnte etwas passieren), gab mir das virtuelle Mädchen angenehme Neuigkeiten (es gibt leider keinen Screenshot). Eine Freeware-Nacherzählung eines Popup-Fensters war so etwas wie „Entschuldigung, der Speicherplatz ist aufgebraucht. Ihre virtuelle Maschine wird gestoppt. Reinigen Sie den Platz und Sie können die VM weiter verwenden. Wiederholen Sie Abbrechen. Zu diesem Zeitpunkt wurde das Problem durch Entfernen der zweiten VM gelöst, die etwa 16 GB benötigte. Dies war jedoch eine vorübergehende Lösung, da jeden Tag immer noch 5 GB irgendwo verschwanden, obwohl das System diese Dateien nicht vergrößerte.
Infolgedessen schrieb ich am Abend des 19. Juli, an einem kühlen Donnerstag, zum ersten Mal auf dem Toaster über dieses Problem. Es gab keine Antwort. Ich denke, das liegt an dem unbeliebten esxi-Tag. Nach erfolglosem Google, nach - dem Entfernen von Schnappschüssen. In diesem Moment verschwanden 5 Gigabyte, der freie Speicherplatz wurde größer, aber nicht so sehr, dass dieses Problem vergessen wurde.
Nachdem ich mit ein wenig Verstand angefangen hatte, die Hierarchie der Schnappschüsse zu studieren. Der letzte, 000003, belegte zu diesem Zeitpunkt 12 GB Speicherplatz. In den VM-Einstellungen wurde es als aktive Festplattendatei aufgeführt, von der der Computer gestartet wurde. Ohne nachzudenken, löschte ich die Festplattendatei 1 mit der aktiven Snapshot-Festplatte und legte an ihrer Stelle die übergeordnete Festplatte der gesamten virtuellen Maschine ein.
Das System startete (Prost) und damit die Dateien für den 30. Juni. Datum der letzten Änderung aller Dateien auf der übergeordneten Festplatte. Ich vermute, dass ich an diesem Tag den ersten Schnappschuss erstellt habe. Logischerweise gab es keine Plätze mehr. Im freien Speicherplatz sind es immer noch ungefähr 5 GB, und die Dateien sind weg.
Die ersten Gedanken sind logisch: Was ich getan habe, sind alle Dateien bis zum 19. Juli verdunstet. Dann sah ich, dass die Snapshot-Dateien nicht gelöscht wurden. Als ich jedoch versuchte, sie als Hauptfestplatte zu laden, schwor ESXi auf die geänderte übergeordnete Festplatte, die nicht "Die übergeordnete virtuelle Festplatte wurde geändert, seit das Kind erstellt wurde" lauten sollte. Mein ewiger Fehler in den nächsten zwei Tagen.
Googeln
Die Zeit näherte sich um zwei Uhr morgens, und ich gab alle vergeblichen Versuche auf, zumindest einige Informationen aus diesen unglücklichen * -0000? -. Vmdk-Snapshot-Dateien zu erhalten.
Der Freitagmorgen begann mit einem aktiven, wirklich aktiven Google wie "Wie bekomme ich Dateien von VMDK?". Artikel, Linux-Reader (Windows-Programm) und alles, was sehr oft vorkam. Ich habe diese 223 Gigabyte vom Server auf den Windows-Laptop auf dem 100-Mbit-Kanal übertragen, was sehr schmerzhaft war. Ich habe versucht, eine SSD-Festplatte im VMware-Format auf einem Linux-System zu mounten, VMware-Tools darauf aufgerollt und sie schwor auf Inkompatibilität der Versionen (die letzte unterstützte war 5, aber ich hatte 6.5). Versuche, sich durch Fenster und Java zu öffnen, waren ebenfalls erfolglos.
Und selbst nachdem ich (mit dem Linux-Reader-Programm unter Windows) auf die Datei * -flat.vmdk zugreifen konnte, erhielt ich die Dateien nur bis zum 30. Juni. Alle weiteren Versuche, Snapshot-Dateien bereitzustellen, führten zu nichts. Das Programm fluchte auf einer ungültigen Festplatte und weigerte sich, weiter zu arbeiten.
Ausgabe gefunden
Freitag ist vorbei, ich war erschöpft und auch verärgert, dass die Dateien nicht zurückgegeben werden können. Aber der Samstag begann erfolgreich. Bei Google-Fehlern (warum ich es nicht sofort getan habe, ist unbekannt) "Die übergeordnete virtuelle Festplatte wurde geändert, seit das Kind erstellt wurde" in der ersten Zeile von Google gab einen Link zur VMware-Seite an. Eine Menge gruseliger Charaktere, rote Linien und alles, was sofort Angst hatte. Ich öffnete den Link und verließ ihn in der Hoffnung, etwas Verständlicheres zu finden.
Und es wurde gefunden. https://communities.vmware.com/thread/323730 Das russischsprachige VmWare-Forum und ein ähnliches Problem haben mich im Internet getroffen. Dies ist wahrscheinlich nicht der gleiche Fall wie bei mir, aber nachdem ich nach unten gescrollt und die Kommentare durchgelesen habe, habe ich versucht, dies zu tun.
In einem Texteditor, der über SFTP eine Verbindung zu esxi herstellte, öffnete ich die Datei mit den Einstellungen der übergeordneten Festplatte. .vmdk (nicht -flat.vmdk) Ich erkannte die CID der Festplatte und stieg dann in * -00001.vmdk auf, wie von der Person mit dem Spitznamen apavlyuchenko im Forum beschrieben.
Im ersten Snapshot sollten die Felder CID und parentCID die CID der übergeordneten Festplatte angeben. Und dann in der .vmx- Datei in den Feldern
scsi0: 1.present = "false"
scsi0: 1.fileName = " .vmdk"
scsi0: 1.deviceType = "scsi-hardDisk"
Ändern Sie den Parameter FALSE in TRUE und .vmdk in -00001.vmdk.
Und tatsächlich startete das Auto danach und schwor nicht auf den Fehler. Und siehe da! Dateien wurden angezeigt, bevor ein zweiter Schnappschuss erstellt wurde!
Im Forum beschrieb ein Freund eine Möglichkeit, Dateien aus nur einem Schnappschuss wiederherzustellen. Aber mein Fall ist schwierig (anscheinend wegen meiner Krankheit, die "alles mit den Händen auf eine Arbeitsmaschine stecken" heißt). Und ich hatte nicht einen Schnappschuss, sondern drei. Was logisch ist, war es notwendig, die Dateien weiter zu ändern.
Also meine Handlungen.
Öffnen Sie die übergeordnete Festplatte. Finden Sie seine CID heraus. Kopieren Sie als Nächstes die CID des übergeordneten Datenträgers in die übergeordnete CID-Zeile des Datenträgers -00001.vmdk (erster Snapshot). Dort sehen wir uns die CID dieses Snapshots an und kopieren sie in die parentCID-Zeile des Laufwerks -00002.vmdk (zweiter Snapshot). Dort sehen wir uns die CID dieses Snapshots an und kopieren sie in die parentCID-Zeile des Laufwerks -00003.vmdk (dritter Snapshot). Danach steigen wir in .vmx auf und geben den Namen der Snapshot-Datei in der fileName-Zeile an (in meinem Fall * -0003.vmdk).
Das Ergebnis ist das Folgende.
* .vmdk
CID = 387edddf
parentCID = ffffffff
* -00001.vmdk
CID = 0284jf712 (Ich habe alle CIDs fett gedruckt)
parentCID = 387edddf
* -00002.vmdk
CID = 732fhhtud
parentCID = 0284jf712
* -00003.vmdk
CID = 3747jfj4ff
parentCID = 732fhhtud
.vmx
scsi0: 1.present = "true"
scsi0: 1.fileName = " -00003.vmdk"
scsi0: 1.deviceType = "scsi-hardDisk"
Ich schalte die VM ein und sehe, dass die Daten wiederhergestellt sind. Es scheint loszulassen. Ich kopiere alles auf einen anderen Server, stoppe den Computer (er schreit bereits nach Festplattenfehlern und einigen anderen kritischen Problemen), gebe die * .vmx-Einstellungen zurück und kopiere die Dateien zurück auf den Arbeitscomputer. Hurra.
Fazit
Diese Geschichte lehrte mich einige goldene Wahrheiten, die vorher nicht verstanden werden konnten.
Sichern Sie zunächst immer und überall alles und nicht wie zuvor auf der Festplatte der virtuellen Maschine. Es ist erforderlich, ein oder sogar zwei Sicherungslaufwerke zu haben, damit keine solchen Ausfallzeiten von zwei Tagen auftreten. (Sind die Dateien verschwunden? Wir rollen zurück, kopieren die Dateien aus dem Backup und dem einfachen - nicht 48 Stunden, sondern 2 Stunden von der Truppe entfernt) Zweitens: Tun Sie um ein Uhr morgens nichts an meinem schweren Kopf (wenn ich ins Bett gehen würde, würde ich am Freitag mit einem sauberen Kopf kommen zu einem anderen Ausgang, aber in der zweiten Stunde der Nacht kein Brennholz zerbrochen) Drittens nehmen Sie keine wichtigen Änderungen an den Arbeitsmaschinen vor. Starten Sie die zweite virtuelle Maschine, machen Sie dort einen Schnappschuss, machen Sie dann das übergeordnete Laufwerk zum Hauptlaufwerk und sehen Sie, was danach passiert - so wurde es gemacht. Und viertens machen Sie noch mehr Backups. Nicht nur VM, sondern esxi selbst als Ganzes.
PS-Ressourcen, die mir endlich geholfen haben:
Das gleiche Forum mit erstaunlichen Apavlyuchenko (wir sind nicht vertraut, wenn das)
Seite zur Wissensdatenbank von vmvara mit einer Beschreibung meines Problems und Möglichkeiten, es zu lösen
Das Bild, das ich verwendet habe
Wenn jemand interessiert ist, kann ich in den Kommentaren die Ressourcen hinterlassen, deren Artikel mir nicht geholfen haben
Pss
Leider ist das Problem des Verschwindens des Ortes immer noch relevant. Wenn Sie Gedanken haben oder mir helfen möchten, damit umzugehen, kommentieren Sie bitte. Wir können dort darüber reden. Oder wenn Sie eine andere Möglichkeit kennen, Dateien von Snapshot-Datenträgern wiederherzustellen, und diese auch freigeben möchten, bin ich daran interessiert, sie zu lesen. Vielen Dank