Das Forum wurde aktualisiert. Wurde höchste Zeit. Wenn etwas nicht funktioniert, bitte gerne hier jederzeit melden.
(Das "alte Design" kommt wieder, wird ne Weile brauchen!)

Problem mit Snapshot und Konsolidierung

Moderatoren: irix, continuum, Dayworker, Tschoergez

Member
Beiträge: 4
Registriert: 21.04.2015, 07:47

Problem mit Snapshot und Konsolidierung

Beitragvon markusa » 21.04.2015, 08:15

Hallo zusammen,

ich habe eine VM (Original-VM) mit drei angehängten Platten. Es sollte ein Umzug der Daten in eine neue VM stattfinden. Snapshots wurden im vSphere Client nicht angezeigt. daraufhin habe ich die Basis-Festplatten (bei ausgeschalteter VM) an das Zielsystem angefügt und wollte die Daten umkopieren.
Dabei viel mir auf, dass ein Snapshot vorhanden sein muss und nur "alte" Daten auf den Basisplatten da sind.

Also habe ich die VMDKs von der Ziel-VM wieder entfernt. Daraufhin startete die Original-VM nicht mehr und zeigte an, dass eine Konsolidierung nötig sei.

Aus Angst noch mehr kaputt zu machen, habe ich nicht konsolidiert sondern einen Klon erzeugt. Dabei wurde der Snapshot auch aufgelöst, allerdings ist der Stand der Daten in der VM jetzt alt.

Also drei Basisplatten und folgende Deltas:
bbms.vmdk mit Deltas:
bbms-000001.vmdk
bbms-000002.vmdk
bbms-000003.vmdk
bbms-000004.vmdk

bbms_1.vmdk mit Deltas:
bbms_1-000001.vmdk
bbms_1-000002.vmdk

und die dritte Platte bbms_2.vmdk ohne Delta

Es gibt auch noch die Logs.

Derzeit bin ich dabei, erstmal alle VMDK-Dateien aus dem Datastore herunterzuladen.

Was kann ich tun, um an den aktuellsten Datenstand zu kommen? Speicherplatz ist kein Problem. Im Datastore sind 2 TB frei, die VM umfasst insgesamt ca. 550 GB.

Danke!
Markus

Experte
Beiträge: 1266
Registriert: 04.10.2011, 14:06

Beitragvon JustMe » 21.04.2015, 09:21

Dadurch, dass die Basis-vmdks an einer anderen VM aktiv benutzt wurden, wurden die sog. CID in der vmdk-Beschreibungsdatei veraendert. Somit stimmt die Kette Basisdatei->Snap1->Snap2->... nicht mehr, und die Meldung "Konsolidierung erforderlich" erscheint, und die VM kann nicht mehr gestartet werden.

Wie viel an Bloecken der Basis-Datei jetzt tatsaechlich durch den Start der anderen VM veraendert wurde, ist nicht zu sagen.

Du kannst versuchen, die Snapshot-Ketten der beiden Dateien einzeln zu reparieren (die CID der Basis-vmdk auf den Wert der Parent-CID in der ersten Snapshot-vmdk setzen), und dann einen Clone der Snapshot-Kette durch

Code: Alles auswählen

vmkfstools -i <Ende der Snapshot-Kette>.vmdk <neuerClone>.vmdk
zu erstellen, und dann mal zu schauen, ob Du mit den gefundenen Daten zufrieden sein kannst.

Sollte das nicht der Fall sein: Friede seiner Asche, und Zeit, das Backup einzulesen.

Member
Beiträge: 4
Registriert: 21.04.2015, 07:47

Beitragvon markusa » 21.04.2015, 10:28

Danke.

Zum Verständnis: mache ich das nur für die erste Snapshot-Vmdk, oder in allen?

Wenn das nicht geht, könnte Datenrettung gehen?

Gruß
Markus

Jenseits von Gut & Böse
Beiträge: 10957
Registriert: 02.08.2008, 15:06
Wohnort: Hannover/Wuerzburg
Kontaktdaten:

Beitragvon irix » 21.04.2015, 11:11

markusa hat geschrieben:Danke.

Zum Verständnis: mache ich das nur für die erste Snapshot-Vmdk, oder in allen?


