...
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 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
...
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 hat leider kein USB-3). So weit - so gut.
...
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. |
...