Parentfile manuell gelöscht

[Neubeginner]

Hallo Liebe Vmware Gemeinde,
folgendes Problem :

ich habe eine Virtuelle Maschine mit Snapshots, allerdings habe ich aus Versehen die allererste Parentfile unwiederbringlich gelöscht.
In der Folge startet die virtuelle Maschine nicht mehr und ich bekomme die Fehlermeldung "File not found: Name der Datei
This file is required to power on this virtual machine. If this file was moved, please provide its new location."

Da ich die Datei leider nicht mehr herstellen kann, möchte ich einmal wissen, ob es irgendwie möglich ist, Zugriff auf die älteren Snapshot-Dateien zu bekommen, um zumindest einen älteren Zustand wiederherzustellen. Geht das?

Host: Windows7 Pro x64, SP1
Workstation-Version: 8.0.2
Die virtuelle Platte ist monolithicSparse, hier die Descriptor-Zeilen:

Martin Vista-000001.vmdk:
# Disk DescriptorFile
version=1
encoding="windows-1252"
CID=518da475
parentCID=dd644d57
isNativeSnapshot="no"
createType="monolithicSparse"
parentFileNameHint="Martin Vista-000002.vmdk"
# Extent description
RW 1258291200 SPARSE "Martin Vista-000001.vmdk"

# The Disk Data Base
#DDB

ddb.toolsVersion = "8450"
ddb.longContentID = "1aef8c8276ddbaba36b488d3518da475"


Martin Vista-000002.vmdk:
# Disk DescriptorFile
version=1
encoding="windows-1252"
CID=dd644d57
parentCID=4826b375
isNativeSnapshot="no"
createType="monolithicSparse"
parentFileNameHint="Martin Vista"
# Extent description
RW 1258291200 SPARSE "Martin Vista-000002.vmdk"

# The Disk Data Base
#DDB

ddb.longContentID = "30e83529423e6fc21b01c438dd644d57"
ddb.toolsVersion = "8450"

Log-Dateien:
Leider habe ich die auch nicht gesichert, bevor ich ein wenig rumprobiert habe...
Vielleicht läßt sich trotzdem noch etwas erkennen...
vmware.log:
https://dl.dropbox.com/s/zdsx2ck474ktxo ... e.log?dl=1
vmware-0.log:
https://dl.dropbox.com/s/7znjycvqycg477 ... 0.log?dl=1
vmware-1.log:
https://dl.dropbox.com/s/im6hf1r6fjipcu ... 1.log?dl=1
vmware-2.log:
https://dl.dropbox.com/s/i1tanu11uc8jw1 ... 2.log?dl=1

Ist Rettung möglich?
(Es würde mir schon absolut reichen, wenn ich nur die Daten aus der -000001.vmdk wiederbekomme!)

[irix]

Am Montag erst gemacht.

1. Erstelle eine leere vDisk in der Groesse deiner vermissten Parentdatei
2. Haenge diese an ein vorhandenes Windows und mache ein Quick Format
3. Haenge die vDisk wieder ab
4. Benutze die VMDK dieser vDisk als Parent in dem du Name, CID usw. anpasst.
5. Haenge nun den Snapshot als weitere vDisk in eine VM ein. Achtung: Man kann keinen Snap einhaengen und die Gui nimmt nur die Parent (wird auch so angezeigt). Das heist man editiert die *.vmx so das der Snap genommen wird und startet dann die VM auf der Konsole
6. Wenn man Glueck hat bietet Windows biem Boot gleich ein Chkdisk an. Ansonsten macht man es nach dem Anmelden

Wer mag macht vorher eine Kopie von seiner Delta Datei bevor er damit rumspielt.

Gruss
Joerg

[Neubeginner]

Vielen Dank für die schnelle Antwort!
Und ja, natürlich war es dumm von mir, die Logs und die Deltafile nicht vorher zu sichern.Kenne mich mit dem Programm eben nicht wirklich aus. Passiert nicht noch einmal!

Ich habe inzwischen alles bis Punkt 4 abgearbeitet - und sofern ich nichts übersehen habe, müsste die Konfiguration so stimmen:

Datei 1:
# Disk DescriptorFile
version=1
encoding="windows-1252"
CID=79157c28
parentCID=ffffffff
isNativeSnapshot="no"
createType="monolithicSparse"

# Extent description
RW 1258291200 SPARSE "Martin Vista.vmdk"

# The Disk Data Base
#DDB

