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