...
Dann ist es endlich soweit: Die Platte liegt noch eingebaut im Gehäuse und auf der Platine - und die Freude ist groß: Ja - es ist ein Standardbauteil. Eigentlich hat man das ja erwartet aber man weß ja nie.... The Winner is: "Western Digital blue WD10JPVF mit 1TB und SATA-Schnittstelle" So weit so gut. Sie tut nur nicht.
Also: schnell mal ne andere Platte aus dem Fundus reingesteckt und mal geschaut, was das BIOS dazu sagt - und, oh Wunder, sie wird ohne Probleme erkannt. Mit ner Zweiten verifiziert: OK! Der Laptop ist schon mal nicht für die Elektroschrottsammlung!
Na dann widmen wir uns der Platte um an unsere wertvollen Daten zu kommen. Wie geht´s los: Richtig und 100 Punkte: Windows-Rechner, USB-Adapter, Platte dran, da ... müsste doch ein Laufwerk zu finden sein. Isses aber nicht. Die Platte sagt leise klack klack, die Scheiben drehen sich - aber auf dem Rechner ist - Stille - und nix zu sehen. Hmm. Fehlerausschrift: Fehlanzeige! Nix im Ereignisprotokoll, nix in irgend nem Log. Was macht der geneigte ITler nun? (...ja ja ich weiß, der hätte nie ne Windows-Platte zur Recovery angenommen und darauf verwiesen, dass das unter Linux sowieso nie passier wäre...) Aber Linux ist schon mal der richtige Weg, auch "postmortal". Also dann:
Linux-Laptop raus (altes UBUNTU, aber reicht), Kommandozeile, USB-Adapter samt Platte eingestöpselt und voller Zuversicht ein "tail -f" auf das "/var/log/syslog" (überall anderswo wäre das das "/var/log/messages" gewesen aber egal...) gemacht - Platte eingestöpselt - und ... und ... Ja - Controller und Platte vom EHCI-Controller erkannt und auch fdisk erkennt unter /dev/sdb was gültiges... aber eben nur "WAS" gültiges:
Der Kern des Pudels heisst "Partition ID = Microsoft basic data" - und beinhaltet irgendwo dann auch die Informationen über Größe und Filesystem-Formatierung - die Betonung liegt auf "Irgendwo", denn mit diesem Partitionstyp lässt sich das Dateisystem mal nicht so eben per loopback mounten - wäre auch zu einfach gewesen. Gut - Herausforderung angenommen.
Also werden wir uns erstmal eine Sicherheitskopie basteln - der alte Forensiker wird sich ja nicht am Original abarbeiten und das womöglich noch weiter durch eventuelle Fehlversuche kaputtmachen...
...
Der erste - zugegebenerweise stümperhafte - Versuch war die Nutzung des simplen kleinen UNIX-Befehls "cat". Er musste fehlschlagen, da die Festplatte ja irgendwo beschädigt war und - ja genau - cat dann an dieser Stelle nach etwa 7 Gigabyte abgebrochen hat.
Zuvor waren allerdings noch ein paar Handgriffe nötig, die auch für die folgenden Aktionen benötigt werden, zu alleroberst:
Mounten des NFS-Pfades der Synology per NFS nach /mnt - irgendwo müssen die zu rettenden daten ja hingeschrieben werden können - auf dem Linux-Lappi Läppi war jedenfalls bei Weitem nicht so viel Platz. Aber dafür wurden ja schließlich Netzwerkspeicher und das NFS erfunden..
Versuch 2: dd — convert and copy a file
dd ist nicht selbsterklärend. Die relativ selbsterklärenden Kommandozeilenparameter sind "if=" und "of=" für die Bezeichnung der Ein- und Ausgabedateien -oder geräte, Es gibt aber auch noch bs, count, ... und das kleine - seltener dokomnetierte "conv=".
...
"conv=" ist der Retter.
Versuch 2b: dd — mit "conf=noerror"
> dd conf=noerror if=/dev/sdb3 of=/mnt/sdb3.img
... und tatsächlich: Das System versucht sich fortan redlich an den defekten Sektoren, bricht auch nicht ab und macht einfach ohne sie weiter. OHNE SIE? STOPP! Dann wird das nix werden, da ja die Daten der Plattenspiegelung mengenmäßig hinter dem Defekt in der Kopie dann völlig verschoben verglichen zum Original liegen werden - die defekten Sektoren werden ja einfach übersprungen. Gibt es denn nicht eine Möglichkeit, fehlerhaft gelesene Stellen einfach mit "00" zu ersetzen, dann stimmen Größe und Position der Daten im Ergebnis ja wieder mit dem Original überein - es gibt halt nur mit "00" gefüllte Datenlöcher an den beschädigten Stellen. ? Gibt es. Und wir sind bei Versuch
Versuch 2c: dd — mit "conf=noerror,sync"
> dd conf=noerror,sync if=/dev/sdb3 of=/mnt/sdb3.img
YESS. Das System rappelt wieder los und macht alles richtig. Im Ziel wird nun die richtige Kopie der Partition liegen. Und was machen wir damit? Glücklicherweise kam diese Frage noch relativ zeitnah am Beginn des Kopiervorgangs in mir hoch, denn ohne die Chance die Partition loopback mounten zu können (wir erinnern uns "Microsoft basic datdata", s.o) ist das ganze nicht so sehr zielführend - also abgebrochen.
...
der uns zum Ziel führen sollte...
Wir machen jetzt also eine fehlertolerante Kopie der gesamten Platte mit allen Partitionen in ein File auf dem Netzlaufwerk. Und da wir nix von Blocksize oder Größe gesagt bzw. an dd übergeben haben machen wir das bis zum bitteren (physikalischen) Ende der Platte und über die kleine Blockgröße auch relativ langsam. Immerhin bekommen wir jetzt für´s Auge einen Balken angezeigt, der uns den Übertragungsfortschritt anzeigt und ein paar Daten wie aktuelle Übertragungsgeschwindigkeit und die noch zu erwartende Dauer...
2 Tage wird´s also dauern, Geschwindigkeit bei ca. 6 MByte/s. Nicht besonders schnell - aber wir müssen ja die Retries und das USB-2 Interface berücksichtigen (Nein der Lappi Läppi hat leider kein USB-3). So weit - so gut.
Dann - plötzlich bricht die Geschwindigkeit ein. Statt der 6 MByte/s nur noch ein knappes 1MByte/s. Was zur Hölle kann das sein. Lesefehler sind's nicht, NAS ist nicht voll und auch nicht ausgelastet, Netzwerk kann´s nicht sein, oder doch? Jepp - da hat sich der Lappi Läppi doch klammheimlich entschieden, nicht mehr das Ethernet-Kabel nutzen zu wollen sondern lieber die WLAnWLAN-Verbindung mit 56MBit - doll. Das hatte hätte dann 2 tage Tage zusätzlich gekostet - inakzeptabel. Die Lösung war dann das Netzwerkkabel einfach einmal raus- und wieder einzustecken. IP bekommen, Netzwerk war wieder schnell...
...
Und da ist das Helferlein namens "
raw2vmdk (auf sourceforge gibt´s Sources, eine Doku und zum Glück vorcompiliertes) → oder direkt hier im Wiki: raw2vmdk-0.1.3.1-jar.tar.gz
Um das Paket zum laufen zu bekommen braucht man Java - kann man aber als Paket auf der Syno problemlos nachinstallieren, ich habe Java 1.8 genommen:
nachdem das Ganze installiert war und auch die Pfade zur Ausführbarkeit glatt gezogen sind geht´s los:
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
ash-4.3# java -jar raw2vmdk.jar /volume2/ESX-Datastore2/sdb.img /volume2/ESX-Datastore2/sdb.vmdk raw2vmdk 0.1.3.1 [$Rev: 30 $] initiated. Author: Zapotek <zapotek@segfault.gr> Website: http://www.segfault.gr Analysing image: /volume2/ESX-Datastore2/sdb.img [1000204886016 bytes] Number of sectors: 1953525168 Number of cylinders: 1023 Heads per track: 255 Sectors per track: 63 Loading VMDK template... Writing VMDK file to: /volume2/ESX-Datastore2/sdb.vmdk All done. |
...
Die Ernüchterung folgt auf dem Fuß - das sdb.vmdk wird nicht in der ESK erkannt oder angezeigt. Am Ende lag´s lags am Pfad aus der Kommandozeile des raw2vmdk-Aufrufs, der sich in der Konfiguration wiedergefunden hatte, aber nur auf der Syno und nicht im Targetsystem ESXi gültig war. Als das gefixt war, konnte die Platte eingebunden werden. (Zusätzlich hatte ich, basierend auf anderen vmdk´s aus anderen virtellen Festplatten noch ein paar Sachen im File geändert:
...
Als letzter Schritt steht dann noch das Zurückkopieren des Images auf den neuen physikalischen Datenträger an (sollte morgen in der Post sein) - dann wird auch der Laptop wieder funktionieren... (Mal sehen wie viele Schrauben diesmal beim zusammenbau übrig bleiben 
). Im ersten Schritt werde ich es mal mit dem in der VM reparierten Image versuchen - hoffentlich kommt WIN10 mit den in der VM erkannten neuen Geräten bzw. dem Rückschwenk auf die im Rechner vorhandenen Geräten (Netzwerk, Interfaces, CPU, ...) zurecht.
Sollte das nicht funzen, gibt´s ja immer noch das "Original" aus 2c - dann muss ene dann eben noch mal repariert werden.
...
- Daten konnten gerettet werden - puh!
- Gut dass der Fehler schon nach ca. 7 GByte auf der Platte war - man stelle sich vor, dass das erst am Ende gewesen wäre. Wie viel Zeit man dann vergeudet hätte... - noch mal puh!
- Platz zum Zwischenspeichern ist wichtig
- Die "richtige" IT-Infrastruktur im Privathaushalt ist wichtig
- Ideen, Zeit und Geduld sind wichtiger
- Nie aufgeben ist am Wichtigsten wichtigsten
Lessons lernt!
Gute Nacht.
...