Dieses Mal muss ich Werbung in eigener Sache machen.
Folgendes Szenario hat sich am vergangenen Dienstag ergeben:
Mein virtueller Mailserver (Ubuntu 8.0.4 mit Zimbra 6.0.6) meldete I/O Read-Write Errors und stand nur mehr im Readmode. Ebenfalls ist mein vCenterServer gecrashed. Nach genauerer Untersuchung musste ich feststellen, daß eine Platte im VMFS3 Store bad blocks hatte und diese genau meine vmdk’s der betroffenen VM’s beinhalten.
Was tun? Jeder andere hätte wahrscheinlich aufgegeben und die VM’s neu installiert – ich wollte aber unbedingt die Daten retten und habe mich an die Arbeit gemacht mit HDD Recovery Tools (die alle nicht für VMFS3 partitionierte Festplatten gemacht sind) zumindest einen Teil der Daten zu retten. Und gleich vorweg – es war erfolgreich, denn sonst hättet Ihr unter www.vdi-guru.com keine Seite mehr erhalten. (Der Webserver ist ebenfalls eine der betroffenen VM’s gewesen)
Somit bin ich der erste (zumindest der erste der im großen weiten Internet darüber berichtet) Consultant der es geschafft hat eine defekte HDD mit VMFS3 Store wieder ohne Datenverlust zu retten!
Aber ich will kein Geld für dieses Know How! Ich teile hier mit euch die notwendigen Schritte und möchte allen anderen VM-Gurus die Suche nach einer Lösung des Problems ersparen und einen Lösungsweg zeigen.
Als erstes: Kläre ob die HDD überhaupt noch läuft. Also fährt sie noch an und kann man zumindest Teile auf der Platte lesen. Bei mir war es überhaupt kein Problem – zumindest solange man keinen “echten” Traffic auf der Platte hatte.
So sind zum Beispiel meine VM’s nach dem Restart des ESXi Hosts problemlos nach einem Datarecoveryprocess (fsck) wieder hochgekommen und haben Ihren Dienst angeboten. Also versuchte ich die VM-Directories einfach auf eine andere LUN zu kopieren. Das ging bis zu einer gewissen Datenmenge sogar gut. (einzelne Dateien sind problemlos kopiert worden) Nur ab einer gewissen Datenmenge stoppte der Kopierprozess mit Buffer I/O Error. Alle Versuche egal ob mit scp, vmkfstools waren erfolglos.
Nach genauerer Analyse der HDD stellte ich defekte Blöcke fest und somit war mir klar um noch eine Chance zu haben, die Daten zu retten, muss ich versuchen die Platte zu klonen. 500GB HDD’s habe ich zum Glück genügend und so schaufelte ich eine 500GB HDD frei und begann mit einem der besten Tools (Parted Magic) eine Live CD zu booten und meine beiden 500GB HDD’s zu prüfen. Tatsächlich! Die VMFS3 Platte hat defekte Blöcke.
Nach vielen Stunden Suche ob jemand eine VMFS3 formatierte Platte einmal retten konnte habe ich leider keinen einzigen Eintrag über eine erfolgreiche Aktion gefunden. Also musste ich mich trauen!
Das Tool meiner Wahl war “ddrescue” .
Damit wird die komplette HDD gescannt, ein Logfile angelegt und anhand des Logfiles die Daten auf eine neue HDD kopiert. Danach wird versucht die defekten Blöcke zu splitten um den Datenverlust so gering wie möglich zu gestalten.
Dieser 
Kopierprozess dauert ziemlich lange – Geduld ist angebracht. Bei mir lief der erste Prozess ca. 12 Stunden und das waren keine sehr angenehme Stunden. Erst als der Kopierprozess abgeschlossen war und der nächste Schritt, daß “Trimming” begonnen hat konnte ich mich dazu überreden schlafen zu gehen. Weitere Stunden später kam aber das erste “aufatmen” als der eigentliche Kopiervorgang erfolgreich abgeschlossen war und ddrescue sich mit den “defekten” Blöcken beschäftigte.
Dieser Schritt ist erbärmlich langsam. Versucht ddrescue ja beinahe unendlich lange einen einzigen Block auf der gesamten Platte zu verteilen um die “defekte Dateigröße” so klein wie möglich zu gestalten. Hier muss man geduldig sein und den Server arbeiten lassen. Bei mir ein Prozess von über 34 Stunden!!
Aber danach kann man sich endlich mit der erfreulicheren Tätigkeit beschäftigen. Das mounten der neuen Festplatte und das kopieren bzw. verschieben auf eine für den ESX Host lesbare LUN. Ich habe einfachheitshalber die lokale HDD des ESXi Hosts und den Midnight Comander dazu verwendet.
Nun sind die Daten auf einem VMFS3 Store und können von dem lokalen Store auf die shared storage wieder kopiert werden und danach wieder im vcenter Server eingebunden werden.
Ist das dann erledigt kann man sich auf die Schultern klopfen und einem ursprünglich katastrophalen Datenverlust abhaken und wieder mit positiver Einstellung sich den eigentlich spannenden Tätigkeiten widmen.
Für Fragen und Tips stehe ich gerne via email zur Verfügung
