Froschs Blog

Computer und was das Leben sonst noch so zu bieten hat

Zur Website | Impressum

Remote-Datenrettung (1)

18. Dezember 2009 um 16:32 Uhr von Atari-Frosch

Gegeben war eine Festplatte, SATA, 320 GB, die eine WinXP-Installation auf C: und eine Datenpartition D: hatte. Diese Installation konnte nach einem mißlungenen Update nicht mehr booten, auch nicht in den „abgesicherten Modus”. Also nahm der Eigentümer des Rechners die Windows Recovery-CD und wollte sein System reparieren lassen. Noch während die Recovery-CD arbeitete, merkte er, daß da was nicht stimmen konnte: Die Platte sollte auf einmal nur noch 16 GB groß sein, und auf diesen 16 GB legte das Recovery-System zwei Partitionen an, angeblich eine für die Pakete und eine für eine Neuinstallation des Systems. Daß auf der D-Partition noch ungesicherte Daten standen, störte die Recovery-CD dabei nicht im geringsten.

Kenntnisse in Datenrettung sind bei mir eigentlich so gut wie nicht vorhanden. Ich mußte mich also langsam vortasten. Als zusätzliches Handicap kommt dazu, daß der Eigentümer des Systems nicht gerade um die Ecke wohnt. Mal eben hinfahren und mich direkt davorsetzen kam also nicht in Frage. Und zur Post wollte er die Platte nicht geben, denn die ungesicherten Daten sind nicht für jedermanns Augen bestimmt — und natürlich ist die Platte nicht verschlüsselt.

Zur Vorbereitung besorgte der Eigentümer eine externe 500-GB-Festplatte (USB/SATA). Dann ließ ich ihn den PC mit einer Knoppix booten und im Router Port 22 öffnen. Knoppix bringt zwar interessanterweise die Datei /usr/bin/ssh mit, aber nicht das dazugehörige Startscript /etc/init.d/ssh. Kurz: Alle Login-Versuche endeten mit einem „Connection refused”. So kam ich nicht weiter.

Nach diversen Überlegungen wies ich ihn an, sich die erste Installations-CD von Debian GNU/Linux zu ziehen und zu brennen (DSL 6000 vorhanden). Via Telefon führte ich ihn dann gestern durch die Expert-Installation. Allerdings hing die zerschossene Windows-Platte als erste SATA-Platte (/dev/sda) im System, und grub wollte sich dann unbedingt in deren MBR schreiben. Nach dem Booten blieb das System mitten im Kernel-Boot hängen, und auch im Single-User-Mode kam es nicht hoch.

Also nochmal das ganze, diesmal mit abgeklemmter Windows-Platte. Was mir nicht gleich klar war: Dadurch wurde die externe Platte natürlich von /dev/sdb zu /dev/sda. Diesmal lief die Debian-Installation durch. Die Platte bekam eine 20-GB-Partition für Linux, 512 MB Swap (bei 2 GB RAM eigentlich überflüssig, aber man weiß ja nie ...), und den kompletten Rest als Datenpartition. Letztere sollte das Image der zu rettenden D: der Windows-Platte aufnehmen; wir schätzten die Größe dieser Partition auf maximal 250 GB, denn die ursprüngliche C: war etwa 80 GB groß gewesen.

Ich ließ ihn noch ssh installieren, und dann konnte ich schon drauf. Neben meinen üblichen Werkzeugen mc und joe installierte ich noch gparted, das mir empfohlen worden war. Dann sollte er die Windows-Platte wieder anklemmen.

Das System blieb dann wieder im Booten hängen, allerdings mit der klaren Beschwerde, daß es seine Partitionen nicht mounten könne. Klar, in der /etc/fstab stand ja /dev/sda, und jetzt war die Platte wieder /dev/sdb. Problemlösung: Runterfahren, ohne Windows-Platte booten, in der /etc/fstab alle sda auf sdb ändern, runterfahren, Windows-Platte anklemmen, wieder booten. Diesmal erfolgreich, wenn auch mit einem lustigen Effekt: Während mir die Rootpartition mit /dev/sdb1 angezeigt wurde, mußte ich für die Datenpartition die /dev/sda3 mounten.

Nächster Schritt: gparted starten. Das meldete mir auf der Konsole einen Gtk-Fehler: Cannot open display. Ähm, ja. Offenbar ist das ein grafisches Tool. Muß ja 'nem Dummen gesagt werden. 😉

