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