Data-Recovery – Faster Disk Recovery with ddrescue Running Slow

I don't know if you are still trying to extract data off that hard drive or if you were successful already, but in case if you were not successful and would like to give it a try to see if you can recover, perhaps, lost Bitcoins or whatever, I have made a few modifications to your ddrescue command line parameters, I have added the following:

$ sudo ddrescue -d /dev/sdb /home/dave/RECOVERY/usb500.image \
     /home/dave/recovery_usb500.logfile --force -R

• -d which tells ddrescue to use direct disk access,
• --force which tells ddrescue to forcefully use and read/write to your logfile in case if it complains that it can't use it for read/write purposes
• -R (yes, with CAPITAL R) which tells ddrescue to perform the recovery operations in reverse instead of reading off the failed hard drive in forward mode. Sometimes reading in reverse helps when the damage is substantial as this bypasses the hard drive's cache in case if there are problems there.

Currently I am using these commands (except I am not using the 3 command as I don't want [YET] ddrescue to retry bad sectors, I will leave that for last, after my first sweep is done, and I am having a great success rescuing data off my 1TB Seagate failed hard drive where I ASSUME might be holding a few bitcoins I may have been mining back in 2009 to 2010, probably I found 1 to 3 blocks of 50 BTC each, I hope it's on this hard drive, well, it will take me a total of over 15 days to complete the operation at a read rate of 634 kbps average.

Also, I would like to add that you may and most likely, based on your previous track record of over 9 DAYS of "last read activity" that you will encounter a situation where the hard drive will just refuse to read any further, in that situation, just press the CTRL + C to cancel since you are using a log file, remove the SATA cable off the failed hard drive, but not the USB controller off the USB port (yes, use a USB SATA controller instead of connecting it to a motherboard so it would not lock out your whole computer forcing you a hard reboot, and then plug in the SATA power back on to restart the hard drive, give it like 10 seconds and then press the up or down arrow to reload your previous terminal command and restart the ddrescue operation, thanks to your previous log it shall continue where it last left off and there will be reading being done and the "last successful read" shall always stay at "0s" (zero seconds) where it should, indicating that ddrescue is being successful in reading from the hard drive, and if you ever notice that the "last read from" starts counting seconds, just terminate once again ddrescue with CTRL+C, power cycle the hard drive, and restart ddrescue, there is no point in waiting to see if the "last read from" restarts back to 0s on its own, based on my experience it's never going to happen, you will be waiting for eternity. I had to power cycle my bad 1 TB hard drive about 20 times in total, it's been like 7 days and I am very close to reaching the 500GB recovered mark, half way to go still, hope I won't encounter any major failures as I near 100% as it has been going flawlessly for the past 3 days, again at over 634 kbps.

Also, don't get greedy at trying to get a faster data throughput read rate, as my attempt at trying many parameters and different block sizes almost left me with a completely dead hard rive that will stop working in over 1 second after power cycling it (that was 5 days ago) but thankfully it just started once again showing sign of life, initially reading at 2,000 bs (yes BYTES per second) a little less than 2kbps, I was very disappointed, but after canceling ddrescue with CTRL + C and just restarting it once again (in reverse with the -R) parameter added, then speed went back to 630, before I was reading forward at 930 kbps, at least I am content that I am doing 630 kbps in reverse and not having to put off with 2kbps, so if you get a success at any read speed, like in the 500 kbps range stick with it and don't try anything to push speeds any higher, it may be your last successful attempt at gaining any read speed.

Alternatively, if ddrescue is of no good for you because you can't get anything read regardless of what parameters you try, you may want to consider replacing the logic board off the hard drive, as 90% of the time it's the logic board that goes bad, but first, take off the logic board and clean all the contacts that makes contacts with the hard drive's pins, some times these contacts gets a blackish gooey mixture in it, severing contact which could be the source of your failure. But be aware that if you have to replace your hard drive's logic board, you will have to get one of the same brand, serial number (close to), model number, revision number because it has to be as close to as the original for the donor board to work.

Even though the question was asked 10 months ago, the answer might be relevant because the recovery cycle might still be running depending on a few factors! No pun intended.

The reason is that, time estimate is almost impossible, however sometimes you could get a rough idea as follows. One of the most obvious reasons is that you can't predict how long it will take the drive to read a bad sector and if you want ddrescue to read and retry every single one, then it could take a very long time. For example, I'm currently running a recovery on a small 500GB drive that's been going on for over 2 weeks and I possibly have a few days left. But mine is a more complicated situation because the drive is encrypted and to read anything successfully, I have make sure to get all sectors that have partition tables, boot sectors and other important parts of the disk. I'm using techniques in addition to ddrescue to improve my chances for all the bad sectors. IOW, your unique situation is important in determining time to completion.

By estimate of "loops", if you mean number of retries then that's something you determine by the parameters you use. If you mean "total number of passes", that's easily determined by reading about the algorithm here.. >man ddrescue< / Algorithm: How ddrescue recovers the data

I'll specifically speak to the numbers in the screen captures you provided. Other situations may have other factors that apply, so take this information as a general guideline.

In the sample you've provided take a look at ddrescue's running status screen. We get the total "estimate" of the problem (rescue domain) by "errsize". This is the amount of data that is "yet to be read". In the sample it is 345GB. Next line below to the right is "average rate". In the sample it is 583kb/s

If the "average rate" was to remain close to steady, this means you have 7 more days to go. 345 GB / (583 kb * 60*60*24) = 7.18 However the problem is that you can't rely on the 583kb/s. In fact deeper you go into recovery, the drive gets slower since it's reading more and more tougher areas and is doing more retries. So the time to finish exponentially increases. All of this depends on how badly the drive is damaged.

The sample you've provided shows a "successful read" was over 10 hours ago. That's saying that it's not really getting anything from the drive for 10+ hours. This shows that your drive may have 345GB worth (or a portion) of data shot. This is very bad news for you.

In contrast, my second 500GB drive that had just started giving me "S.M.A.R.T" errors, was copied disk to disk (with log file on another drive) and the whole operation took about 8-9 hours. The last part of it slowed down. But that's still bearable. While the very bad drive, as noted above is well past 2 weeks working on 500GB and still has about 4-5 % remaining to recover.

HTH and YMMV