NOTE : I do not take any responsibilty of any damage to your disk or data while trying my method or any of my commands stated in this article. YOU HAVE BEEN WARNED!!!
- 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.
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.
- 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
mount -t ext2 -o ro,errors=recover,
errors=<span class="kwrd">continue</span> /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 file system.
- Before you proceed further, I'd recommend taking an image, by executing :
dd <span class="kwrd">if</span>=/dev/sdb3 of=/sdb3-backup/image/backup
and then using the loop device to work on that. If the partition is bigger than 2 gig you will probably need to compress it alternatively by executing
dd <span class="kwrd">if</span>=/dev/sdb3 | gzip > /sdb3-backup/image/backup.gz
Note: If compressing the loop device doesn't work and you have to work on the bare hardware and using an alternate superblock failed too, a last dirty fix could be
mke2fs -S /sdb3-backup/image/backup
Or if the dd result is too big use
mke2fs -S /dev/sdb3
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 another HDD to save the data, I’m would be happy ; to do
dd <span class="kwrd">if</span>=/dev/hda2 of=/dev/xyz
e2fsck -b 32768 /dev/xyz
e2fsck restored the first superblock and my problems are gone...but unfortunately I do not have another HDD which can hold this big chunk of data
- 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: LinuxBlock size=4096 (log=2)
Fragment size=4096 (log=2)14385152 inodes, 28754341
blocks1437717 blocks (5.00%) reserved <span class="kwrd">for</span> the
super userFirst data block=0878 block groups32768
blocks per group, 32768 fragments per group16384
inodes per groupSuperblock backups stored on
blocks:32768, 98304, 163840, 229376, 294912, 819200,
884736, 1605632, 2654208,4096000, 7962624, 11239424,
- 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. BINGO! )
Use the formula below to calculate the backup superblock location :
Superblock backups stored on blocks location
* Block size <span class="kwrd">in</span> K(i.e.Block size/1024) =
Nmount -t ext2 -o sb=N /dev/sdb3 /mnt/sdb3
(replace N with the result of the calculation)
- If you successfully able to mount the partition, go to the mounted partion and copy data using
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.
Derived from my original article publish in My TechBlog