ddrescue failure question

Question

I'm trying to run ddrescue on a damaged hard drive. For a while, it ran smoothly but intermittently, often going several minutes to an hour without getting any data. After, it started going fast, but only reading error, and getting tens of thousands of them. Is this a definite sign of hard drive damage, or could it be caused by something like a scrambled partition table? Also, could the disk be damaged in a way that using ddrescue could be making the damage worse?

Answer 1

DDrescue can make the disk worse, to minimise you want to try and get the good block as quick as possible.
You can set DDrescue to copy the good blocks first using the -n flag eg:

ddrescue -f -n /dev/sdb sdb_rescue.img sdb_rescue.log

Then run DDrescue again trying to recover ( reusing the existing log will skip the successfully recovered logs) eg:

ddrescue -d -f -r3 /dev/sdb /root/sdb_rescue.img sdb_rescue.log

DDrescue can try and recover the partiton table in the state it is on the disc, then you can try and repair the partition table on the recovered image.

A failing drive tends to develop more and more errors as time passes. Because of this, you should rescue the data from a drive as soon as you notice the first error. Be diligent because every time a physically damaged drive powers up and is able to output some data, it may be the very last time that it ever will.

You should make a copy of the failing drive with ddrescue, and then try to repair the copy. If your data are really important, use the first copy as a master for a second copy, and try to repair the second copy. If something goes wrong, you have the master intact to try again.

If you are trying to rescue a whole partition, first repair the copy with e2fsck or some other tool appropriate for the type of partition you are trying to rescue, then mount the repaired copy somewhere and try to recover the files in it.

If the drive is so damaged that the file system in the rescued partition can't be repaired or mounted, you will have to browse the rescued data with an hex editor and extract the desired parts by hand or use a file recovery tool like photorec.

If the partition table is damaged, you may try to rescue the whole disc, then try to repair the partition table and the partitions on the copy.

https://www.gnu.org/software/ddrescue/manual/ddrescue_manual.html#Examples

Answer 2

from the ddrescue manual https://www.gnu.org/software/ddrescue/manual/ddrescue_manual.html

Never try to rescue a r/w mounted partition. The resulting copy may be useless. It is best that the device or partition to be rescued is not mounted at all, not even read-only.

Never try to repair a file system on a drive with I/O errors; you will probably lose even more data.

So yes, in answer to your question, ddrescue could be making matters worse indeed any procedure which tinkers with a damaged (or even undamaged) volume has the capacity to do further damage.

Answer 3

but intermittently, often going several minutes to an hour without getting any data. After, it started going fast, but only reading error, and getting tens of thousands of them.

That happened to me with an SSD drive. I found out that turning off the computer for a while and restarting the process (using a mapfile) fixed the issue (as in, the rescue started to work again). I think the reason for the issue is that the computer controller or the drive firmware go in a state that is not recoverable. At that point, the only way to fix things is to turn off the computer completely (i.e. not just a reboot).

If ddrescue says it's "Finished". Trying again as is will not do anything. Instead, the next time you want to run ddrescue to try to get those pesky sectors you were not able to read the first time, use the --retrim command line option. This marks the map as not yet "Finished" and restart the scraping process. That way blocks that were missed the first time may be rescued the second time.

Also, on my end, I started to stop the process once I saw errors. That way, it does not skip thousands of sectors doing nothing (talking with a controller which cannot recover). That worked great for me. After each restart, I was able to recover more and more data. At first, I had some 649 Gb of "errors". The second time, that went down to 167 Gb. The next time 149 Gb. The last time (so far) under 2 Gb of errors. So if you really want to rescue as much as possible, a full power cycle may be your only option.

Is this a definite sign of hard drive damage, or could it be caused by something like a scrambled partition table?

If you are using ddrescue, that's probably because you at least suspected the drive was bad. If a sector is damaged (cannot be read) then you'd get errors. The damage may be permanent (you can never get the sector read again) or temporary (re-trying later, especially after cooling off the drive, may work reading that very sector).

ddrescue knows nothing about partition tables. The kernel tells where the data starts and stops on a given device. That's all ddrescue uses.

Also, could the disk be damaged in a way that using ddrescue could be making the damage worse?

ddrescue is kind of your last chance unless you have thousands of $$$ and can hire a professional company to restore the data on your drive. Instead, you should have made backups (and, yes, me too).