GNU ddrescue—A Powerful Data Recovery Tool

3 days ago, I encountered an error while moving a folder of about 3 GB from my USB stick to my hard disk using GUI. After 1.2 GB of the files are moved, the progress bar of the program just remained unchanged. I left the seat in front of my computer and did something else. Returning to the seat after half an hour, the situation had NOT been better. The displayed remaining time was still "unknown".
The I clicked the cancel button to stop the process, but it simply hangs. After terminating the process from the "System Monitor" (another GUI program), the read/write speed of the USB stick became extremely low. Instead of blinking frequently, the light bulb inside the USB stick went on and off slowing during a read/write operation.
In /var/log/syslog.1, it says

[  627.152020] usb 2-1: reset high-speed USB device number 4 using ehci_hcd
[  658.128020] usb 2-1: reset high-speed USB device number 4 using ehci_hcd
[  658.493165] sd 3:0:0:0: [sdf] Unhandled error code
[  658.493169] sd 3:0:0:0: [sdf]  Result: hostbyte=DID_ABORT driverbyte=DRIVER_OK
[  658.493174] sd 3:0:0:0: [sdf] CDB: Write(10): 2a 00 00 54 e9 30 00 00 01 00
[  658.493188] end_request: I/O error, dev sdf, sector 5564720
[  658.494531] quiet_error: 39 callbacks suppressed
[  658.494533] Buffer I/O error on device sdf1, logical block 5564658
[  658.495808] lost page write due to I/O error on sdf1

Oh! I need to recover the data! And I've found GNU ddrescue an excellent tool for the task. No expensive recovery plans are needed. Just ddrescue on a bootable media and some free space in a storage device will do.
It's important to note that the data recovery program should never be run on the damaged device. Otherwise, further damage will be done to the damaged device. [1] In addition, I don't recommend running the data rescue tool on the operating system(s) installed on your hard disk. The process takes a long time, so "patience is key". [1]
Booted into the command line interface (CLI) of Ubuntu Rescue Remix 12.04, I first formatted the D drive into an empty NTFS partition after backing up the data on that device. (i.e. /dev/sda5)
After that , I ran the following command: [1]

$ ddrescue -r1 -n -S -v /dev/sdxm /dev/sdyn [logfile]
# Substitute x with the appropriate partition letter of the source partition
# Substitute y with the appropriate partition letter of the destination partition
# Substitute m with the appropriate partition number of the source partition
# Substitute n with the appropriate partition number of the destination partition

The process is irreverisible so do it carefully.
In the screenshot below, x=f, y=a, m=1, n=5, and logfile=`backup1.log' .
But the program refused to work, so I have to --force it to work.

Captured using screendump.

The program read the blocks fast initially but it gradually slowed down. After running the command for over 20 hours, over 3700 MB of the data had been read. Although there's just about 400 MB to go, according to the average speed at that moment, it was an hour to recover 10 MB of the data. What's worse, the average speed was getting slower and slower! (Later, from GeekyProjects, I realised that the heat of the devices inhibits the process [2], and the logfile file feature enables users to pause the job. [3]) Therefore, always use a logfile. [4]
Without adequate knowledge on GNU ddrescue, I stopped the task with <C-c>, but it took the computer several minutes to receive this input. But what's next for an incomplete task? The files don't occupy the whole USB stick. It might took me another day if I waited for some while and then resumed the task. At that moment, I decided to try mounting the destination partition /dev/sdyn. Thinking that the destination was a NTFS partition from the partition table rendered by fdisk -l, I tried mount -t ntfs /dev/sdyn, but the computer wouldn't let me go. I was fortunate to be stopped by this error. Otherwise, I think I would do another harm to the file system. This time, I let mount to automatically decide the partition type by removing the -t flag. It worked! I could browse and open the file there. After that, I copied the files to a safe place (i.e. a normal data storage device) Finally, I've found that most of the files were salvaged, despite some corruption of the multi-media files.
Since then, I've really learnt a lesson: NOT to use GUI for copying big files, always use commands. Secondly, never use mv for big files, use cp instead.

Reference:
[1]: http://techmuck.blogspot.hk/2012/03/data-recovery-with-gnu-ddrescue.html
[2]: http://geekyprojects.com/storage/how-to-recover-data-even-when-hard-drive-is-damaged/
[3]: https://www.gnu.org/software/ddrescue/ddrescue.html
[4]: http://manpages.ubuntu.com/manpages/raring/man1/ddrescue.1.html