Froschs Blog

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:

Das ließen wir dann über Nacht laufen.

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

History

Dieser Eintrag wurde am 18. Dezember 2009 um 16:32 verfaßt und unter Computer abgelegt. Sie können alle Antworten auf diesen Eintrag via RSS 2.0 verfolgen. Sie können einen Kommentar hinterlassen oder einen Trackback von Ihrer Website aus setzen.

Schlagwörter: Datenrettung, Linux, Software, Windows