I am learning the value of having good backups.
I have a 500GB hard drive which is failing. I started running
ddrescue /dev/sdb1 backup.img mapfile
and it was going to take 40 to 70 DAYS, depending on which moment you looked at it.
I read this post which shows how to speed up the ddrescue with a -c 1Ki option. Now I am looking at 15 days or so.
Is there another trick I am missing? Or a better tool? Is this really what recovering a failed hard drive entails?
ddrescue has this option:
-a, --min-read-rate=<bytes>
minimum read rate of good areas in bytes/s
If you specify it on your command line with a decent size like 10M, with any luck, areas that are still able to read but extremely slow will be skipped first, and continue with other areas the drive is still able to read performantly.
Depending on how much is missing in the end, you can still follow it up with a slow pass afterwards.
It's also possible to run ddrescue in --reverse mode or force it to start at a specific offset with --input-position=X so if ddrescue doesn't skip into a faster region by itself you can force it to do that manually.
Is this really what recovering a failed hard drive feels entails?
Hard to tell since there are so many different types of failures. It also depends on the type of drive, how it handles errors, and sometimes also how the controller itself reacts to bad drives. Check dmesg for any noise, see if there are bus resets, those should not happen just because a drive encounters a read error. (If that happens, perhaps increase /sys/block/.../device/timeout)
If your drive supports SCTERC (unlikely for desktop consumer drives) you might be able to tell the drive to not even attempt internal error correction but return read errors directly.
