Recover from accidental mkfs using fsck

Recently I accidentally ran mkfs.ext3 on the wrong RAID1 array.

As soon as I realized what had happened, I shut power off from the PC.

Booting to a live CD, I ran

mdadm –assemble /dev/md0 /dev/sda1 /dev/sdb1

fsck -y /dev/md0

I was able to then mount the drive

mkdir /media/md0

mount /dev/md0 /media/md0

ls /media/md0/lost+found

And the majority of my files were saved.

Check to see if your filesystem is ext2 or ext3

mount | grep md0

If it’s ext2, convert it to ext3

umount /media/md0

tune2fs -j /dev/md0

WARNING: If you choose to run fsck manually (without -y), choosing “n” to Clear? and “y” to Fix? will cause you to lose that file.

5 Responses to “Recover from accidental mkfs using fsck”

  1. pavlix says:

    hello, I wonder why should ever fsck recover a lost filesystem when you run it on a perfectly clean newly made ext3 filesystem (with mkfs).

    more I wonder why should the manual way break the file(s) even if you choose to fix them, as opposed to the automatic way (this is what your article says).

  2. termina says:

    pavlix,

    I think my first sentence there explained why someone would want to recover a lost filesystem after making a new one (ie, an accident…).

    If you’re asking why I included the “Warning”, it’s because fsck does not clearly explain what the default behavior will be so I’m making sure people will not choose the option that would lose their data.

    This article is only useful for those that have made a mistake and would like to recover data. 😛

  3. pavlix says:

    hello,

    I understood both your first sentence and the usefulness of recovering after mkfs. That’s exactly why I found your post.

    I’ll try to reword at least the first question. The more important one:

    I know fsck is a set of repair tools for various filesystems. Let’s stick to ext3. Let’s say I have a working clean filesystem. Then I accidentally call mkfs. And now I call fsck because I want to revert my mistake.

    What fsck sees is a valid (though empty) filesystem. According to the documentation, one would expect fsck to confirm that the filesystem is clean and needs no repair (mkfs creates a correct empty filesystem, doesn’t it?)

    My question is (and was), how does fsck know it should throw away the new clean filesystem and try to recover the old one instead.

  4. termina says:

    Yeah, I didn’t get that from your first post. Thanks for clarifying. 🙂

    It sounds like you let mkfs complete? If you had interrupted it you’d probably have been better off. 🙁

    My understanding is that the data is left alone but that the journal and superblocks are overwritten after calling mkfs.

    If any of the superblocks from the previous filesystem existed you could use

    fsck.ext3 -b superblock-number /dev/sda1

    And that would let you recover your previous filesystem.

    So to answer your question, fsck checks the journal and superblocks to determine if a filesystem is clean and determines which files you see in your filesystem.

  5. pavlix says:

    Ah, then it means it tries to recover an incomplete mkfs.

    A complete mkfs leaves no chance except block-level tools (as far as I understand other sources, even the inode table is zeroed).

Leave a Reply to termina Cancel reply

Your email address will not be published. Required fields are marked *

Time limit is exhausted. Please reload CAPTCHA.