1. This table assumes that you (know you) have a faulty disk or filesystem. It does not cover things like bad cables, bad controllers, bad motherboards, bad CPU's, bad memory or bad termination, all of which can seem to be bad disks or filesystems at times. If you suspect you may have a bad disk, but aren't sure yet, then if you can see some important data right now that you cannot afford to lose, it's a good idea to use one or more of the "1) make a best copy of what you have" methods below, then check related hardware other than your disk, then resume with one or more of the "2) repair what you have" or "3) hunt for lost data?" methods, because a bad disk can get a lot worse fast sometimes.
2. If you don't have backups, ask yourself "why not?" You're probably too busy right now dealing with the lost/missing data, but put a time to look into backups on your calendar, right now
3. Methods that use the POSIX file API will generally have one class of failure modes, and methods that go to the device file will generally have another class of failure modes, so it can be a good thing to try at least one of each if you want to make a copy (assuming the first you try doesn't work).
4. Methods that try to undelete or search for bit patterns through the device file will tend to have decaying usefulness. That is, every second that elapses from the time the file is deleted or otherwise lost, until you start hunting for the file, is a second that increases the probability that you won't be able to get the file back. To make matters worse, some *ix filesystems will intentionally reuse recently-released blocks, in an effort to reduce disk head motion and consequently increase performance, which means your file's blocks may be allocated to new files before other blocks that have been free for ages. You can reduce the pain of this situation a bit by making the first thing you do, creating an image backup onto another disk, to a file on another filesystem, or to a disk on another host. The best way to do your image backup is the fastest way - usually that means to a file on another filesystem on the same host. If you do choose to do an image backup, you may want to see copying lots of data. If you don't have enough room for an image backup, consider compressing it, especially if the filesystem isn't 100% full (and hasn't been since the last mkfs/newfs/whatever).

Tool/approach	May cause things to get worse?	May cost money, not just time?	Goes through the POSIX file access API, or to the device file?	Will attempt to: 1) make a "best copy", 2) repair what you have or 3) hunt for lost data?	Will only copy data that appears to still need to be copied, if you run it more than once?	Number of files this operation handles	For more information
e2retrieve	no	no	device file	1) make a best copy	no (?)	Whatever files are available in the device file used - it's assumed you'll be doing this with a severely damaged ext2 (and 3?) filesystem, due to for example, having lost too many disks in a RAID volume or similar	official site: guzu.net
dd conv=noerror	Only if not used as intended	no	device file	1) make a best copy	No	The whole filesystem
dd_rescue	Only if not used as intended	no	device file	1) make a best copy	Yes	The whole filesystem	official site: garloff.de
GNU ddrescue	Only if not used as intended	no	device file	1) make a best copy	Yes	The whole filesystem	official site: GNU ddrescue. Some prefer GNU ddrescue to dd_rescue, but dd_rhelp is supposed to add some ddrescue-like functionality to dd_rescue.
fsck, including fsck with an alternate superblock	Yes, once in a while it will, even when used as intended	no	device file	2) attempt to repair what you have	Does not copy	The whole filesystem
data recovery service	Very unlikely, unless perhaps your disk gets lost in the mail or is "shipped incautiously" - IE, gets damaged in transit	Yes, it could. If they can recover your data automatically, they probably won't charge you that much. If they have to get someone to reassemble your filesystem by hand, they may charge you a lot	device file	Up to them	Up to them	Anywhere from one file to the whole filesystem	Some data recovery services
tar/cpio/afio/pax/etc.	Very unlikely	no	POSIX file API	1) make a best copy	No	Anywhere from one file to the whole filesystem
rsync	Very unlikely	no	POSIX file API	1) make a best copy	Yes, but only already-copied data is skipped, not troublesome data	Anywhere from one file to the whole filesystem	official site: samba.anu.edu.au
dump/ufsdump with restore/ufsrestore	Very unlikely	no	device file	1) make a best copy	No	Anywhere from one directory to the whole filesystem
find | xargs grep	Very unlikely	no	POSIX file API	3) hunt for lost data	Doesn't copy at all	As many files as you provide search patterns for	As pertains to e-mail, and more generally
undeletion program	Not highly likely, but these programs can generally be thought of as somewhat risky	no	device file	2) attempt to repair what you have	Doesn't copy except in rare cases	Anywhere from one file to the whole filesystem	Undelete programs
searching through the device file	Very unlikely	no	device file	3) hunt for lost data	Doesn't copy so much as search, but to the extent that it does copy, it does not avoid recopying already-copied data	As many files as you provide search patterns for	Using ext3 with LVM2 as an example, including what to do if GNU egrep runs out of memory and how to do it without a volume manager involved
writing to the/a bad block	Yes, this could be dangerous, especially if you write the wrong block	no	device file	2) attempt to repair what you have	Doesn't copy	Operates on a single block. If that block is part of a file, then just that file. If that block is part of some metadata, then it may relate to many files
mapping away the/a bad block, EG with Sun's "format" program in "Analyze" mode	Yes, it could	no	device file	2) attempt to repair what you have	Doesn't copy	Operates on a single block. If that block is part of a file, then just that file. If that block is part of some metadata, then it may relate to many files
Create a filelist, and back it up, removing backed up files and problematic files from the list as you go	Very unlikely	no	POSIX file API	1) make a best copy	Yes, both already-copied data and troublesome data can be skipped, but it can be tedious managing the list of files	Anywhere from one file to the whole filesystem
try-copying-up-to-n-times	Very unlikely	no	POSIX file API	1) make a best copy	Yes, both already-copied data, and troublesome files are skipped. Does the work of managing a list of files yet to copy for you, stored in a variety of database backends	Anywhere from one file to the whole filesystem	official site: dcs.nac.uci.edu

Sounds like physical trouble, but/so you might try, in no particular order:

1) Pop the disk into a freezer bag, and pop the bag into a freezer for a while. This may change the distances between the blocks and tracks in a way that allows you to get your data back

2) Fiddle with hdparm, focusing on reducing what the OS requires of the disk

3) Pull out the disk, hold it between your hands, and make a quick rotating motions. Sometimes this'll knock loose some gummed up lubricant inside the disk

4) Check the temperature at the time the disk has trouble

5) Hook the disk up to another system and/or another power supply, and see if that helps any

6) Try ddrescue and/or dd_rescue, to see if they can get some of your data back

7) Use SMART on the drive, to see if SMART tells you anything about what went wrong

8) See if you can get ahold of another identical drive, with a serial number very close to yours - remove the servo from the good one, and try installing it on the bad one. Note, however, that this can really toast your data if you get an incompatible servo.

9) You might try a disk recovery shop

You can e-mail the author with questions or comments: