Inodes werden definitiv überschrieben: Unterschied zwischen den Versionen
Niki (Diskussion | Beiträge) (Die Seite wurde neu angelegt: x) |
Niki (Diskussion | Beiträge) |
||
| Zeile 1: | Zeile 1: | ||
| − | + | <section begin="head"/> | |
| + | Seit langem wieder ein großer Rückschlag bei meiner Datenrekonstuktion. Meine ewige Hoffnung war, dass vielleicht doch nicht alle inodes überschrieben sind. | ||
| + | |||
| + | Heute hab ich mich auf die Suche nach inodes gemacht... | ||
| + | <section end="head"/> | ||
| + | |||
| + | Dazu habe ich das Programm "e2salvage" umgebaut, und zwar so, dass es das komplette Image nach inodes durchsucht, und diese schön geordnet in eine Datei schreibt. | ||
| + | |||
| + | Auf der Datenpartition waren in etwa 111772 Dateien und Verzeichnisse, d.h. es müsste in etwa so viele inodes geben. Gefunden habe ich 85064 Inodes. Das hat sich auf den ersten Blick gut angesehen. | ||
| + | |||
| + | Meine große Befürchtung war aber, dass die inodes in Wirklichkeit nicht von meiner Datenpartition stammen. Denn auf der Datenpartition war noch ein ca 1GB großes ext2-Image für ein UML-Linux. Ebenfalls mit Blockgröße 4096. | ||
| + | |||
| + | Erste Stichproben mit den ersten Datenblöcken verschiedener inodes brachten jedoch schon die Ernüchterung: Die referenzierten Datenblöcke konnten ganz einfach nicht zum inode gehören, z.B. weil in den betreffenden Blöcken gar nie Padding dabei war, obwohl laut inode die Dateigröße < 4096 sein müsste. | ||
| + | |||
| + | Das folgende Script | ||
| + | |||
| + | <source lang="bash"> | ||
| + | dest=/mnt/backup/hda4test/dest_inode | ||
| + | |||
| + | grep ‘^Data:’ /inodes.txt | while read line | ||
| + | do | ||
| + | block=`echo $line | awk ‘{print $2}’` | ||
| + | |||
| + | echo $block | ||
| + | |||
| + | if test $block -le 3664828 | ||
| + | then | ||
| + | dd if=/mnt/backup/hda4test/hda4.bin of=/tmp/c.dat bs=4096 count=1 skip=$block 2>/dev/null | ||
| + | |||
| + | type=`file -b /tmp/c.dat` | ||
| + | type=`echo $type | sed -e ’s/[^ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0-9(),.-]/_/gi;’` | ||
| + | |||
| + | mkdir -p “$dest/$type” | ||
| + | cp /tmp/c.dat “$dest/$type/$block” | ||
| + | fi | ||
| + | done | ||
| + | </source> | ||
| + | |||
| + | kontrolliert nun extrahiert nun gerade alle "ersten" Datenblöcke. Aber schon während dem Verlauf sehe ich: Alle Blöcke sind einfach viel zu niedrig für meine Datenpartition. | ||
| + | Lediglich vereinzelt ein paar hohe oder sehr hohe Blöcke, die vermutlich Opfer der heuristischen Suche geworden sind. | ||
| + | |||
| + | Schade. Also bleibsts beim Puzzle-Bauen :-( | ||
| + | |||
| + | [[Kategorie:Weblog]] | ||
Version vom 1. Februar 2008, 16:25 Uhr
Seit langem wieder ein großer Rückschlag bei meiner Datenrekonstuktion. Meine ewige Hoffnung war, dass vielleicht doch nicht alle inodes überschrieben sind.
Heute hab ich mich auf die Suche nach inodes gemacht...
Dazu habe ich das Programm "e2salvage" umgebaut, und zwar so, dass es das komplette Image nach inodes durchsucht, und diese schön geordnet in eine Datei schreibt.
Auf der Datenpartition waren in etwa 111772 Dateien und Verzeichnisse, d.h. es müsste in etwa so viele inodes geben. Gefunden habe ich 85064 Inodes. Das hat sich auf den ersten Blick gut angesehen.
Meine große Befürchtung war aber, dass die inodes in Wirklichkeit nicht von meiner Datenpartition stammen. Denn auf der Datenpartition war noch ein ca 1GB großes ext2-Image für ein UML-Linux. Ebenfalls mit Blockgröße 4096.
Erste Stichproben mit den ersten Datenblöcken verschiedener inodes brachten jedoch schon die Ernüchterung: Die referenzierten Datenblöcke konnten ganz einfach nicht zum inode gehören, z.B. weil in den betreffenden Blöcken gar nie Padding dabei war, obwohl laut inode die Dateigröße < 4096 sein müsste.
Das folgende Script
dest=/mnt/backup/hda4test/dest_inode
grep ‘^Data:’ /inodes.txt | while read line
do
block=`echo $line | awk ‘{print $2}’`
echo $block
if test $block -le 3664828
then
dd if=/mnt/backup/hda4test/hda4.bin of=/tmp/c.dat bs=4096 count=1 skip=$block 2>/dev/null
type=`file -b /tmp/c.dat`
type=`echo $type | sed -e ’s/[^ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0-9(),.-]/_/gi;’`
mkdir -p “$dest/$type”
cp /tmp/c.dat “$dest/$type/$block”
fi
done
kontrolliert nun extrahiert nun gerade alle "ersten" Datenblöcke. Aber schon während dem Verlauf sehe ich: Alle Blöcke sind einfach viel zu niedrig für meine Datenpartition. Lediglich vereinzelt ein paar hohe oder sehr hohe Blöcke, die vermutlich Opfer der heuristischen Suche geworden sind.
Schade. Also bleibsts beim Puzzle-Bauen :-(