ddb.adapterType = "ide"
ddb.geometry.sectors = "63"
ddb.geometry.heads = "16"
ddb.geometry.cylinders = "16383"
ddb.uuid = "60 00 C2 9b 88 33 54 af-df 34 a9 bc 93 ff d0 43"
ddb.longContentID = "f095c3ce93d8dd00ffc85d5379157c28"
ddb.virtualHWVersion = "8"

Datei 2:
# Disk DescriptorFile
version=1
encoding="windows-1252"
CID=dd644d57
parentCID=79157c28
isNativeSnapshot="no"
createType="monolithicSparse"
parentFileNameHint="Martin Vista.vmdk"
# Extent description
RW 1258291200 SPARSE "Martin Vista-000002.vmdk"

# The Disk Data Base
#DDB

ddb.longContentID = "30e83529423e6fc21b01c438dd644d57"
ddb.toolsVersion = "8450"

Datei 3:
# Disk DescriptorFile
version=1
encoding="windows-1252"
CID=518da475
parentCID=dd644d57
isNativeSnapshot="no"
createType="monolithicSparse"
parentFileNameHint="Martin Vista-000002.vmdk"
# Extent description
RW 1258291200 SPARSE "Martin Vista-000001.vmdk"

# The Disk Data Base
#DDB

ddb.longContentID = "1aef8c8276ddbaba36b488d3518da475"
ddb.toolsVersion = "8450"



Korrigiert mich bitte, wenn ich falsch liege.

Nun aber zum weiteren Vorgehen:
Mir ist nicht ganz klar, was unter Punkt 5 gemeint ist. Kann die vDisk auch als einzige Platte in ihrer ursprünglichen Maschine gestartet werden, oder ist es zwingend erforderlich, sie in eine "fremde" Maschine einzuhängen?
Und was bedeutet der Teil hinter "Achtung:"? Was muss ich da genau in der *.vmx editieren?
Zur schnellen Hilfe hier der Link zu meiner .vmx-Datei:
https://dl.dropbox.com/s/ix8ohlcxhdm99eo/VMX.vmx?dl=1

[JustMe]

Mal sehen, ob ich es diesmal schaffe, schnell genug zu sein...

Der Grund, warum die "wiederhergestellte" Platte an eine andere (funktionierende) VM gehaengt werden muss, liegt darin, dass das Betriebssystem auf Deiner nur noch in den nach Snapshots veraenderten Bereichen vorhanden ist, und somit nur dann ueberhaupt vielleicht starten wuerde wenn Du im Snapshot auch ein Betriebssystem-Update mit abgebildet haettest, mit dem so viel wie moeglich geaenderte Sektoren in den Snapshot-Dateien landen wuerden. Aber wie geschrieben: Das ist hoechst unwahrscheinlich.

Das "Achung:" bedeutet, dass Du im GUI wohl nicht die -000001.vmdk an eine VM anhaengen kannst, sondern nur die Basis-Datei. Du musst also vor dem VM-Start deren .vmx-Datei bearbeiten, und den Verweis auf diese Platte um den Snapshot-Suffix haendisch eintragen.
Das habe ich selber noch nicht probiert, deshalb nur eine Vermutung. Aber Du kannst es ja einfach mal ausprobieren mit den Dir vorliegenden Dateien. Deine verlinkte vmx-Datei koennte aber bereits als Bestaetigung dienen, da hier nur der Basis-Dateiname eingetragen ist. Die korrekte Zeile muesste somit m.E. lauten:

Code: Alles auswählen

ide0:0.fileName = "F:\Virtuelle Computer\MartinVista\Martin Vista-000001.vmdk"

PS1: Merkwuerdig, dass die Snapshot-Kette 1-2-Basis ist. "Normalerweise" erwartet wuerde 2-1-Basis...
PS2: Alles steht und faellt mit der Menge der in den Snapshots abgelegten Sektoren. Je mehr, je besser...

[irix]

Du vermutest komplett richtig.
Wenn es als Boot Disk benoetigt wird so haette man anstelle des Quickformats eine OS Installations machen muessen. Hinterher die Snapkette mal in ein Knoppix haengen und mit "testdisk" gucken und gegebenenfalls Reperarieren.

Aber hier war nur gefordert das man einige Dateien herauspicken will und von booten war nicht die Rede.

Allerdings sehe ich erst jetzt das es sich um VMware Workstation handelt und ich war in Gedanken bei vSphere. Ich weis nun nicht wo es sich im Detail unterscheidet.

Gruss
Joerg

[continuum]

