mount: wrong fs type, bad option, bad superblock on /dev/sdb on CentOS 6.0

Question

Somehow my partition on /dev/sdb has gotten all buggered up. This hard drive contains a lot of data that I need to recover and haven't been able to backup yet. When I attempt to mount it:

# mount -t ext4 /dev/sdb /world
mount: wrong fs type, bad option, bad superblock on /dev/sdb,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

Also when I run fdisk to try see what partitions are on the hard drive:

Disk /dev/sdb: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x25467742

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb3   *           1           1           0    0  Empty
Partition 3 does not end on cylinder boundary.

I have attempted to use TestDisk to try to recover my lost partition but both quick and deep scans find no partitions present.

I am able to look at the used space and all of my data is still intact on the hard drive itself, it just seems my partition is complete gone. Is there any way I can recover this data? Any tools or details that I am missing?

Solution

Mount a partition, not the whole disk

Your initial command was

#mount -t ext4 /dev/sdb /world

instead of

#mount -t ext4 /dev/sdb3 /world

(notice the use of the partition name instead of the disk name: /dev/sdb3 vs /dev/sdb). I have been bitten by this before, so I thought I might point it out.

Use recovery tools

In some cases your partition, disk or partition table might be corrupted.

In an ideal world, you would create an image of that hard drive before trying any recovery tools on it.

There is a tool called "foremost" that can retrieve files of specific types. Here is a blog post that might help: Recovering data from formatted drives using foremost

If your data is of uncommon types then foremost will probably not help much.

If TestDisk can't find your partitions then I expect that GNU Parted won't either, but it might be worth a shot

Comments

[Nils]

The partiton ist still mounted... So the question is: How do you get the kernel-idea of where that partition starts and ends from?

[Gilles 'SO- stop being evil']

You're trying to mount /dev/sdb, which is the whole disk. This is unusual, and probably not what you wanted since you say there was a partition on the disk. What does </dev/sdb tail -n +513 | file - say? If it detects a filesystem, you've just hosed your partition table and should recreate a partition starting at cylinder 1.

[Admin]

@Gilles When trying to run /dev/sdb tail -n +513 | file - it gives me an /dev/stdin: no read permission error even though I am running it as root.

[Gilles 'SO- stop being evil']

@Nic Try again with the whole command line, including the initial <.

[Admin]

@Gilles same result, I am still getting a premission denied

[Gilles 'SO- stop being evil']

@Nic This is strange. What is the output of ls -l /dev/std*? What does head -c 1024 </dev/sdb | hexdump -C1 show?

[Admin]

When I attempt to mount the file with /dev/sdb3' it gives me mount: special device /dev/sdb3 does not exist. I have tried partition numbers 1-4 and get the same result. Also I am following the tut. for the GNU Parted that you linked to and I ran dd if=/dev/sdb of=/dev/sdc bs=512 conv=noerror,sync` to create a disk image of the hard drive but it is taking an unusually log time. Is this normal? How long can I expect this to take? The disk I am trying to image is 1TB.

[Paul Nijjar]

Sorry for the late reply. Yes, this can take a long time. You can issue a command to check the progress of the copy.