sudo apt-get install gcc autoconf automake boost-build libboost-dev libboost-regex-dev libboost-filesystem-dev libboost-program-options-dev

Als nächstes habe ich den aktuellsten Quelltext heruntergeladen:

svn co https://svn.sourceforge.net/svnroot/jfsrec jfsrec

Im Verzeichnis jfsrec habe ich dann die Schritte configure und make und make install ausgeführt. Den Prefix mit /usr/local/jfsrec habe ich gewählt, weil ich das Programm mit stow verwalten will, wie schon in einem anderen Beitrag erwähnt.

cd jfsrec
./configure --prefix=/usr/local/jfsrec
make
make install
cd /usr/local
stow -R jfsrec

Nun kann man jfsrec verwenden. Ein beispielhafter Aufruf sieht so aus:

jfsrec --device /dev/mapper/crypt_root_sdb --output /recovery/root_sdb_jfsrec/ --logdir /recovery/root_sdb_log

Dabei wird versucht die verschlüsselte Partition /dev/mapper/crypt_root_sdb zu retten. Die Daten werden ins Verzeichnis /recovery/root_sdb_jfsrec/ geschrieben und die Informationen über die inodes werden im Verzeichnis /recovery/root_sdb_log abgelegt. Zu beachten ist, dass es durchaus einige Zeit dauern kann, bis jfsrec seine Arbeit erledigt hat. Bei mir wurden für etwa 240 GB acht bis zehn Stunden benötigt. Bei den Dateinamen musste ich jedoch feststellen, dass die Umlaute und Sonderzeichen falsch dargestellt wurden. Dieses Problem konnte ich jedoch mit dem Programm convmv beheben. Convmv ist ein kleines Komandozeilen-Programm um Dateinamen von einem Zeichensatz in einen anderen zu konvertieren. In meinem Fall half folgender Aufruf um die wiederhergestellten Datei- und Verzeichnisnamen in /recovery/root_sdb_jfsrec/ wieder richtig darzustellen.

convmv -f utf8 -t latin1 -r --notest /recovery/root_sdb_jfsrec/

Mein neues System hatte ich auf /dev/sda installiert. Im Zuge der Neuinstallation hatte ich vier Partitionen erstellt: /dev/sda1 bis /dev/sda4, die teilweise auch verschlüsselt sind. Auf der Platte /dev/sda musste ich also nach meinem alten LUKS-Header für die Datenpartition suchen. Bevor man jedoch mit der Suche loslegt, sollte man auf Nummer sicher gehen und die Partition in den nur-Lesemodus versetzen.

sudo chmod 400 /dev/sda*

Mit dem Hex-Editor hexedit suchen wir nun nach LUKS-Headern:

sudo hexedit /dev/sda

Mit der Taste <Tab> erstmal in den ASCII-Teil wechseln und dann mit der Tastenkombination <Strg>+<S> die Suche nach dem Wort LUKS starten. Sobald ich einen Header gefunden hatte, musste ich überprüfen, ob es ein Header der neuen verschlüsselten Partition war oder aber der meiner alten, den ich verzweifelt suchte. Dazu öffnete ich dann jeweils die anderen Partitionen im Hexeditor und verglich die Zeichenfolgen, die ein paar Bytes nach dem Schlüsselwort LUKS kommen.

sudo hexedit /dev/sda1

Nachdem ich an dem Offset 0×2E44CCC00 den entsprechenden Header meiner alten Partition gefunden hatte, musste ich noch herausfinden, wie groß die alte Partition war. Ich hatte Glück, da die Partition den gesamten Rest der Festplatte einnahm und somit 237639177216 Bytes groß gewesen sein musste.

Mit diesen Informationen kann man nun mittels losetup ein Loopback-Device erzeugen, das genau auf den Teil verweist, der die urpsrüngliche verschlüsselte Partition ausgemacht hat.

sudo losetup -o @0x2E44CCC00 -s 237639177216 /dev/loop1 /dev/sda

Nun kann man das Loopback-Device ebenfalls read-only setzen und mit cryptsetup öffnen

sudo chmod 400 /dev/loop1
sudo cryptsetup -d /path/to/key luksOpen /dev/loop1 cryptbackup

Die Partition können wir nun mit mounten mit einem

mount -t jfs -o ro /dev/mapper/cryptbackup /mnt/recover

oder als Image sichern (Achtung unverschlüsselt!)

dd if=/dev/mapper/cryptbackup of=/location/to/backup.img bs=10M

Den Fortschritt von dd kann man übrigens mit

while /bin/true; do sleep 5; kill -USR1 DD-PID; done

verfolgen.