Die Foren-SW läuft ohne erkennbare Probleme. Sollte doch etwas nicht funktionieren, bitte gerne hier jederzeit melden und wir kümmern uns zeitnah darum. Danke!

VMDK kann nicht gelesen werden

Tips und Hinweise zur Datenrettung bei defekten VMs oder unlesbaren Datastores

Moderatoren: irix, Dayworker

Member
Beiträge: 25
Registriert: 18.04.2013, 11:08

VMDK kann nicht gelesen werden

Beitragvon Silece » 31.08.2018, 10:21

Hallo,

ich habe zuhause seit einiger Zeit das Problem, dass ich eine VMDK nicht verwenden kann.

Die ganze Geschichte:
Von meinem Monitoring erhielt ich Anfang August die Meldung, dass die Kühlung im "Serverraum" ausgefallen ist.
Die Temperatur des Servers (Fujitsu TX300S6 mit ESXi 6.5UkeineAhnung) stieg dann auf ~40 Grad. Da ich auf DIenstreise war konnte ich wenig machen.
Nach ein paar Tagen habe ich dann festgestellt, dass eine VM nicht mehr erreichbar ist.
Sie ließ sich auch über das Webinterface nicht rebooten, und auch nicht hart ausschalten.
Also habe ich den ganzen ESX rebootet.
Leider hat die Hitze wohl dem USB-Stick geschadet.
- no operating system found

Nach meiner Rückkehr habe ich dann einen neuen Stick gesteckt und VMWare 6.7 (<- vielleicht der erste Fehler?) installiert.
Nach der Grundkonfiguration (welche Karte steckt wo im Switch, welche IP, etc) liefen meine DCs wieder. Nur der Mailserver hat ein Problem.
Ich habe ihn hochgefahren und C funktioniert soweit, nur D wird als unformatiert angezeigt.
Ich habe ihn dann gleich runtergefahren, da ich erst einmal eine kopier der VMDK für D machen wollte.
Das geht leider nicht über das Webinterface, und auch nicht über SSH.
Die Meldung interpretiere ich so, dass da gerade nicht zugegriffen werden kann.

<quote>
Destination disk format: VMFS thin-provisioned
Cloning disk 'HMAIL - Windows Server 2016_1.vmdk'...
Clone: 10% done.Failed to clone disk: Input/output error (327689).
</quote>

Leider hat die Hitzewelle im "Serverraum" auch dem NAS für das Backup zu gesetzt, so dass es nicht einfach ein "zurücksichern" ist.
Hat jemand eine Idee?

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

Re: VMDK kann nicht gelesen werden

Beitragvon JustMe » 31.08.2018, 11:45

Steht doch alles drin:
Silece hat geschrieben:Failed to clone disk: Input/output error

und just vor drei Tagen veroeffentlichte contiunuum dies am hiesigen Orte...

Member
Beiträge: 25
Registriert: 18.04.2013, 11:08

Re: VMDK kann nicht gelesen werden

Beitragvon Silece » 31.08.2018, 11:52

Hallo,

danke!
Ich habe vor einer Woche das Forum durchsucht und nichts gefunden, dann eine Woche mit den Kindern verbracht und dann, war da einfach ein neuer Post...
Schande über mich.

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

Re: VMDK kann nicht gelesen werden

Beitragvon JustMe » 31.08.2018, 12:09

Nee, nicht Schande :-)

Das weist einfach auf die weise Voraussicht von User "continuum" hin!

Member
Beiträge: 25
Registriert: 18.04.2013, 11:08

Re: VMDK kann nicht gelesen werden

Beitragvon Silece » 31.08.2018, 15:19

Hallo,

Ich habe mit dem ersten Schritt begonnen:
dd bs=1M if="HMAIL - Windows Server 2016_1-flat.vmdk" of="HMAIL - Windows Server 2016_1-flatclone.vmdk"
DA kam dann der Abbruch bei 146MB(von 104GB).
Also dieses MB ausgeklammert.
Puh, nur eine Lücke, weil, läuft durch.
Jetzt : vmkfstools -p 0 vmkfstools -p 0 "HMAIL - Windows Server 2016_1-flat.vmdk" > mapping-name.txt

