To check a disk or partition for errors, use the Linux command fsck (and its file system specific derivates).

1. unmount the partition to check (if it was mounted before)
   # umount /path/to/mountdirectory
2. check the partition
   # fsck /dev/<partition-name>
   e.g. <partition-name> is hda1
3. for a file-system specific check (i.e. include checking for bad blocks) use
   # <filesystem>fsck /dev/<partition-name>
   where <filesystem> can be one of the following: dos (for FAT/FAT32/VFAT), reiser (for ReiserFS), e2 (for ext2/3), e.g. # dosfsck /dev/hda1
   alternatively, you can use
   # fsck.<filesystem> /dev/<partition-name>
   where <filesystem> can be: vfat, reiser, ext2, ext3, e.g. # fsck.vfat /dev/hda1
   

The following procedure has been tried with a damaged FAT32 partition. It should work for ext2/3 and ReiserFS partitions as well. Success for NTFS partitions depends on the availability of NTFS drivers.

You recover data by making a bit-per-bit copy of the disk that contains the precious data onto an error-free disk. This means you need a second hard disk drive that is as least as big as your original disk. This bit-by-bit copying process is time consuming. In the end you have a disk image which you can manipulate, repair inconsistencies and restore and backup data. We will need three partitions: the source partition (/dev/hda1), a working partition (/dev/sda1) and a target partition (/dev/sdb6) where we manipulate or read the data we want to recover.

In the following we assume that your partition to recover is /dev/hda1, and that you have a free and error-free disk at your disposal, and that you've booted your machine with a Live Linux CD (I used Knoppix).

1. Create a new ext3 partition that is at least as big (preferably slightly larger) than the disk to be recovered. I used GParted from a Knoppix CD. The newly created partition got device name /dev/sda1 (it was an external USB drive)
2. Mount the new partition and make it accessible:
   gain root privileges
   # su
   create a new mount directory
   # mkdir /media/sda1
   and mount the partition
   # mount -t auto /dev/sda1 /media/sda1
   change to the partition
   # cd /media/sda1
   and give full access privileges
   # chmod 777 *
3. The disk bit-per-bit copy is performed by the tool dd. This tool by itself has no error recovery and will try to copy erroneous bits. This is good as long as this attempt succeeds. But it fails if the bit is physically damaged on your disk. Therefore, two scripts have been developed: the dd front-end dd_rescue and the dd_rescue front-end dd_rhelp. I suggest to use dd_rhelp as it gives you some text-rendered graphical output on the progress and has a strategy that tries to read large chunks of undamaged data first before reading the damaged parts completely. You can get dd_rhelp from http://www.kalysto.org/utilities/dd_rhelp/index.en.html .
4. download dd_rhelp-0.1.2.tar.gz (or any other feasible file) to /media/sda1 and unpack it
   # tar xzf dd_rhelp-0.1.2.tar.gz
   that gives you the directory /media/sda1/dd_rhelp-0.1.2/
5. run dd_rhelp to copy /dev/hda1 to a file in /media/sda1/
   # /media/sda1/dd_rhelp-0.1.2/dd_rhelp /dev/sda1 /media/sda1/hda1_backup.img
   This will produce disk input/output error messages because your disk; this is natural because you are trying to rescue data from a damaged disk.
   
6. This process makes a bit-per-bit copy of the entire disk and writes it to the image sda1_backup.img. Any bit that cannot be read by the program will be zero. This takes a while. Quite a while. For my 40GB about a week. You may kill the dd_rhelp and the dd_rescue processes at any time and continue later on. dd_rhelp writes a log file that keeps track of the overall progress that has been made.
   Get the list of all running processes
   # ps -a
   Find dd_rhelp (assume process id 11) and dd_rescue (assume process id 22) and kill both processes
   # kill -9 11 22
   Interrupting and restarting dd_rhelp may help speeding up the process to some degree. After a restart, dd_rhelp might try a different part of the disk. The dd_rhelp logic makes sure that it covers large chunks of readable data first and tries the difficult parts in the end. Thus if the dd_rhelp gets stuck in a part with lots or input/output errors, a kill will get it out of this part of the disk and a restart with make it start on a different part of the disk. In the end, there are only difficult parts left. You may decide whether you let dd_rhelp do its job until the end or stop and see what has been rescued already.
7. It is possible to tune dd_rhelp and disk access. Two things I did before starting dd_rhelp at all:
   Set disk access for /dev/hda1 to safe but slow:
   # hdparm -m 0 -d 0 -p 0 -A 0 -X 08 /dev/hda
   and modify in the dd_rhelp script the block size dd_rhelp tries to read, edit /media/sda1/dd_rhelp-0.1.2/dd_rhelp and set
   max_bs=1024
   min_bs=64
   or whatever works for you best
8. Once your are done, you have a full (up to unreadable bits) copy of the original partition in the file /media/sda1/hda1_backup.img. Do not manipulate this image! You could destroy a week of copying with a single command! Either make a copy of it and manipulate the copy or copy all data from the image into another partition and manipulate this target partition. We do the latter.
   
9. Create a new FAT32 partition on a new hard-disk that is at least as big as your image file (e.g. using GParted); or more generally, create a parition of type X if your original partition had type X; assume that this new partition is /dev/sdb6
   
10. Copy the (maybe manipulated and restored) image file into that partition:
    # dd if=/media/sda1/sda1_backup.img of=/dev/sdb6
    This goes a lot faster. Once you are done, mount /dev/sdb6 and access your files (or what could be rescued of them). You may also run data/file-system recovery tools on this partition, if you feel like doing so. The success depends on the data that could be copied from your original disk.