![[Screenshot: Autopsy-Webinterface in Firefox. Verzeichnis Bilder soll nicht mehr zu retten sein.]](autopsy-screenshot-670x618.png "Nichts zu machen.")
Autopsy möchte ich im Ernstfall jedenfalls nicht vertrauen müssen, die defekten Bilder wurden nicht mal
gefunden, das Verzeichnis selbst zwar noch erkannt, aber als nicht mehr zu retten angezeigt.
www.fabiankeil.de/blog-surrogat/2006/06/04/bilder-suche-nach-daten-kau.html
Vor etwa zwei Wochen habe ich mein Heimatverzeichnis von /usr auf ein
eigenes Slice übertragen um geli
nutzen zu können. Der gesamte Inhalt wird nun auf Dateisystem-Ebene verschlüsselt und ich muss mich
nicht mehr um jede schützenswerte Datei einzeln kümmern.
Vorher war es auf /usr bereits etwas eng geworden, obwohl
ich Fotos und andere größere Dateien auf das msdosfs-Slice /dev/ad0s2
ausgelagert hatte. Die FAT32-Formatierung
stammte noch aus der Anfangszeit, beim Kauf war auf dem Laptop Windows XP installiert
und ich hatte zuerst vor, Windows und FreeBSD parallel zu nutzen. Eine Partition, auf
die beide Betriebssysteme schreiben können, erschien mir daher sinnvoll.
Zu der Parallelnutzung ist es nie gekommen, als ich Windows löschte
war ich aber zu faul /dev/ad0s2 auf ein anständiges Dateisystem umzuformatieren.
Nach dem Verschieben des Heimatverzeichnisses war die externe Speicherung der Bilder nicht mehr nötig, alle verlinkten Verzeichnisse wurden durch harte Kopien ersetzt. Im Heimatverzeichnis ist noch immer genug Luft:
fk@TP51 ~ $df -h Filesystem Size Used Avail Capacity Mounted on /dev/ad0s3a 248M 78M 150M 34% / devfs 1.0K 1.0K 0B 100% /dev /dev/ad0s3e 248M 85M 143M 37% /tmp /dev/ad0s3f 8.0G 5.6G 1.8G 76% /usr /dev/ad0s3d 248M 100M 128M 44% /var /dev/ad0s1.eli 18G 11G 5.1G 69% /usr/home/fk devfs 1.0K 1.0K 0B 100% /var/named/dev <above>:/usr/src-patched 16G 14G 1.8G 89% /usr/src /dev/ad0s2 9.2G 5.9G 3.4G 64% /mnt/ad0s2
/usr enthält noch die alte unverschlüsselte Version meines Heimatverzeichnisses,
sobald die gelöscht ist, sollte auch dort wieder Platz sein.
Vor ein paar Tagen wollte ich mit dem Bericht zum iRiver-Akku-Tausch anfangen, durfte aber feststellen, dass Gimp meine Fotos nicht mehr öffnen wollte. Nicht nur die neuen – alle. Meine Hoffnung auf ein Gimp-Problem hielt nicht lange, auch auf anderen Rechnern hatte ich kein Glück.
Die Bilder auf dem msdosfs-Slice hatten die gleichen Probleme, die Bilder waren also schon vor dem Kopieren defekt – warum auch immer. Das fand ich erstmal nicht so schön, der angekündigte Bericht über den Akku-Tausch wurde verschoben und ich machte mich statt dessen auf die Backup-Suche.
Die Frequenz meiner Backups hatte etwas unter dem noch immer ungelösten Samba-Ausfall gelitten: manuelle Sicherungen werden schnell unbequem, wenn kein fertig konfigurierter Server dafür bereits steht und die Netzwerk-Übertragung Jahre dauert.
Datenverlust gab es dann doch keinen, auf der zweiten Festplatte von
Casablanca
lag noch die Sicherung, die ich vor dem geli-Umstieg gemacht hatte. Die Funk-Übertragung dauerte
zwar eine halbe Ewigkeit:
ftp> get home-bilder-2006-05-22.tar.gz local: home-bilder-2006-05-22.tar.gz remote: home-bilder-2006-05-22.tar.gz 229 Entering Extended Passive Mode (|||60325|) 150 Opening BINARY mode data connection for 'home-bilder-2006-05-22.tar.gz' (4851053359 bytes). 100% |******************************************************| 4626 MB 554.70 KB/s 00:00 ETA 226 Transfer complete. 4851053359 bytes received in 2:22:20 (554.70 KB/s)
anschließend konnte ich jedoch alle Bilder mit sauberen Versionen überschreiben und mir die ad0s2-Überreste näher anschauen, um für den Ernstfall zu proben.
Autopsy möchte ich im Ernstfall jedenfalls nicht vertrauen müssen, die defekten Bilder wurden nicht mal
gefunden, das Verzeichnis selbst zwar noch erkannt, aber als nicht mehr zu retten angezeigt.
Mit FreeBSD dagegen kann ich noch alle Dateien sehen und kopieren, auch wenn die Dateien selbst beschädigt sind.
Spaßeshalber habe ich auch noch ein merkwürdiges Perl-Skript auf die Bilder-Suche geschickt, stieß aber auf leichte Probleme:
fk@TP51 ~/test $./imagerecovery.pl /dev/ad0s2 image-recovery/
./imagerecovery.pl: line 2: print: command not found
./imagerecovery.pl: line 3: =: command not found
./imagerecovery.pl: line 4: syntax error near unexpected token `{'
./imagerecovery.pl: line 4: `if ($argsLen < 2) {'
Hauptsächlich, da es wegen fehlerhaften Shebangs als Shell-Skript behandelt wird. Nach etwas Frickelei:
fk@TP51 ~/test $diff -u imagerecovery.pl cfr.pl
--- imagerecovery.pl Sun Jun 4 18:13:24 2006
+++ cfr.pl Sun Jun 4 18:14:49 2006
@@ -1,4 +1,4 @@
-#/usr/bin/perl -w
+#!/usr/bin/perl -w
print "Starting CompactFlash card recovery\n";
$argsLen = $#ARGV + 1;
if ($argsLen < 2) {
@@ -11,18 +11,16 @@
}
open (DUMPFILE, $ARGV[0]);
-my $line;
-while () {
- $line = $line.$_;
-}
+local( $/);
+my $line = <DUMPFILE>;
my @files = split(/\xff\xd8\xff\xe1/, $line);
my $size = @files;
close(DUMPFILE);
print "There are potentially " . $size . " files on the disk ...\n";
-print "An attempt will now be made to recover the images.\n"
+print "An attempt will now be made to recover the images.\n";
print "... this may take some time!\n";
-for (my $i=0; $i<=$size; $i++) {
+for (my $i=0; $i<$size; $i++) {
open (NEWFILE, "> " . $ARGV[1] . "/" . $i . ".jpeg") or
die "Error cannot create new file\n";
print NEWFILE "\xff\xd8\xff\xe1".$files[$i];
konnte ich es dann sogar starten. Nur um zu sehen, wie es sich an der Größe des defekten Dateisystems verschluckte:
fk@TP51 ~/test $./cfr.pl /dev/ad0s2 image-recovery/ Starting CompactFlash card recovery Out of memory during "large" request for 536875008 bytes, total sbrk() is 268550144 bytes at ./cfr.pl line 17.
Um das Image in einem Rutsch abzuarbeiten fehlten meinem Laptop geschätzte 35 Gigabyte Arbeitsspeicher. Immerhin: die ersten hundert Megabyte teilt das Skript klaglos in 36 Teile:
fk@TP51 ~/test $./cfr.pl ad0s2.image.teil1 image-recovery/ Starting CompactFlash card recovery There are potentially 36 files on the disk ... An attempt will now be made to recover the images. ... this may take some time!
![[Screenshot: Gimp zeigt in der Vorschau einen Monitor an, das geöffnete Bild ist fehlerhaft und besteht hauptsächlich aus einen GVU-Bild]](gerettetes-bild-585x609.png "Vorschau und Realität")
Es gönnt sich dafür immer noch bescheidene 400 Megabyte Arbeitsspeicher, aber was soll's.
Zu 32 der 36 Dateien kann Gimp noch eine Vorschau erstellen, auch wenn sie oft vom Endergebnis geringfügig abweicht.
Drei davon werden ohne Fehlermeldung geladen und anschließend korrekt angezeigt.
Da ich keines der drei Bilder über das defekte Dateisystem lesen kann, werte ich das als kleinen Erfolg. Auch wenn die geretteten Bilder natürlich nicht korrekt beschnitten werden und am Datei-Ende Fragmente aus anderen Dateien enthalten,
fk@TP51 ~/test/image-recovery $hd 3.jpeg > 3.hex
fk@TP51 ~/test/image-recovery $hd ~/bilder/camera/eos350d/IMG_3070.JPG > 3-original.hex
fk@TP51 ~/test/image-recovery $diff -u 3-original.hex 3.hex | head -n 20
--- 3-original.hex Sun Jun 4 19:02:12 2006
+++ 3.hex Sun Jun 4 19:02:05 2006
@@ -119296,5 +119296,4091 @@
001d25f0 6d 0c 1b bc c4 11 8d a7 70 3b 58 e7 f4 ac 69 5c |m..¼Ä..§p;Xçô¬i\|
001d2600 c9 2b ac 85 4e 00 09 2a 8c 71 f5 e9 8a f3 6a d3 |É+¬.N..*.qõé.ójÓ|
001d2610 a5 2a b1 e6 7a 1d 15 b1 0e 94 63 4e 51 ba ee 7f |¥*±æz..±..cNQºî.|
-001d2620 ff d9 |ÿÙ|
-001d2622
+001d2620 ff d9 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |ÿÙ..............|
+001d2630 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
+*
+001d4000 67 69 6d 70 20 78 63 66 20 66 69 6c 65 00 00 00 |gimp xcf file...|
+001d4010 04 00 00 00 03 00 00 00 00 00 00 00 00 11 00 00 |................|
+001d4020 00 01 01 00 00 00 13 00 00 00 08 42 96 00 00 42 |...........B...B|
+001d4030 96 00 00 00 00 00 14 00 00 00 04 00 00 00 02 00 |................|
+001d4040 00 00 16 00 00 00 04 00 00 00 01 00 00 00 15 00 |................|
+001d4050 00 01 24 00 00 00 10 67 69 6d 70 2d 69 6d 61 67 |..$....gimp-imag|
+001d4060 65 2d 67 72 69 64 00 00 00 00 01 00 00 01 08 28 |e-grid.........(|
+001d4070 73 74 79 6c 65 20 69 6e 74 65 72 73 65 63 74 69 |style intersecti|
+001d4080 6f 6e 73 29 0a 28 66 67 63 6f 6c 6f 72 20 28 63 |ons).(fgcolor (c|
fk@TP51 ~/test/image-recovery $tail 3-original.hex
001d25a0 49 55 03 e7 3e 9d fa fa 7b d6 4e 5c 98 65 cd a5 |IU.ç>.úú{ÖN\.eÍ¥|
001d25b0 8d 27 42 35 9d 5a f2 5a 8b a4 5f 34 9b 6d de 37 |.'B5.ZòZ.¤_4.mÞ7|
001d25c0 8c 34 9f 29 70 bc fa 7b f6 fe 55 b5 70 d9 69 7f |.4.)p¼ú{öþUµpÙi.|
001d25d0 7d b5 d9 79 da 0e 14 71 ef e9 5b d5 8c e7 18 ce |}µÙyÚ..qïé[Õ.ç.Î|
001d25e0 6e f7 d7 e4 65 4a bc 2a 59 46 36 e9 a9 a2 93 46 |n÷×äeJ¼*YF6é©¢.F|
001d25f0 6d 0c 1b bc c4 11 8d a7 70 3b 58 e7 f4 ac 69 5c |m..¼Ä..§p;Xçô¬i\|
001d2600 c9 2b ac 85 4e 00 09 2a 8c 71 f5 e9 8a f3 6a d3 |É+¬.N..*.qõé.ójÓ|
001d2610 a5 2a b1 e6 7a 1d 15 b1 0e 94 63 4e 51 ba ee 7f |¥*±æz..±..cNQºî.|
001d2620 ff d9 |ÿÙ|
001d2622
fk@TP51 ~/test/image-recovery $ls -l ~/bilder/camera/eos350d/IMG_3070.JPG 3.jpeg
-rwxr-xr-x 1 fk fk 1910306 Apr 29 10:18 /home/fk/bilder/camera/eos350d/IMG_3070.JPG
-rw-r--r-- 1 fk fk 3588096 Jun 4 18:21 3.jpeg
Ohne Backup sähe die Einschätzung möglicherweise anders aus ...