Liefert eine Text-Datei.
Das einzige spannende ist
Mapping for file HMAIL - Windows Server 2016_1-flat.vmdk (107374182400 bytes in size):
[ 0: 1048576] --> [VMFS -- LVID:59037ee4-7683f61a-7f67-001999b8ed06/59037ee3-73427c72-dea2-001999b8ed06/1:( 663054450688 --> 663055499264)]
[ 1048576: 134217728] --> [NOMP -- :( 0 --> 134217728)]
[ 135266304: 40894464] --> [VMFS -- LVID:59037ee4-7683f61a-7f67-001999b8ed06/59037ee3-73427c72-dea2-001999b8ed06/1:( 673254998016 --> 673295892480)]


Aber leider sagt das tutorial nur
If that works we can use the mapping-name.txt file to create a dd-command that copies the vmdk fragment by fragment.
Unfortunately it is very rare that this command will work at this stage.


Blöd, dann bin ich wohl ein Sonderfall :-(

Und was jetzt? Was mache ich mit dieser Mapping-Datei?

King of the Hill
Beiträge: 13561
Registriert: 01.10.2008, 12:54
Wohnort: laut USV-Log am Ende der Welt...

Re: VMDK kann nicht gelesen werden

Beitragvon Dayworker » 31.08.2018, 16:46

Das einfachste wäre, mit "continuum" zu skypen. ;)

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

Re: VMDK kann nicht gelesen werden

Beitragvon JustMe » 31.08.2018, 17:45

Dem moechte ich beipflichten ;-)
Mit undokumentierten Parametern und dem Inhalt der Mapping Table bin ich aussen vor.

Meinereiner wuerde bei "nur einem Defekt" eher versuchen, mit der MOA und ddrescue (oder mit viel Muehe und eigenen iterativen dd-Aufrufen im ESXi) auch von dem ausgeklammerten MB noch so viel als moeglich zu erhalten. Vielleicht ist der fehlerhafte Block ja noch viel kleiner als das ganze MB, und fuer die MAILBOX-Software gar nicht notwendig...

Andererseits muss ich gestehen, dass das ZIEL meiner Recovery-Versuche in wirklich KEINEM Fall einfach derselbe Datentraeger gewesen waere. Ich hoffe, Du hast bei Deinem Post fuer "of=" den Pfad auf einen anderen Datentraeger einfach aus Uebersichtlichkeitsgruenden weggelassen.

Benutzeravatar
UNSTERBLICH(R.I.P.)
Beiträge: 14759
Registriert: 09.08.2003, 05:41
Wohnort: sauerland
Kontaktdaten:

Re: VMDK kann nicht gelesen werden

Beitragvon continuum » 04.09.2018, 15:43

Mapping for file HMAIL - Windows Server 2016_1-flat.vmdk (107374182400 bytes in size):
[ 0: 1048576] --> [VMFS -- LVID:59037ee4-7683f61a-7f67-001999b8ed06/59037ee3-73427c72-dea2-001999b8ed06/1:( 663054450688 --> 663055499264)]
[ 1048576: 134217728] --> [NOMP -- :( 0 --> 134217728)]
[ 135266304: 40894464] --> [VMFS -- LVID:59037ee4-7683f61a-7f67-001999b8ed06/59037ee3-73427c72-dea2-001999b8ed06/1:( 673254998016 --> 673295892480)]


Diese mapping Datei zeigt uns ....
Das erste MB der thin provisioned VMDK ist schon belegt - klar - das ist der MBR / GPT ...
Das naechste Stueck ist 127 MB gross und bis jetzt noch nicht beschrieben. ESXi nutzt daher statt einem Fragment auf dem VMFS-volume sozusagen einen Verweis auf /dev/zero.
Das ist natuerlich deulich platz-sparender.
Die naechsten 4 MB sind dann wieder belegt ... und so weiter.

Kurz gesagt - der Auschnitt der mapping.txt ist voellig in Ordnung - kein Grund zur Sorge


Zurück zu „Datenrettung“

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 6 Gäste