Reading bad blocks from hard disk too slow in Linux

Question

I'm trying to recover data from an old 320G hard drive (full of bad sectors) to a new one. I found that ddrescue is a good tool for this task due to it's smart algorithm. I have already done this once with following command:

ddrescue -f -n /dev/sda /dev/sdb log

It was completed in several hours with errsize 16G (unrecovered) wich still may contain important data, so I ran next pass:

ddrescue -f -d /dev/sda /dev/sdb log

but it runs too slow (avg 300B/s) because linux getting stuck on each bad sector.
It's actually linux kernel (probably libata), not a hard disk itself, because I tried to recover in DMDE tool running on clean DOS and there was no such problem: ATA timeout can be tuned there and overall recovery process runs MUCH faster.
But not in Linux.
I also tried these kernel parameters: libata.ignore_hpa=1 libata.noacpi libata.force=noncq,norst and also libata.dma=0 passing to cmdline at bootlader, but it had no effect (im using System Rescue CD where LIBATA compiled in kernel).
Also tried to change device timeout:

echo 1 > /sys/block/sda/device/timeout

(default is 30)
but it's only generates more errors flood in syslog and don't help.
Passing bad blocks still takes 1-3 minutes for each sector wich is incredebly slow. How much time it need for parsing 16GBs of "bad" chunks? A week? Month?
I still prefer ddrescue for recovery (due to its efficient algorithm and logfile functionality) and want to know how to tune kernel driver to speedup ata/disk error handling. Google and related questions here on SU did'nt help. Any ideas?

P.S. sorry for my english

@ta.speot.is

Why don't you just restore from your regular backups?

This hard disk of my friend, not mine. So sad, he have no backups. Now, after disk crash, he starting think about making backups, yes :)

---

UPD: 2.5 years later I still don't know the answer, but just realized that ddrescue works faster when sata controller is in Compatibility (IDE) mode, another tip is always use -d option (direct access) to speed up things slightly. Also take a look at hdparm options to tune HDD (-m, -D, -P), it could help (on old hardware).

---

UPD2: Just noticed the Slizzered's answer to related question. It's great! I tried:

smartctl -l scterc,20,20 /dev/sda

and recovery went much faster than before (only in IDE mode though).

Answer 1

This is a few years after the question was posted but it will help someone else. I saw the major part of this answer somewhere else and I'm not sure if the -c option was available in older ddrescue. -c changes the amount of sectors to copy at a time.

here goes:

ddrescue -d -r0 -e +0 -T 1s -n /dev/sdX recover.img recover.log -c 1 -O

replace X with the drive you are trying to recover. Data will be stored in a file called recover.img so you'll need enough space.

Use the 'watch' program in front of the above code to run the code automatically when it crashes due to 'too many bad areas' error.

Answer 2

From the DDRescue man:

(the user may interrupt the process at any point, but be aware that a bad drive can block ddrescue for a long time until the kernel gives up)

So the short answer is: with DDRescue you can't because you can't change the Kernel timeout (you need to edit the right source in the right place and recompile... not simple!).

I had good results using some software contained in Hiren's boot:

• DataResque DD (make an image)
• Roadkil's Unstoppable Copier (copies the files and logs errors)

Both run in the MiniXP also contained in Hiren's boot. It run from CD/DVD or USB drive.

Advice: harddisks can run very hot, this is bad and worse the process. Cool down with a fan, this prolongs their life and can make faster the work.

Answer 3

It may be helpful to configure the --skip-size= parameter to something larger. It defaults to something tiny like 64 kB, whereas the damage stripes in a modern drive might be much larger.

Although you will still have to wait for the timeout each time, there will be fewer of them to wait-out.