Weder noch :).

Die Numerische Reihenfolge muss nicht mit der logischen Reihenfolge uebereinstimmen. Wenn man Snaps aus der Mitte loescht so werden diese Nummern von VMware wiederverwendet fuer den naechsten Snap.

Ja in den meisten Faellen ist die hoehste Nummer auch der aktuelle Snap... aber wie gesagt das muss nicht so sein.


Bring also den aktuellen Snap in Erfahrung:
- grep -i vmdk *.vmx
- Alternativ im vSphere Client unter Settings->vDISK den Pfad und Dateinamen angucken

vmkfstool -i meingewuenschtersnap.vmdk -> /path/wo/platz/ist/vmname/rettung01.vmdk

Die Originaldateien werden hierbei nicht angepasst. Es wird automatisch die ganze Kette rueckwaerts eingearbeitet basierend von deinem Startpunkt.

Was das Thema CID angeht. Bei einem jeden VM Start wird eine neue ausgewuerfelt und in die Descriptor VMDKs geschrieben. Wenn die Nummer abweichend ist erkennt die VM das die Festplatte sich wohl geaendert hat und verweigert den Commit (Delete Snap)

Wenn das nicht geht, könnte Datenrettung gehen?


Restore vom Backup geht immer.


Gruss
Joerg

Jenseits von Gut & Böse
Beiträge: 10957
Registriert: 02.08.2008, 15:06
Wohnort: Hannover/Wuerzburg
Kontaktdaten:

Beitragvon irix » 21.04.2015, 11:16

Nur der Vollstaendigkeit halber. Das Problem wurde dadurch verursacht das die GUI beim hinzufuegen von vorhandenen vDisk NIEMALS vorhandene Snapshots anzeigt. Aus diesem Grund hast du gutglaeubig die Basis vDisk ausgewaehlt und nicht den aktuellen Stand. Das Drama nahm seinen Lauf.

Mich wuerde ein Dateilistung mit ls -alh interessieren weil wenn der Snapshot "klein" ist dann kann man nachdenken ob man sagt das ist mein Datenverlust und evt. Daten muessen halt neu eingegeben werden weil das System dann Zeit X in die Vergangenheit geht. (Macht man natuerlich nicht mit Windows DCs, sofern man mehrere hat)

Gruss
Joerg

Experte
Beiträge: 1266
Registriert: 04.10.2011, 14:06

Beitragvon JustMe » 21.04.2015, 11:52

Und ich moechte noch hinzufuegen, dass, wie ich es in meinem vorherigen Posting angedeutet hatte, aussreichen sollte, die CID in der BASIS-vmdk anzupassen, weil die Snapshots vmtl. nicht angefasst wurden.

In ESXi5 koennte man die Snapshot-Kette mit einem anderen vmkfstools-Parameter automatisiert pruefen lassen; aber in ESXi4 muessen eigentlich die einzelnen Snapshot-Descriptoren gegeineinander ueberprueft werden, um die korrekte Reihenfolge zu ermitteln.

Member
Beiträge: 4
Registriert: 21.04.2015, 07:47

Beitragvon markusa » 21.04.2015, 13:37

Ich habe jetzt die einzelnen Snapshot-Dateien nochmal neu den Basis-Platten zugeordnet, indem ich nach gleichen Partners geguckt habe.
Dann hatte ich pro virtueller Disk eine alte (2014) und kleine Snapshot-VMDK und eine sehr große aktuelle Snapshot-VMDK, die aber in logischer Folge die kleinere Nummer im Dateinamen trug.

In den drei Basis-VMDKS habe ich die CID geändert, sodass je eine Basis-VMDK Parent der beiden Snapshots sind.

Zur Zeit läuft für alle drei VMDKS der Cloning-Prozess, bei dessen Aufruf ich den Namen der aktuelleren/größeren Snapshot-Datei angegeben habe.

Wie schätzt ihr die Chancen?

Schon mal vielen Dank - ohne eure Hinweise wäre ich noch hilfloser...

Jenseits von Gut & Böse
Beiträge: 10957
Registriert: 02.08.2008, 15:06
Wohnort: Hannover/Wuerzburg
Kontaktdaten:

Beitragvon irix » 21.04.2015, 13:47

Je groesser ein vorhandener Snapshot desto besser in deinem Falle. Weil im Idealfall enthaelt ein Snap ja 100% aller Daten wenn alles mal umgeschrieben wurde.

Ich gehe mal davon aus das die VM nur ganz kurz lief bis du gemerkt hast das der Stand nicht passt oder? Was man machen kann ist folgendes:

- Einbau der neuen vmdk als weitere Festplatte in eine vorhandene Windows VM
- Durchfuehren eines CheckDisk
- Man koennte nun entscheiden nur die User/Anwendungsdaten heraus zukopieren und ueber eine neue VM bereit zustellen sofern das OS beschaedigt ist oder man diesem nun nicht mehr vertraut

Gruss
Joerg

Experte
Beiträge: 1266
Registriert: 04.10.2011, 14:06

Beitragvon JustMe » 21.04.2015, 14:19

@markusa:
So ganz verstehe ich nicht, was Du genau gemacht hast...

Auf jeden Fall sollten, wie Du in Deinem Eingangsposting schriebst, die Dateien bbms_1* der zweiten Platte zusammengehoeren, und die anderen bbms* dann zur ersten Platte gehoeren. Die dritte Platte bbms_2* hatte ja keine Snapshots (mehr).

Vielleicht koenntest Du ja mal die kleinen Descriptor-Dateien *.vmdk mit einem (aelteren) vmware*.log und einem Dateilisting wie von irix erwaehnt zusammenpacken, und hochladen. (Falls noch nicht erfahren: Anhaenge hier im Forum gehen nicht. Also irgendwo anders hochladen, und hier nur verlinken). Nur fuer den Fall, dass die laufenden Clonings nicht das gewuenschte Ergebnis erbringen...

Member
Beiträge: 4
Registriert: 21.04.2015, 07:47

Beitragvon markusa » 21.04.2015, 17:21

Noch mal zusammenfassend:

Mein erstes Posting enthielt eine falsche Zuordnung der Snapshots zu den Basis-VM. Ich habe mich von der Benennung irritieren lassen.

Ich bin in jeden Snapshot-Descriptor-file gegangen und habe mir die ParentCID zum Dateinamen aufgeschrieben. Außerdem habe ich mir zu jedem Dateinamen die CID geschrieben. Damit konnte ich dann je zwei Snapshots (mit der gleichen ParentCID) als offensichtlich zu der gleichen Basis_VMDK zuordnen. Das ergab folgendes Bild:

Basis-VMDK: bbms_1.vmdk
zugehöriger Snap-1: bbms1-000001.vmdk
zugehöriger Snap-2: bbms1-000003.vmdk

Basis-VMDK: bbms_2.vmdk
zugehöriger Snap-1: bbms-00001.vmdk
zugehöriger Snap-2: bbms-00004.vmdk

Basis-VMDK: bbms_3.vmdk
zugehöriger Snap-1: bbms_1-000001.vmdk
zugehöriger Snap-2: bbms_2-000002.vmdk

Anhand der File-Größe und des Datums habe ich dann entschieden, dass alle Snap-1 wohl den letzten Snapshot enthalten müssen. Alle Snap-2-Dateien waren nur rund 500 kb groß und bereits ein Jahr alt. Also habe ich in den Basis-VMDKs die CID auf die "alte" ParentCID geändert und anschließend drei Clones mit vmdkfstools -i <Snap-1> <Zielplatte> erstellt.

Diese ließen sich in einer bestehenden VM problemlos mounten. ich bin jetzt dabei, Daten zu kopieren. Das Ergebnis sieht aber schon ganz gut aus. Bisher habe ich noch nicht versucht, die neuen VMDKs einfach in eine neue VM zu hängen und zu starten.

Ihr habt mir mit den Tipps heute (auch wenn es für euch Profis eher nervig ist) sehr geholfen. D A N K E !

Viele Grüße
Markus

Experte
Beiträge: 1266
Registriert: 04.10.2011, 14:06

Beitragvon JustMe » 21.04.2015, 17:28

Na, das ist ja dann mal erfreulich.

Alles wird gut :-)


Zurück zu „ESXi 4“

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast