Data recovery from corrupted ext2/ext3 filesystem having bad superblock

Posted On // 1 comment

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!!!


  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.



    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
  3. 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.


  4. 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 smile_regular; 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 datasmile_sad

  5. 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,
    20480000, 23887872


  6. 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!smile_teeth )

    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)
  7. 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.

Derived from my original article publish in My TechBlog

1 comment:

  1. hello animesh,

    i just stumbled over your blog entry while once more trying to rescue a large ext4 data partition and found your descriptions very helpful.
    sadfully the data seems not recoverable although the harddrive seems intact (i've run multiple checks, also the manufacturers lowlevel tool) but i will keep your instructions for future use.

    in my case all backup superblocks were not useable so i tried the 'mkfs.ext4 -S /dev/...' solution and tried various approaches with fsck.ext4 (while always restoring the backup after each failed try... quite time consuming on a 900GB partition). the more aggressive ones lead to a strange behaviour where weird offsets occurred:
    Free blocks count wrong for group #0 (31581, counted=31580).
    Fix? yes

    Free blocks count wrong (235869153, counted=235869152).
    Fix? yes

    Free inodes count wrong for group #0 (127, counted=126).
    Fix? yes

    Directories count wrong for group #0 (1, counted=2).
    Fix? yes

    Free inodes count wrong (921727, counted=921726).
    Fix? yes

    in the end all i got was an empty filesystem with only the lost+found folder on it. the lost data would have been nice to get back but are not worth the many dollars needed to spend on data recovery experts.

    i've also tried to get help from people over at ubuntuforums and described my efforts with testdisk, a quite helpful tool in case your partitions are screwed.
    for details check this thread: