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