Ext 3 or 2 file system recovery: Bad superblock with no working backup superblocks. What else can I try?

mount hard-drive filesystem data-recovery

10,394

It looks like something messed up your partition table. If the drive was partitioned with any software more recent than 7 years or so, the partition should begin on sector 2048, not sector 63. According to gpart, that is indeed where your filesystem starts, so you need to correct the partition table. Use fdisk to delete and recreate the partition but with a starting sector of 2048.

10,394

Author by

Programmeur

Updated on September 18, 2022

Comments

Programmeur over 1 year

I have a WD Green 2TB hard drive that used to be in an external case with USB 2.0 connection. To improve the communication speed, I took it out of the case and connected it to my PC through SATA.

On this hard drive I have one partition and I'm about 99% sure the file system is EXT3. Otherwise it might be EXT2 or 4. Before I took it out of the case it was working just fine, but now it seems the file system is corrupted.

When I try to mount the partition I get the following error:

ubuntu@ubuntu:~$ sudo mount /dev/sdb1 /media/wd/
mount: wrong fs type, bad option, bad superblock on /dev/sdb1,
       missing codepage or helper program, or other error

       In some cases useful info is found in syslog - try
       dmesg | tail or so.

I've tried several things to repair and recover the superblock. I read the following relevant posts:

sudo fdisk -l gives me the following output:

Disk /dev/sdb: 1.8 TiB, 2000398934016 bytes, 3907029168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0x00000000

Device     Boot Start        End    Sectors  Size Id Type
/dev/sdb1          64 3907024895 3907024832  1.8T 83 Linux

Parted doesn't indicate it found any file system:

Model: ATA WDC WD20EURX-63T (scsi)
Disk /dev/sdb: 2000GB
Sector size (logical/physical): 512B/4096B
Partition Table: msdos
Disk Flags: 

Number  Start   End     Size    Type     File system  Flags
 1      32.8kB  2000GB  2000GB  primary

I looked for backup superblocks like this:

ubuntu@ubuntu:~$ sudo mke2fs -n -S /dev/sdb1
mke2fs 1.42.13 (17-May-2015)
Creating filesystem with 488378104 4k blocks and 122101760 inodes
Filesystem UUID: 9e7b7f80-e70c-474a-b889-eff034b72fb0
Superblock backups stored on blocks: 
    32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
    4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 
    102400000, 214990848

However, when I checked all of those backups with sudo e2fsck -b <BLOCK NUMBER> /dev/sdb1, none of them seemed to work. For all of the backup superblocks I get the same output:

ubuntu@ubuntu:~$ sudo e2fsck -b 23887872 /dev/sdb1
e2fsck 1.42.13 (17-May-2015)
e2fsck: Bad magic number in super-block while trying to open /dev/sdb1

The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem.  If the device is valid and it really contains an ext2/ext3/ext4
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>
 or
    e2fsck -b 32768 <device>

I've also tried scanning the drive with gpart, which suggests that I was wrong in that it is a ext3 filesystem:

ubuntu@ubuntu:~$ sudo gpart /dev/sdb

Begin scan...
Possible partition(Linux ext2), size(1907726mb), offset(1mb)
End scan.

Checking partitions...
Partition(Linux ext2 filesystem): primary 
Ok.

Guessed primary partition table:
Primary partition(1)
   type: 131(0x83)(Linux ext2 filesystem)
   size: 1907726mb #s(3907022848) s(2048-3907024895)
   chs:  (0/32/33)-(1023/254/63)d (0/32/33)-(243201/13/12)r

Primary partition(2)
   type: 000(0x00)(unused)
   size: 0mb #s(0) s(0-0)
   chs:  (0/0/0)-(0/0/0)d (0/0/0)-(0/0/0)r

Primary partition(3)
   type: 000(0x00)(unused)
   size: 0mb #s(0) s(0-0)
   chs:  (0/0/0)-(0/0/0)d (0/0/0)-(0/0/0)r

Primary partition(4)
   type: 000(0x00)(unused)
   size: 0mb #s(0) s(0-0)
   chs:  (0/0/0)-(0/0/0)d (0/0/0)-(0/0/0)r

Other things I've tried:

ubuntu@ubuntu:~$ sudo dumpe2fs /dev/sdb1
dumpe2fs 1.42.13 (17-May-2015)
dumpe2fs: Bad magic number in super-block while trying to open /dev/sdb1
Couldn't find valid filesystem superblock.

ubuntu@ubuntu:~$ sudo fsck /dev/sdb1
fsck from util-linux 2.27.1
e2fsck 1.42.13 (17-May-2015)
ext2fs_open2: Bad magic number in super-block
fsck.ext2: Superblock invalid, trying backup blocks...
fsck.ext2: Bad magic number in super-block while trying to open /dev/sdb1

The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem.  If the device is valid and it really contains an ext2/ext3/ext4
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>

 or
    e2fsck -b 32768 <device>

Does anybody have any suggestions of what else I can try to recover my data?

Terrance over 6 years

Was the drive purchased as a Western Digital external? Sometimes manufacturers will make it so that the drive needs to be in the external case. I think it is a security feature that they implement. I was having the same issue with a Seagate External drive that I had.
Programmeur over 6 years

Yes it was, however it looks like a normal hard drive with no extra features and I formatted the drive before I started using it.
Terrance over 6 years

Did you format it in the external enclosure? See tomshardware.com/answers/id-2953530/… where the drives might have an issue with being formatted in something else then put into the computer.
Programmeur over 6 years

Yes, it was in the enclosure when I formatted it. I will try using it again with the enclosure to see if that works.
Programmeur over 6 years

The problem persists when I connect it through the original enclosure (with USB).
Programmeur over 6 years

It says "Found invalid GPT and valid MBR; converting MBR to GPT format in memory. THIS OPERATION IS POTENTIALLY DESTRUCTIVE! Exit by typing 'q' if you don't want to convert your MBR partitions to GPT format!". fdisk does show the partition table properly.
Terrance over 6 years

OK, don't use gdisk then. No worries there. I use that application at work on the GPT disks to recover them. I am agreeing with @psusi answer. However, the new partition will be empty. You can try applications like photorec to try to recover the lost applications / files.

Programmeur over 6 years

If I do this, can I still access the files from the original partition or will the new partition be empty?
Programmeur over 6 years

Something indeed seemed to have messed up my partition table. I ended up using testdisk to change the partition table. All my data is restored.