cgsecurity.org

Posted: **05 Aug 2020, 22:06**

Dears,

tl;dr; I'm interested into ext4 filesystem tree recovery for corrupted journal inode.

I experienced a hard-drive corruption (an ext4 over LUKS over a WD hard-drive). It was carefully restored from ddrescue (although not completely).

- It can't be mounted as-is (too dirty).

Code: Select all

ext4_ext_map_blocks:4301: inode #8: comm mount: bad extent address lblock: 0, depth: 1 pblock 0
failed to initialize system zone (-117)

- testdisk can see some of the top-level directories. Not too bad, but still frustrating because the directories I'm the most interested in are not visible by testdisk.

- If I do a e2fsck (on a copy of the rescue copy), I see hundreds of thousands of errors of orphaned inodes, among others:

Entry 'super-important' in / (2) has deleted/unused inode 97518870. Clear<y>? yes

Entry 'videos' in / (2) has deleted/unused inode 94765075. Clear<y>? yes

Entry 'books' in / (2) has deleted/unused inode 81002530. Clear<y>? yes

Entry 'photos' in / (2) has deleted/unused inode 81002531. Clear<y>? yes

...

These are the one invisible directories from testdisk. After e2fsck, files are put in the-horrible-lost+found-flat-list.

When running dumpe2fs, I get some other information, but detailed information about the journal super block is unavailable:

Code: Select all

dumpe2fs: Corrupt extent header while reading journal super block

So, e2fsck is somehow able to identify:

inode of files and their content

inode, filename, and parent directory

And if I'm myself able to say whether they use to be file, symlinks or directory.

Do you know of any way testdisk (or any other tool) could help me to further recover this part. In an ideal world, I'd run testdisk which would say:

Code: Select all

You got an orphaned inode found: "photos" at 81002531 used to be under "/", e2fsck would drop it under lost+found, but testdisk will link this back to its original place.
Please select: Was is <directory> - <file> - <symlink> - ... ? [select "<directory>"]
Relinking to "/" done.

First, is an ext4 disk layout with this state of corruption (that journal inode #8 and these orphaned directories after e2fsck) still offer a theoretical possibility of recovery?

If yes, could testdisk be in the future, such a salvation tool? If not what am I left with currently?

Posted: **06 Aug 2020, 07:43**

drzraf wrote: 05 Aug 2020, 22:06 Do you know of any way testdisk (or any other tool) could help me to further recover this part. In an ideal world, I'd run testdisk which would say:

Testdisk won't recover more than you found.
Other tools may recover more depending on the degree of analysing remains of metadata in your file system.

First, is an ext4 disk layout with this state of corruption (that journal inode #8 and these orphaned directories after e2fsck) still offer a theoretical possibility of recovery?

Yes.

If yes, could testdisk be in the future, such a salvation tool? If not what am I left with currently?

I am not aware of plans of Christophe Grenier to extend Testdisk so that it ressembles commercial tools.
You are left with what you found. You might recover other files for the price of loosing metadata such as file names using Photorec.

cgsecurity.org

ext4 file hierarchy recovery

ext4 file hierarchy recovery

Re: ext4 file hierarchy recovery