Das Infolexikon

Wer war und ist der DAU? Ja, natürlich ich! Nachdem ich mich schon länger mit meinem Gentoo gekloppt habe, weil sich gcc, bzw. eher gcc-config nichtmehr dazu zwingen lassen wollte mir ausführbare Binaries zu schenken - musste ich dann doch irgendwann mal radikalere Maßnahmen ergreifen. Nachdem ich mir paar Configfiles und ähnliches vom alten System gebackupt hatte - war ich dann bereit wieder zu ArchLinux zu flüchten. Das lief auch wie gewohnt relativ flott. Kurz nachdem die meisten Sachen wieder funktioniert haben, hatte ich mich dazu entschlossen versehentlich beim Bestätigen eines Bashbefehls anstatt auf "Enter" zu knüppeln, noch schnell die PgUp Taste zu erwischen. Das führte in der Zeile dann zu einem rm -rf /home aus der Bash-History. Dann hab ich noch locker 3-5 Sekunden gebraucht um überhaupt zu verstehen, dass es nicht so lange dauern kann um ein ls auszuführen - also brachte der prüfende Blick auf die Zeile einen Strg+C Reflex mit sich - direkt aus dem Rückenmark^^ - und so begann die Quälerei...

Oh jeee

Zuerst dachte ich, es sei nichts wichtiges verschwunden. Doch nach rund 2(!) Stunden ist mir dann aufgefallen, dass ich halt wirklich mein aktuelles - noch nicht veröffentlichtes - Projekt ausschließlich hier auf dem Laptop habe - oder soll ich besser sagen: "hatte". Aber ja ReiserFS ist halt auch nun mal für seine schnellen Löschvorgänge bekannt.

Mörder und so

Btw. die orginal Seite von ReiserFS http://www.namesys.com ist leider nicht mehr erreichbar und es ist fraglich ob jemals wieder, Hans Reiser, der ReiserFS Vater wurde ja wegen Mordes an seiner Frau angeklagt und verurteilt. Also sind die einzigen offiziell verfügbaren ReiserFS Seiten von einem ehemaligen Mitarbeiter von namesys - schon krass irgendwie - Nerds sollten nicht morden^^

Rettung naht

Auf alle Fälle war das Verzeichnis weg und ich hab schon Eimer im Kreis um mich aufgestellt, da ich bereits mit akuten "Im-Kreis-kotzen" Anfällen gerechnet habe. Doch da kam mir die - eigentlich nicht so abwegige - Idee, dass man doch mal schauen könnte ob ich nicht Teile oder sogar ganze Dateien aus dem Projekt auf der Festplatte wiederfinde. Hier also

Rettungsmaßnahmen für gelöschte Dateien auf ReiserFS Partitionen

Zunächst einmal muss die Partition so schnell wie möglich umounted werden, jeder weitere Schreibzugriff könnte theoretisch eine noch vorhandene, aber gelöschte Datei auf der Festplatte überschreiben und so zu mehr Verlusten führen. (Bei mir wars die Home-Partition, ohne die kann man eine Zeit lang ganz gut leben)

Dann kann man folgendes versuchen:

$ cat /dev/sdaX | strings | grep <id> -B <davor> -A <danach> > /root/dump

id sollte eine regexp sein, welche den Inhalt der zu suchenden Datei möglichst eindeutig beschreibt. davor und danach geben an wie viele Zeilen vor respektive nach dem auffinden von id mitgenommen werden sollen. Als Beispiel: Ich habe nach Python Quellen gesucht, dort kann man schön davon ausgehen, dass die ersten Zeilen mit import bzw. from beginnen und gemächlich 500 Zeilen danach mitnehmen, Bei mir wars somit:

$ cat /dev/sda8 | strings | grep ^from -A 500 > /root/dump

Da kam für meine wenig benutzte - da grade mal einen Monat alt - mit grade mal 20GB Daten gefüllten 130GB Partition eine 58MB Textdatei raus (ist euch klar, dass es ein Text-only-Datei wegen strings ist, oder?^^) Das hat für mich schon gelangt und ich hatte nach einiger Wühl-Arbeit den Großteil von meinen Sources zurück und war angenehm überrascht. Ich hab sogar noch ältere Versionen von den Daten gefunden.

Doch ist es natürlich nicht immer eine Textdatei die man sucht, oder man möchte vielleicht ganze Verzeichnisstrukturen wiederherstellen. In Frage kommt noch eine andere

Methode zum Wiederherstellen von Verzeichnisstrukturen und/oder Binären Daten auf ReiserFS Partitionen

$ dd bs=1M conv=noerror,sync if=/dev/sdaX of=/root/full_dump
$ losetup /dev/loop4 /root/full_dump
$ reiserfsck --rebuild-tree --scan-whole-partition /dev/loop4
$ mount /dev/loop4 /mnt/some/path

Zunächst benutzen wir mighty dd und machen ein 1 zu 1 Abbild der Partition /dev/sdaX in das File /root/full_dump. Dabei benutzen wir bs=1M um die "blocksize" zu vergrößern und somit mehr Durchsatz rauszuholen. noerror ist offensichtlich um bei Lesefehlern nicht abzubrechen und sync um dadurch eventuell unvollständige Blöcke mit Leerzeichen aufzufüllen. ACHTUNG Dabei entsteht ein File, was exakt die Größe der Partition haben wird, also wählt das Ziel des Images mit bedacht! Daraufhin erstellen wir mittels losetup ein Blockdevice auf welches wir dann mit dem reiserfsck-tool losgehen. Benutzt diesen reiserfsck Befehl niemals(!) auf einer physikalischen Partition. Mit aller größter Wahrscheinlichkeit werden zahlreiche andere Dateien beschädigt oder besser gesagt verschoben. Hat man diesen Schritt nämlich fertig (Dauert wirklich ewig, bei mir weit über eine Stunde), kann man das Loopdevice mounten und im lost+found/ Ordner anfangen zu suchen. Es werden nur seeehr wenige Dateinamen stimmen, deshalb muss man in diesem Fall nach anderen Kriterien suchen wie zum Beispiel Dateigrößen oder auch file ist nützlich. Man kommt aber nicht drum herum auch diese Verzeichnis zu filtern, da man sonst mit 10.000den von Dateien zu kämpfen hat. Die Sprichwörtliche Nadel im Heuhaufen würde ich ma sagen^^

Achso und ich kann natürlich nicht einen dd Artikel schreiben ohne noch dazu zu sagen:

$ dd if=/dev/sdaX bs=1M conv=noerror,sync | gzip -9 > /to/some/path

was man vorzüglich benutzen kann um auch ganze Partitionen zu backupen. Die Größe der Dateien sinkt dadurch erheblich, nur leider kann man ein gzip'ed image nicht direkt als loopback device mounten, falls da jemand was zu weiß - als her damit!