Datenrettung mit ext3grep - Assertion `!reused_or_corrupted_

[sukram]

Ich habe ausversehen mein Profile von icedove auf einer ext3 Partition gelöscht und habe nur eine 2 Wochen alte Datensicherung.
Ich versuche deshalb mit ext3grep an die Daten heranzukommen was aber immer mit einer Fehlermeldung endet.
Ich habe die betroffene Partition ausgehängt.

Das Programm scheint ja Blöcke (Blocks count: 120487492) zu finden bricht aber immer mit folgender Maldung ab:

ext3grep: journal.cc:379: void init_journal(): Assertion `!reused_or_corrupted_indirect_block4' failed.

Ist das jetzt ein Programmfehler oder kann ich eine Datenrettung vergessen?

Code: Alles auswählen

# ext3grep /dev/sdb1 --superblock | grep 'size:'Block size: 4096
Fragment size: 4096
ext3grep: journal.cc:379: void init_journal(): Assertion `!reused_or_corrupted_indirect_block4' failed.

Code: Alles auswählen

# ext3grep /dev/sdb1 --superblock | grep 'Blocks count:'
Blocks count: 120487492
ext3grep: journal.cc:379: void init_journal(): Assertion `!reused_or_corrupted_indirect_block4' failed.

Code: Alles auswählen

# ext3grep /dev/sdb1 --dump-names
Running ext3grep version 0.10.1
WARNING: I don't know what EXT3_FEATURE_COMPAT_EXT_ATTR is.
Number of groups: 3677
ext3grep: journal.cc:379: void init_journal(): Assertion `!reused_or_corrupted_indirect_block4' failed.

Code: Alles auswählen

# ext3grep --journal /dev/sdb1
Running ext3grep version 0.10.1
No action specified; implying --superblock.

WARNING: I don't know what EXT3_FEATURE_COMPAT_EXT_ATTR is.
Journal Super Block:

Signature: 0x3225106840
Block type: Superblock version 2
Sequence Number: 0
Journal block size: 4096
Number of journal blocks: 32768
Journal block where the journal actually starts: 1
Sequence number of first transaction: 152853
Journal block of first transaction: 0
Error number: 0
Compatible Features: 0
Incompatible features: 1
Read only compatible features: 0
Journal UUID: 0x55 0xed 0xa9 0x73 0xd7 0xc0 0x4d 0x28 0xb4 0xae 0xe7 0x6d 0x8a 0x09 0xc2 0x2a
Number of file systems using journal: 1
Location of superblock copy: 0
Max journal blocks per transaction: 0
Max file system blocks per transaction: 0
IDs of all file systems using the journal:
1. 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00

ext3grep: journal.cc:379: void init_journal(): Assertion `!reused_or_corrupted_indirect_block4' failed.

[robi1]

ext3grep hat Probleme die Journalfile zu öffnen. Für ext3grep ist das Journal defekt.

versuche mal "extundelete" oder "ext4magic" die haben beide nicht diese handgezimmerten Methode die Files und Daten "zu Fuß" zu öffnen, sondern verwendne die offiziellen oder nur leicht modifizierte Routinen aus der ext2lib Library zum Zugriff auf das Filesystem.

robi1

[sukram]

versuche mal "extundelete" oder "ext4magic" die haben beide nicht diese handgezimmerten Methode die Files und Daten "zu Fuß" zu öffnen, sondern verwendne die offiziellen oder nur leicht modifizierte Routinen aus der ext2lib Library zum Zugriff auf das Filesystem.

Danke für den Hinweis bzgl. des Journals.
Die anderen beiden Tools kannte ich noch nicht und werde sie mir gleich mal anschauen.

[sukram]

extundelete konnte zwar sehr viele Dateien wiederherstellen aber leider war das gelöschte Profile mit all meinen Mails von mozilla-thunderbird nicht dabei.

[robi1]

extundelete konnte zwar sehr viele Dateien wiederherstellen aber leider war das gelöschte Profile mit all meinen Mails von mozilla-thunderbird nicht dabei.

hast du "--restore-all" versucht ?
wenn ja , dann müsste man das Journal etwas näher untersuchen, um dir hier noch weiter zu helfen.

Entweder 1. es sind gar keine Kopien von diesem Filesystem-Abschnitt im Journal (nicht sehr wahrscheinlich) ,
oder 2. es wurde nur ein Einstiegsverzeichnis zu den Datenabschnitt nicht gefunden,
oder 3. es wurde in der Zwischenzeit ein neues Verzeichnis und eventuell auch einzelner Dateien mit den selben Namen schon wieder erstellt. oder 4. es sind dort HTREE Daten in den Verzeichnisdaten die das recovern erschweren.
oder oder oder oder .....

Das 2. und 3. der Probleme könnte mit ext4magic und genau gesetzten Optionen

Code: Alles auswählen

ext4magic DEVICE -r  -a A-ZEIT  -b B-ZEIT -f VERZEICHNIS -d ZIELVERZEICHNIS 

eventuell eine Lösung sein, um die Dateien dort noch zu finden.

Ansonsten für das 1. Problem hat ext4magic auch noch eine Funktion die bei ext3 auch Dateien finden kann, ohne die Inode Kopie dafür im Journal gefunden zu haben. Es lässt sich dort ein File Carver nach schalten. (nennt sich dort Magic Function)

Voraussetzung dafür wäre, nach dem Löschen ist nicht mehr allzuviel auf dem Filesystem passiert. Dauert aber eventuell auch recht lange, je nach Größe des Filesystems und wieviel Daten dort gelöscht wurden, und ob die Metadaten in den Journaldaten die während des Löschvorgangs geschrieben wurden noch im Journal enthalten ist.

Code: Alles auswählen

ext4magic DEVICE -a A-ZEIT -m -d ZIELVERZEICHNIS

das 4. Problem ist in ext4magic gepacht und beseitigt, aber im Moment noch nicht in der aktuellen Version enthalten.

Zu den Optionen:

DEVICE = das Filesystemdevice zB /dev/sda1
A-ZEIT = die genaue (+0s bis -60 s) Zeit vor dem Löschen der ersten File in Sekunden
B-ZEIT = die Zeit nach dem Löschen (muss größer als A_ZEIT, und sollte nähe Endzeit des Löschens oder etwas früher.)
ZIELVERZEICHNIS = ein Verzeichnis auf einem ext3/ext4 Filesystem das genügend Platz hat, um die recoverten Daten aufzunehmen.
VERZEICHNIS = Das Verzeichnis dessen Daten du recovern willst (vom Filesystem aus gesehen, nicht vom kompletten Linuxdateibaum)
alternativ könnte auch mit "-I INODENUMMER" die Inodenummer des ehemaligen Verzeichnisses angegeben werden, diese Inodenummer muss aber auch erst ermittelt werden.


Zum Ermitteln der genauen Zeiten könnte man die " Option -H" verwenden.

Es geht mit diesem Tool noch einiges mehr, muss man sich aber wohl etwas näher damit befassen, und das betroffene Filesystem vor sich haben.

robi1

[sukram]

hast du "--restore-all" versucht ?

Erst mal vielen Dank das Du mir das so ausführlich erklärst.

Ja ich hatte --restore-all gewählt.
Bevor ich mit Deinen anderen Vorschlägen weitermache möchte ich gerne wissen was es mit den vielen file.nnnnnnnn Dateien auf sich hat.

Code: Alles auswählen

RECOVERED_FILES$ ls
file.20185096  file.20185190  file.20185384  file.20185432  file.20185484
file.20185104  file.20185191  file.20185386  file.20185433  file.20185485
file.20185106  file.20185192  file.20185389  file.20185434  file.20185491
file.20185107  file.20185216  file.20185390  file.20185435  file.20185495
file.20185108  file.20185218  file.20185391  file.20185436  file.20193281
file.20185114  file.20185220  file.20185392  file.20185437  file.20193302
file.20185122  file.20185221  file.20185393  file.20185438  file.20193305
file.20185125  file.20185222  file.20185394  file.20185439  file.20324418
file.20185126  file.20185223  file.20185395  file.20185440  file.20324419
file.20185127  file.20185224  file.20185396  file.20185441  file.20324420
file.20185129  file.20185225  file.20185397  file.20185442  file.20324421
file.20185130  file.20185226  file.20185401  file.20185444  file.20324422
file.20185131  file.20185227  file.20185402  file.20185445  file.20324423
file.20185132  file.20185228  file.20185403  file.20185446  file.20324424
file.20185133  file.20185229  file.20185404  file.20185449  file.20324425
file.20185157  file.20185230  file.20185405  file.20185450  file.20324426
file.20185158  file.20185237  file.20185407  file.20185451  file.20324427
file.20185159  file.20185240  file.20185408  file.20185452  file.20324428
file.20185161  file.20185242  file.20185409  file.20185453  file.20324429
file.20185162  file.20185243  file.20185410  file.20185454  file.20324430
file.20185163  file.20185244  file.20185411  file.20185457  file.20324431
file.20185164  file.20185246  file.20185412  file.20185458  file.20324433
file.20185165  file.20185248  file.20185413  file.20185459  file.20324434
file.20185166  file.20185249  file.20185414  file.20185460  file.20324435
file.20185171  file.20185250  file.20185415  file.20185461  file.20324538
file.20185172  file.20185251  file.20185416  file.20185463  file.20324539
file.20185173  file.20185252  file.20185417  file.20185464  file.20324540
file.20185175  file.20185253  file.20185418  file.20185465  file.20324541
file.20185177  file.20185255  file.20185419  file.20185466  file.20324542
file.20185178  file.20185256  file.20185420  file.20185467  file.20324543
file.20185179  file.20185257  file.20185422  file.20185468  file.20324544
file.20185180  file.20185258  file.20185423  file.20185469  file.20324546
file.20185181  file.20185259  file.20185424  file.20185470  file.20324847
file.20185182  file.20185260  file.20185425  file.20185471  lost+found
file.20185184  file.20185261  file.20185426  file.20185472  markus
file.20185185  file.20185378  file.20185428  file.20185475
file.20185186  file.20185380  file.20185429  file.20185477
file.20185187  file.20185381  file.20185430  file.20185479
file.20185188  file.20185382  file.20185431  file.20185483

Das für mich wichtigen Verzeichnis wurde zurückgeholt - hatte es aber nicht gesehen, da es ein verstecktes Verzeichnis ist (markus/.mozilla)-
Selbst das Verzeichnis für das Profile ist darin enthalten und darin wieder einige Dateien NUR DAS wichtige MAIL Verzeichnis ist nicht gerettet worden.

Kann es sein, dass die Informationen in den file.nnnnn Dateien stecken? Komme ich da irgendwie dran?

[robi1]

das sind gefundene Dateien denen keine Name zugewiesen werden konnte, da wahrscheinlich nicht genügend Daten von den gelöschten Verzeichnissen ( dort wo die Namen<->Inode Zuordnung erfolgt) gefunden wurden. Hier kann sich das Eine oder Andere wertvolle Fundstück noch wieder finden lassen, möglich ist aber auch mehr oder weniger Datenmüll dazwischen.

Für einen ersten Überblick, um was für Dateien es sich handeln könnte, folgenden Befehl.

Code: Alles auswählen

file *

dann kannst du die Dateien entsprechend der Dateitypen wieder richtig umbenennen und dann mit den normalen Grafischen Tools sichten und wieder richtige Namen geben. Bei Mail muss ich da aber auch passen, die hatten glaube ich immer ein bisschen irgendwie kryptische Namen und irgenwo gab es einen Index dazu. Wie man solche roh recoverten Mailarchive wieder repariert und wieder brauchbar zu einem Postfach zusammen bauen kann, bin ich auch überfragt.

Wenn du einigermaßen fit auf der Bash bist, kannst du zu mindestens Dokumente, Bilder und ähnliches von dort bequem mit ein paar Befehlen in wieder brauchbare Dateien umwandeln.

robi1

[sukram]

Wenn du einigermaßen fit auf der Bash bist, kannst du zu mindestens Dokumente, Bilder und ähnliches von dort bequem mit ein paar Befehlen in wieder brauchbare Dateien umwandeln.

Das hört sich ja erst einmal recht gut an.
Ja, vor langer Zeit war ich mal recht gut bei der Umsetzung von Scripten usw. Mal sehen was davon noch übriggeblieben ist.
Ich hoffe da ist was brauchbares an Dateien dabei.