Recovering ext4 superblocks

  • Recently, my external hard drive enclosure failed (the hard drive itself powers up in another enclosure). However, as a result, it appears its EXT4 file system is corrupt.

    The drive has a single partition and uses a GPT partition table (with the label ears).

    fdisk -l /dev/sdb shows:

       Device Boot      Start         End      Blocks   Id  System
         /dev/sdb1          1  1953525167   976762583+  ee  GPT

    testdisk shows the partition is intact:

    1 P MS Data                     2049 1953524952 1953522904 [ears]

    ... but the partition fails to mount:

    $ sudo mount /dev/sdb1 a
    mount: you must specify the filesystem type
    $ sudo mount -t ext4 /dev/sdb1 a 
    mount: wrong fs type, bad option, bad superblock on /dev/sdb1,

    fsck reports an invalid superblock:

    $ sudo fsck.ext4 /dev/sdb1            
    e2fsck 1.42 (29-Nov-2011)
    fsck.ext4: Superblock invalid, trying backup blocks...
    fsck.ext4: Bad magic number in super-block while trying to open /dev/sdb1

    and e2fsck reports a similar error:

    $ sudo e2fsck /dev/sdb1        
    e2fsck 1.42 (29-Nov-2011)
    e2fsck: Superblock invalid, trying backup blocks...
    e2fsck: Bad magic number in super-block while trying to open /dev/sdb1

    dumpe2fs also:

    $ sudo dumpe2fs /dev/sdb1                      
    dumpe2fs 1.42 (29-Nov-2011)
    dumpe2fs: Bad magic number in super-block while trying to open /dev/sdb1

    mke2fs -n (note, -n) returns the superblocks:

    $ sudo mke2fs -n /dev/sdb1       
    mke2fs 1.42 (29-Nov-2011)
    Filesystem label=
    OS type: Linux
    Block size=4096 (log=2)
    Fragment size=4096 (log=2)
    Stride=0 blocks, Stripe width=0 blocks
    61054976 inodes, 244190363 blocks
    12209518 blocks (5.00%) reserved for the super user
    First data block=0
    Maximum filesystem blocks=4294967296
    7453 block groups
    32768 blocks per group, 32768 fragments per group
    8192 inodes per group
    Superblock backups stored on blocks: 
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
        4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 
        102400000, 214990848

    ... but trying "e2fsck -b [block]" for each block fails:

    $ sudo e2fsck -b 71663616 /dev/sdb1 
    e2fsck 1.42 (29-Nov-2011)
    e2fsck: Invalid argument while trying to open /dev/sdb1

    However as I understand, these are where the superblocks were when the filesystem was created, which does not necessarily mean they are still intact.

    I've also ran a testdisk deep search if anyone can decypher the log. It mentions many entry like:

    recover_EXT2: s_block_group_nr=1/7452, s_mnt_count=6/20,
    s_blocks_per_group=32768, s_inodes_per_group=8192
    recover_EXT2: s_blocksize=4096
    recover_EXT2: s_blocks_count 244190363
    recover_EXT2: part_size 1953522904
    recover_EXT2: "e2fsck -b 32768 -B 4096 device" may be needed

    Running e2fsck with those values gives:

    e2fsck: Bad magic number in super-block while trying to open /dev/sdb1

    I tried that with all superblocks in the testdisk.log

    for i in $(grep e2fsck testdisk.log | uniq | cut -d " " -f 4); do
       sudo e2fsck -b $i -B 4096 /dev/sdb1

    ... all with the same e2fsck error message.

    In my last attempt, I tried different filesystem offsets. For each offset i, where i is one of 31744, 32768, 1048064, 1049088:

    $ sudo losetup -v -o $i /dev/loop0 /dev/sdb

    ... and running testdisk /dev/loop0, I didn't find anything interesting.

    I've been fairly exhaustive, but is there any way to recover the file system without resorting to low-level file recovery tools (foremost/photorec)?

    What does `sudo fdisk -l /dev/sdb` show?

    I can't make myself believe that you were unlucky enough to have _all_ copies of the superblock wiped. So there must be something wrong with the partition table, which in turn is throwing off the logical block offsets in the filesystem causing fsck to not be able to find the alternate superblocks.

    Didn't you have on this disk LVM? Do you have a external enclosure the same type as previous (same block size, etc.)?

    @KyleJones Following advice from the author of `testdisk`, as mentioned above, I tried different offsets using `losetup` (`i * 512` where `i` is one of 62, 64, 2047 or 2049).

    @JanMarek No, no LVM unfortunately. The enclosure is one that houses any standard 3.5" disk, but I don't have another, nor a second 1TB disk.

  • tlvince

    tlvince Correct answer

    8 years ago

    Unfortunately, I was unable to recover the file system and had to resort to lower-level data recovery techniques (nicely summarised in Ubuntu's Data Recovery wiki entry), of which Sleuth Kit proved most useful.

    Marking as answered for cleanliness' sake.

License under CC-BY-SA with attribution

Content dated before 6/26/2020 9:53 AM