Sign up ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I accidently run "fsck" on a mounted partition which was my only parttion. Now I can't boot. It was Fedora 13, filesystem should be ext3.

I have booted from usb with ubuntu 11.10.I found that lost+found is empty. I can't find my files. Is there a way to recover them?

I only want to save some of my files.

share|improve this question

migrated from Jun 7 '12 at 7:44

This question came from our site for professional and enthusiast programmers.

Do you use RAID or LVM? If so you'll need to activate those before mounting the filesystem. Please update your post with the output of /sbin/fdisk -l and ls of the filesystem mounted in your live distro. Not sure if it'll make a difference but if you have or can get a Live CD of Fedora 13 (here) you at least have the same version of the tools used to create the filesystem, LVM etc. – Bram Jun 7 '12 at 7:51

1 Answer 1

Immediate actions (Do and Don't):

  • Do immediately umount /dev/sdaX partition or if it is not possible do mount -o remount,ro /dev/sdaX where /dev/sdaX is your partition device node.
  • Do NOT write anything to partition that contains files/data that you're attempting to recover.
  • Do NOT run any filesystem repair tools (fsck or like) or any utility that could modify filesystem or disk contents.
  • Do NOT attempt to mount/use that partition before your initial stage backups are ready.

Before starting recovery:

You should always make disk or partition image before attempting to recover any files from broken filesystem. When you have image file you can always rollback if something goes wrong with recovery process and situation gets worse.

Noticeable benefits

  • You could replicate your backup and run through different recovery methods at same time, effectively saving time spent at overall recovery process.
  • You could restart whole recovery process from beginning if something goes terribly wrong with recovery [recovery tools fail, further data corruption, head crash etc. renders original source inoperable, ...]
  • In given situation, it just is very bad idea to work directly on device where your most valuable data resides.

Preparing for recovery:

There are several ways and utilities that could help with image creation, one example is using linux utility called dd. This utility can copy every bit from HDD to file.

However, doing disk images this way might eat a lot of disk space, 2000GB file for 2000GB disk because dd does not look at filesystem or data stored to harddisk but instead just tries to copy every bit it can see. Using compression is must (at least for bigger disks), even if using fastest compression method it still eliminates most zeros[RLE] from file. This example copies disk /dev/sda to /mount/backups/disk1.img.bz2.

# Disk image + compression with bzip2:
dd if=/dev/sda of=/dev/stdout bs=1M | bzip2 > /mount/backups/disk1.img.bz2
# Or compression with gzip:
dd if=/dev/sda of=/dev/stdout bs=1M | gzip > /mount/backups/disk1.img.gz

If you are taking image from defective source then use ddrescue instead of dd (ddrescue is similar utility but it can retry/skip sectors in case errors).

How to recover files:

Good file recovery utilities for EXT file systems are extundelete and ext3grep.

debugfs could help but requires some undestanding of underlying filesystem, you can try if it can read your filesystem. See cat and dump provided by debugfs to view and copy files.

testdisk is another utility used to find and repair partition tables from disk.

fsck -t ext3 -f -y is also worth to try but remember that this is will write directly to source so make sure that you have backup.

photorec if all above fails try this. Photorec will try to find files by headers so it can only recover known types listed here but it probably can recover at least something because it does not need to know anything about filesystem but instead it works directly on raw data. However if files is non-contiguous it is possible that some files are not fully recovered. Another utilities with likewise functinality is Foremost and Magicr Rescue.

Few notes:

Remember that some recovery / checking utilities can also make situation worser by corrupting data, this is why you really should first create full disk backup before proceeding with recovery.

Disk image compression could be effectively done with LZ4 or DEFLATE as both have good RLE support, and of course any lossless algorithms will do (more or less effectively).

There is also a lot of other recovery utilities all over Google.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.