Das "Achung:" bedeutet, dass Du im GUI wohl nicht die -000001.vmdk an eine VM anhaengen kannst, sondern nur die Basis-Datei. Du musst also vor dem VM-Start deren .vmx-Datei bearbeiten, und den Verweis auf diese Platte um den Snapshot-Suffix haendisch eintragen.

Das Problem betrifft nur ESXi - bei Workstation ist ein Einhaengen von Snapshots per GUI moeglich

[continuum]

PS1: Merkwuerdig, dass die Snapshot-Kette 1-2-Basis ist. "Normalerweise" erwartet wuerde 2-1-Basis...

Das ist voellig normal. Die snapshotketten koennen kreuz und quer hin und her springen.
Nicht geradliniege ketten sagen nur aus dass zwischendurch schon einmal einzelne snapshots entfernt wurden. Bei Erstellung eines weiteren snapshots wird dann die erste freie Nummer verwendet.

@ neubeginner

wenn dir das ganze nicht geheuer ist - ruf eben an - ich kann dir das dann per Teamviewer zusammenbasteln.

02985 908742

[Neubeginner]

Also da ich die Lösung, das System von der wiederhergestellten vDisk booten zu können, natürlich bevorzuge (weil komfortabler und näher am Originalzustand), habe ich auf die leere neu erstellte Disk einmal das gleiche OS (Vista) installiert, wie auf der kaputten. Dann wieder die Descriptor-Zeilen angepasst und in der *.vmx die -000001.vmdk als Disk eingetragen (geht bei Workstation tatsächlich via GUI). Anschließend habe ich in der "zerbrochenen VM mit der Vista-CD gestartet und ein Chkdsk drüber laufen lassen. Meldung war, dass er sie reparieren konnte.

So weit, so gut.

Wenn ich nun direkt von der zusammengebastelten Platte wieder starten möchte, bekomme ich die Meldung "The file is possibly corrupt. The file header checksum does not match the computed checksum" und nichts tut sich mehr.

Wenn ich richtig vermute, müsste das doch vom Betriebssystem kommen, oder? Zumindest kann ich die reparierte Disk ohne Probleme als Netzlaufwerk in mein Host-System mounten (Dafür schon einmal ein riesiges Dankeschön!!!).

Aber - wenn ich schon dabei bin: Lässt sich da noch etwas machen, sodass ich wieder von der reparierten Disk starten kann?

[continuum]

Wenn ich nun direkt von der zusammengebastelten Platte wieder starten möchte, bekomme ich die Meldung "The file is possibly corrupt. The file header checksum does not match the computed checksum" und nichts tut sich mehr.

Ist das eine VMware -meldung oder eine Vista-meldung ?

[Neubeginner]

Die Meldung kommt innerhalb der virtuellen Maschine nach dem Boot-Screen - daher denke ich von Vista.
Außerdem lässt sich die vDisk ja wie beschrieben fehlerfrei im Host-System mounten, weshalb ich denke, dass es kein vmWare-Problem ist.

[continuum]

Mit welchen optionen hast du das checkdisk ausgefuehrt ?

chkdsk /f /x /r solltest du nehmen

[Neubeginner]

Ursprünglich habe ich die "Reparieren"-Funktion der Windows-CD benutzt.

Inzwischen habe ich nochmal ein chkdsk mit den Parametern ( /f /x /r ) gemacht - und er hat wieder etwas repariert.

Die Meldung wenn ich von der reparierten Disk starten möchte bleibt allerdings unverändert.
Was könnte die Ursache dafür sein?

[irix]

Kann halt sein das der Snap zu klein ist und nicht genug Daten enthaelt. Konntest du denn die gewuenschten Daten herausholen nach dem die Platte wo anders eingehaengt wurde?

Gruss
Joerg

[Dayworker]

Mit Windows Plattenfehler zu reparieren, ist manchmal eine längerandauernde Angelegenheit.
Ich habe jetzt schon mehrfach gelesen, daß Windows bei Fehlern immer nur den ersten behandelt und den Rest trotz anderslautender Anzeige nicht mehr bearbeitet. Sowas würde eigentlich nur bei Folgefehlern einen Sinn machen und dann könnten wirklich erst nach einem Zweit- oder sogar Drittreparaturlauf alle Probleme beseitigt sein.

In wie weit dir "continuum" seine Parameter daran etwas ändern, entzieht sich meiner Kenntnis. Ich würde jedenfalls von der Win-CD/DVD starten und von dort die Disk-Reparatur anschieben. Das hätte auch den Vorteil, daß der Datenträger wirklich nicht im Zugriff ist und Windows dann hoffentlich alles in einem Durchlauf erledigen kann.

