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 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 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 done ... 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)?