Shortly after my last post, my aging Dell Studio laptop learned the hard way that gravity can sometimes be a cruel and heartless mistress. I learned a couple of lessons too. Notably that 1) Dell Studio laptops do not bounce and 2) hardwood floors are called that for a reason. After recovering the pieces (well most of them), sadly the computer would no longer boot, and the screen was beyond repair.

I got myself set up again with a nice, Ubuntu-happy laptop, which I’ll tell you about in another post. I removed the hard drive from the old Dell and put it in a 2.5″ external USB enclosure to try to try and mount my /home partition for data recovery, which is when I got the dreaded “Bad superblock on /dev/sdb3″ error.

Interestingly fsck is happy to tell you that you have a bad superblock, but it doesn’t tell you either what a superblock is, or how to fix the problem. So, first things first, the superblock is a record of the filesystem details, such as its size, block size, the used and unused blocks, the size and location of the inode tables, and so on. Any time you access a file, the superblock is read.

So, how can you recover a bad superblock? Fortunately for us, backup copies of the superblock are kept at certain offsets on the disk. To find out where the superblock backups are, open a terminal window and type:

sudo mke2fs -n /dev/????

Where ???? is the partition you want to check, which in my case was sdb3. This produces output, like the following:

Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424, 20480000, 23887872


These are block numbers, signifying the location of the superblock backups.

To replace the superblock with one from a backup, type the following:

sudo e2fsck -y -b block_location /dev/????

Replace block_location with one of the above numbers and, again, ???? is the partition, so in my case it was sdb3.

There was significant corruption on my hard drive, but supplying the -y switch stopped fsck asking for confirmation every time it encountered a bad block.

After running this, I was able to mount the partition and recover my data.