Data recovery technique from corrupted ext2/ext3 filesystem having bad superblock

NOTE : I do not take any responsibilty of any damage to your disk or data while trying my technique or any of my commands stated in this article. YOU HAVE BEEN WARNED!!!

1. Let's say our corrupted filesystem is at partition /dev/sdb3 of ext3 type. We will mount the partition under /mnt/sdb3, so create the directory structure if you dont have it already.

Also, create the following directory structure to keep backup data.

mkdir /sdb3-backup
mkdir /sdb3-backup/image
mkdir /sdb3-backup/copy

Note that ext3 filesystem is same as ext2, with only addition of journal. So our entire technique will use ext2 filesystem if even our corrupted filesystem is ext3 type. Because our aim is to recover data not journal recovery (which is unrecoverable as far as I know). So be carefull while you issue any of my commands, unless explicitly told dont add any ext3 filesystem type in any of our command. Use all my command as it is written below.

2. Before applying this technique be sure that your superblock is corrupt only not the entire disk or something else.

USE THE INSTRUCTION BELOW TO CHECK IT

A. Try to mount the disk read only using

mount -t ext2 /dev/sdb3 /mnt/sdb3 -o ro

OR

mount -t ext2 -o ro,errors=recover,errors=continue /dev/sdb3 /mnt/sdb3

Check the message you are getting. it must be something like below :

mount: wrong fs type, bad option, bad superblock on /dev/sdb3,
or too many mounted file systems

B. Now try "dmesg | more" to actually verify if the superblock is really damaged. We will see a line like below :

EXT2-fs: unable to read superblock

Now we will first start to recover the data by mounting it then we will try to correct the filesystem.

3. Before doing that I'd recommend taking an image, something like

dd if=/dev/sdb3 of=/sdb3-backup/image/backup

and then using the loop device to work on that. If the partition's bigger than 2 gig you will probably need to compress it first with something like

dd if=/dev/sdb3 | gzip > /sdb3-backup/image/backup.gz

(note that if it's compressed the loop device won't work and you'll have to work on the bare hardware). If using an alternate superblock doesn't work a last ditch fix may be

mke2fs -S /sdb3-backup/image/backup (or mke2fs -S /dev/sdb3 if the dd result was too big).

This will rewrite the superblocks, you will then need to run e2fsck to clean up. This did the
trick for me on a drive that got a whole bunch of bad sectors that I had to get data off.

Hmm, if I'd only have a HDD to save the data, I would be happy :) ; then I could probably do

dd if=/dev/hda2 of=/dev/xyz
and
e2fsck -b 32768 /dev/xyz

e2fsck would restore the first superblock and my problems were gone...but I have no second hard disk which is that big :(.

4. Linux file system writes backup of superblock in different locations. Find the backup superblocks using

mke2fs -n /dev/sdb3

The above command will give you a result like below

mke2fs 1.35 (28-Feb-2004)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
14385152 inodes, 28754341 blocks
1437717 blocks (5.00%) reserved for the super user
First data block=0
878 block groups
32768 blocks per group, 32768 fragments per group
16384 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424, 20480000, 23887872

4. Now please note the superblock backup blocks number at the last line and the block size(which is multiple of 1K=1024b). In our case the block size is 4096 that mean 4K (4096/1024=4)

While the block number which must be given to mount is based on the blocksize which is installed on the hard disk (4k in my case), the block number which must be given to mount is calculated on a 1k-block-basis, so I had to multiply 32768*4.

Now we will try to mount the corrupted filesystem partition. We have to tell mount command to use backup superblocks so we will calculate the first backup superblock (if it is OK) 32768*4 = 131072. Now mount with the command below :

mount -t ext2 -o sb=131072 /dev/sdb3 /mnt/sdb3

Now imagine the backup at position 32768 was damaged too . . . then you just try again with the backup stored at position 98304, and 163840, and 229376 etc. etc. until you find an undamaged backup ( there are several backups so if at least one of those five is okay it´s bingo ! )

Use the formula below to calculate the backup superblock location :

Superblock backups stored on blocks location * Block size in K(i.e.Block size/1024) = N
mount -t ext2 -o sb=N /dev/sdb3 /mnt/sdb3
(replace N with the result of the calculation)

5. If you successfully able to mount the partition, go to the mounted partion and copy data using

cd /mnt/sdb3
cp -R /mnt/sdb3/data /sdb3-backup/copy/.

If any of the above steps fails. You need to consult a experienced data recovery experts.

In 90% case of damaged superblock this technique of data recovery works. Hope the above technique will help you too. Please post your result if you use the technique in this article.

And at last I would like to say "ALWAYS BACKUP YOUR DATA IN MULTIPLE / DISK OR MEDIA" so
if one fails you can restore from others.

Please post your comments, to let others know about the technique failure and success rate.
If you have any other sucessfull method to recover data, please post it.

Acknowledgement :
http://www.linuxforums.org/forum/misc/35926-cannot-boot-up-linux-unable-read-superblock.html
http://www.ussg.iu.edu/hypermail/linux/kernel/0104.2/1353.html
http://www.brunolinux.com/04-The_File_System/Damaged_Superblock.html
http://lists.debian.org/debian-user/2001/09/msg01200.html