[continuum]

"The file is possibly corrupt.

ist zu erkennen um was fuer eine Datei es da genau geht ?

[Santa]

Wenn es Dateien sind, die zur Windows-Grundinstallation gehören (und damit auch nicht im Snapshot liegen), dürfte mann diese mit einer Reparaturinstallation wiederherstellen können.

[Neubeginner]

Konntest du denn die gewuenschten Daten herausholen nach dem die Platte wo anders eingehaengt wurde?

Nachdem ich die entsprechenden Zugriffsberechtigungen gesetzt habe, habe ich über dsa Hostsystem wieder Zugriff auf die reparierte vDisk.
An dieser Stelle noch einmal vielen Dank für die Hilfe! Das ist mir das wichtigste.

ist zu erkennen um was fuer eine Datei es da genau geht ?

Nein, leider nicht. Die Meldung ist alles, was ich sehe.

Ich werde daher mal den Rat von Dayworker befolgen und ChkDsk (mit den Parametern /f /r /x /b ) von der Windows-CD aus mehrmals über die Platte laufen lassen.
Falls das nichts hilft, kann ich es mal mit der Reparaturinstallation probieren.

[continuum]

Ich mache solche Aktionen fast regelmässig für Kunden.

Denen sage ich dann immer sie sollen die wichtigen Daten extrahieren und die VM danach wegwerfen.

So eine Aktion ist ein sehr massiver Eingriff in das Dateisystem und meiner Ansicht nach ist eine solche VM nachher nicht mehr vertrauenswürdig

[Bernie2013]

Hallo!

Auch wenn dieser Thread schon einige Zeit zurückliegt war er für die Lösung meines Problems bis jetzt sehr nützlich. Es geht um folgendes:

Ich habe hier eine VM mit einer Festplatte (monolithicSparse), die sich in Snapshots aufteilt (Kette ist "Basis-2-1", wobei "1" der neueste Snapshot ist).
Bei der Migration auf ein anderes System ist die Basis-Datei verschwunden, die VM lief nicht mehr. Ich wollte aber gern die die (verlorenen) Daten sichern...
Anhand der oben beschriebenen Systematik habe ich eine passende Ersatz-Basisdatei gebastelt, die Snapshots angepasst und kann die virtuelle Disk nun wieder mounten.
So weit, so gut.
Nachdem ich mir die ersten Ordner herauskopiert habe, stelle ich nun fest, dass sich die meisten Dateien nicht öffnen lassen, obwohl sie mir im Explorer angezeigt werden. Ich vermute, dass liegt daran, dass Teile dieser Dateien in dem Basis-Snapshot abgelegt waren. Stimmt das?
Und wenn ja, habe ich dann noch eine Chance auf Rettung?
Eigentlich müsste man mit mit irgendwelchen Undelete-Tools versuchen, die Basis-Datei wiederherzustellen, oder??? Ich fürchte nur, dass das nichts mehr bringt, da die Festplatte, auf der sie lag, schon mehrfach mit einer Menge anderer Daten überschrieben wurde...
Gibt es noch einen anderen Weg auf Rettung oder sind die Daten für immer weg?

Gruß,
Bernie

[continuum]

Moin
hast du noch saubere Kopien der beiden snapshots ?

Bei dieser Sache ist es sehr wichtig, wann man das System den checkdisk laufen lässt - wenn man da nicht aufpasst bekommt man leere dateien.

Ruf doch mal an - dann sprechen wir mal eben über den Fall

02985 90874zwei

[Bernie2013]

Moin allerseits!

hast du noch saubere Kopien der beiden snapshots ?

Jein. Als ich zu dem Problem hinzugezogen wurde, war mit den Originalen leider schon etwas herumprobiert worden. Habe dann erstmal eine Sicherung gemacht und probiere nun mit den Kopien herum.

Bei dieser Sache ist es sehr wichtig, wann man das System den checkdisk laufen lässt - wenn man da nicht aufpasst bekommt man leere dateien.

Wäre es da nicht sogar am besten, den CheckDisk komplett wegzulassen und alles aus dem wieder zusammengebastelten Laufwerk mit einem RecoveryTool herauszukopieren (z.B. anhand dieser Anleitung: http://stadt-bremerhaven.de/anleitung-photorec-findet-geloeschte-daten-auf-festplatte-usb-stick-sd-karte/)?
Dass dabei Ordnerstruktur und Dateinamen verloren gehen, interessiert nicht. Wichtig ist, dass die noch lesbaren Daten wieder zugänglich sind.

Gruß,
Bernie