Na gut. Ich hatte zwar gehofft, daß es ohne geht, aber wenn es denn unbedingt sein muß ... Ich holte also die nötigen Pakete für nx von NoMachine und installierte sie. Mein nxclient weigerte sich allerdings, die Verbindung vollständig aufzubauen. Der Aufbau lief fast durch, dann wollte er noch was verhandeln („Negotiating link”), und dann kam eine Fehlermeldung, die besagte, daß der Proxy (?) den Client nicht authentifizieren konnte. Ich vermutete erst einen Versionskonflikt, weil mein Client ein bißchen älter ist als der Server auf der anderen Seite, aber auch ein Update meines Clients brachte keine Änderung. Also fiel das erstmal weg.

Eine Suche in den Paketquellen erbrachte, daß es da auch noch den lde gibt, einen Hex-Editor für Filesysteme. Das Hauptproblem ist ja, herauszufinden, wo genau die verlorene Partition anfängt, also auf welchem Block. Mit lde fand ich dann auch den Anfang der ersten Partition (auf Block 31), aber offenbar wurde mir nicht, wie vorgegeben, die gesamte /dev/sdb angezeigt, sondern nur /dev/sdb1. Denn bevor da noch eine Anfangskennung für eine Partition kam, war die Anzeige zu Ende. Ich fand auch keine Möglichkeit, auf die nächste Partition oder überhaupt über das Partitionsende hinaus zu springen.

So nebenbei machte sich dann noch ein zweites Problem bemerkbar: Meinem Gegenüber wurde vom Provider alle 10 bis 15 Minuten eine neue IP verpaßt. Damit starb mir natürlich jedesmal die ssh-Verbindung. Ich ging dann dazu über, die Befehle dem Eigentümer vorzugeben, sodaß sie direkt lokal ausgeführt wurden. Ja, ich hätte screen verwenden können, weiß ich. 😉

Schließlich entdeckte ich noch gpart. Damit konnten wir dann wenigstens herausfinden, daß die verlorene Partition tatsächlich noch existiert. Allerdings liefert gpart nicht den genauen Block, sondern nur einen Wert in Megabytes. Auch scheint das Tool nicht dafür geeignet zu sein, eine solche gefundene Partition direkt in ein Image zu übertragen.

Ich versuchte also:

dd skip=81719M if=/dev/sdb of=/data/winhdd

Das ließen wir dann über Nacht laufen.

Das enttäuschende Ergebnis heute: Eine Datei der Länge 0 ... Fortsetzung folgt. Hoffentlich 😉

3 Kommentare zu “Remote-Datenrettung (1)”

  1. LOL quakte:

    ssh != sshd. Für X11 übers Netzwerk braucht man doch kein NX. Das geht doch nativ mit ssh -X bzw. ssh -Y. Bei dd sollte man unbedingt bs=… benutzen, denn mit 512 kleinem Puffer dauerts gern mal 10x so lange. 64-256 KiB sollte man sich schon können per USB sowieso.

    Bei Megabytes ist immer fraglich, was überhaupt gemeint ist. Gesunde Menschen wissen das Mega „Million“ bedeutet. Weniger gesunde Menschen verwechseln das manchmal mit Mebi (2^20). Leider sind viele Frickler nicht so furchtbar kerngesund. Da kommt es dann schon einmal zu Inkontinenzen zwischen Applikation A und Programm B.


  2. frosch quakte:

    Zum Installieren in Debian gibt man ssh an. Der sshd kommt dabei mit. — Oder meinst Du den in Knoppix? Das kann natürlich sein, daß das ein reiner Client ist. Ich benutze Knoppix nicht regulär, nur zum Testen (und dafür werde ich wohl auf grml wechseln).

    X11 über 2 x DSL 6000 (Upload: max. 768 kBit/s) — nein, das will man nicht wirklich. nx zeichnet sich dadurch aus, daß es gerade auch auf solchen Verbindungen fast genauso schnell ist, als würde man lokal arbeiten. Und wieso sollte ich den großen Klotz X11 auf die entfernte Maschine werfen, wenn es mit dem kleinen nx auch geht (bzw. normalerweise gehen sollte)?

    Megabytes (1024) und Megabytes (1000) werden in der manpage zu dd explizit unterschieden (M/MB). Insofern gehe ich schon davon aus, daß der Programmierer resp. der Ersteller der manpage wußte, was er da schrieb. Und auch bei einem Tool wie gpart sollte man davon ausgehen können, daß diese Werte korrekt dargestellt werden. Genau diese manpage sollte ich aber nach einem Hinweis von anderer nochmal genauer durchgehen, denn möglicherweise ist gpart doch schon alles, was ich benötige.

    Über konkrete Tips freue ich mich natürlich. 🙂


  3. Loria quakte:

    Warum versucht ihr nicht mal folgendes:
    http://www.tim-bormann.de/gelschte-partition-wiederherstellen-mittels-testdisk/
    debianpaket vorhanden:
    apt-get install testdisk


Kommentieren

Bitte beachte die Kommentarregeln!

XHTML: Du kannst diese Tags verwenden: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>