Wer kennt das nicht - Laptop runtergefallen und bootet nicht mehr. Und selbst die Recovery-Funktionen, die der Hersteller (in diesem Fall ASUS) eingebaut hatte, wollen das System nicht mehr wiederherstellen. Erschwerend kommt hinzu, dass die Festplatte im BIOS nur manchmal - und dann auch nur kurz erkannt wird. Rettung - unmöglich... Was aber - wenn dringend benötigte, unwiederbringliche Daten drauf sind? dann greife man zum Backup, mag der Besserwisser sagen - womit er ja natürlich auch recht hat, schließlich gibt es für schmales Geld an jeder Ecke und im Internet überall USB-Festplatten und USB-Sticks. Nicht gerade das, was der Sicherheitsfanatiker als gültiges Backup-Medium anerkennen würde, aber besser als nichts - und ein großes NAS - was man übrigens zweckmäßigerweise für die im Nachfolgenden beschriebene Rettungsaktion gut gebrauchen kann - hat ja nun auch nicht jeder gleich rumstehen....

Die Zutaten

Kaputter Laptop und ein paar geeignete Schraubenzieher , ggf. ein YouTube Video., wie man das Ding beschädigungsfrei öffnen kann, falls man nicht von außen an die Platte rankommt
Funktionstüchtiger Laptop mit Linux drauf
SATA zu USB-Adapter
Netzwerk (Gigabit reicht , schneller ist besser )
NAS (Synology DS-1819+) mit viiiiel Speicherplatz und NFS-Freigabe
Ein ESXi-Host (ESXi 6.7) mit schneller Anbindung zur Syno als Datastore (am einfachsten hier auch per NFS, nicht iSCSI)
ein kleines Progrämmchen, auf das ich im Internet (Google) aufmerksam geworden bin, aber dazu später....

Jetzt geht´s los - oder "Das Kochrezept"

Die erste Zeit verbringt man naturgemäß erst mal in ein paar Versuchen herauszufinden, warum eigentlich nix mehr geht: Liegt´s am Laptop selbst oder der Festplatte. Nach einigen nervtötenden aber erfolglosen Versuchen und Selbstzweifeln (1-2 Stunden sind da nix) merkt man, dass man ohne Aufschrauben nicht weiterkommt. Also: Schraubendreher raus und aufgeschraubt! Wenn das mal so einfach wäre. Schließlich haben die werten Hersteller von "Consumer"-Laptops an teuren Schrauben gespart und stattdessen auch eine Vielzahl von kleinen Plastiknasen und -häkchen gesetzt, die sooo gerne beim Öffnen abbrechen und einen "unsichtbaren" Zusammenbau dann unmöglich machen (sollen). Schließlich will man ja auch mal wieder was neues in schöner Regelmäßigkeit verkaufen. Ein Schelm,.... Übrigens: YouTube ist da eine super Quelle für Anleitungen, wie man was aufmachen kann.

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...

Wir kopieren die Daten - ein Handbuch aus der Reihe "Spannend erzählt"

Versuch 1: cat /dev/sdb3 >dateiname.raw

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-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=".

Kurzum dd alleine in seiner simpelsten Form reicht nicht - auch hier bricht die Übertragung wieder beim Kratzer auf der Scheibe nach etwa 7 Gigabyte ab. Erwartbar, aber schade.

"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 data", s.o) ist das ganze nicht so sehr zielführend - also abgebrochen.

Außerdem erinnerte ich mich noch, dass es man irgendein kleines Helferlein gab (nein das ist noch nicht das im ersten Absatz gemeinte) um ein paar nützliche Informationen über den Kopiervorgang darzustellen: "pv" bzw. "process visualization".

Final lautete dann also der Befehl:

>dd conf=noerror,sync if=/dev/sdb | pv -s 1T | dd conf=noerror,sync of=/mnt/sdb.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 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 Läppi doch klammheimlich entschieden, nicht mehr das Ethernet-Kabel nutzen zu wollen sondern lieber die WLAN-Verbindung mit 56MBit - doll. Das hätte dann 2 Tage zusätzlich gekostet - inakzeptabel. Die Lösung war dann das Netzwerkkabel einfach einmal raus- und wieder einzustecken. IP bekommen, Netzwerk war wieder schnell...

Heute nachmittag war es dann endlich soweit: Die Daten waren alle schön ordentlich in einem File gelandet, dd hatte sich ohne weitere Fehlermeldung beendet und es gab allen Grund zur Hoffnung, dass da noch was geht. Was kommt als nächstes? Richtig - eine Sicherung dieses Files! Schließlich will man ja die Aktion nicht wiederholen müssen, wenn bei den weiteren Versuchen was schief geht. Und zum Rückspielen auf eine baugleiche Festplatte (hatte ich übrigens schon am ersten Tag auf ebay gesichtet und geordert) taugt das Imagefile ja allemal.

Di Sicherung ging dann auch richtig zügig mir 245MByte/s RAID10 sei Dank und war nach ner guten Stunde erledigt.

Die Untote erwacht im Labor

Okay okay - das ist reißerisch. Das Labor ist ist eine Virtualisierungsumgebung und die Untote ist ein Klon der Toten. Klingt aber irgendwie immer noch nach Dracula...

Zunächst erstellen wir mal eine neue virtuelle Maschine "Appliance" in unserer VM-Ware ESXi 6.7 - immer gut wenn das noch ein bisschen Platz ist ...

Der Datastore ist - wie oben beschrieben über NFS eingebunden, schnell ne neue Maschine aufgesetzt, Win10-64-Standardprofil, Netzwerk ans richtige VLAN, Platte ran - hoppla. Die Platte ist nicht im richtigen Format für eine direkte Einbindung in die virtuelle Maschine. Die ESXi unterstützt nur .vmdk-Dateien, wir aber haben ein mit dd erzeugtes "raw"-Image. Prizipiell kann ESX auch mit "raw"-Festplatten umgehen - aber offensichtlich nicht mit "raw"-Images... Das kann doch nicht wahr sein. GOOOOOGLE!

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:

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.

und siehe da. da fällt ein .vdmk file raus.... Heureka!

Die Ernüchterung folgt auf dem Fuß - das sdb.vmdk wird nicht in der ESK erkannt oder angezeigt. Am Ende 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:

Header-Kommentare entfernt
ddb.adapterType => "lsilogic"
ddb.virtualHWVersion = "4"

so dass es dann erkannt wurde und in die VM eingebunden werden konnte :

ash-4.3# cat sdb.vmdk
# Disk DescriptorFile
version=1
encoding="UTF-8"
CID=3d4aa51e
parentCID=ffffffff
createType="monolithicFlat"

# Extent description
RW 1953525168 FLAT "sdb.img" 0

# The Disk Data Base
#DDB

ddb.adapterType = "lsilogic"
ddb.geometry.cylinders = "1023"
ddb.geometry.heads = "255"
ddb.geometry.sectors = "63"
ddb.longContentID = "eb374eba18a6187bd2953d273d4aa51e"
ddb.uuid = "60 00 C2 91 8e 73 27 62-43 58 3b f8 05 ae 2e a0"
ddb.virtualHWVersion = "4"

Ready for Takeoff

VM eingerichtet

Takoff

... dann etwas Rödeln a la " Automatische Reparatur wird versucht - kann länger als eine Stunde dauern..." - leider ohne Bildschirmfotos und voila

I´m alive

Reprise

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 dann eben noch mal repariert werden.

That´s it.

Fazit

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

Lessons lernt!

Gute Nacht.