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
fdisk -l /dev/sdbshows:
Device Boot Start End Blocks Id System /dev/sdb1 1 1953525167 976762583+ ee GPT
testdiskshows 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,
fsckreports 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
e2fsckreports a similar error:
$ sudo e2fsck /dev/sdb1 Password: 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
$ sudo dumpe2fs /dev/sdb1 dumpe2fs 1.42 (29-Nov-2011) dumpe2fs: Bad magic number in super-block while trying to open /dev/sdb1
-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
testdiskdeep 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
for i in $(grep e2fsck testdisk.log | uniq | cut -d " " -f 4); do sudo e2fsck -b $i -B 4096 /dev/sdb1 done
... all with the same
In my last attempt, I tried different filesystem offsets. For each offset
iis 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 (
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).