DDRescue taking months but no errors?

Question

I'm having a hard time finding others with the same error, and I'm trying to figure out the best path forward.

I have a hard drive that was unusably slow, and then stopped booting. The clonezilla clone failed, and I started a ddrescue, using the gnu rescue tool included with a clonezilla live cd. It is going unbelievably slow averaging about 400 kBps for a 2 TB drive, so I'm estimating almost 4 months! at this point. My last backup was sadly about 2 years ago, and there are a lot of pictures I'd like to get off of it. The surprising part is that its rescued about 50 GB, with no errors so far, even though its taken 3 days. I have a few questions on the best path forward, and why it would take so long but also not have any errors.

Is the drive just taking forever to succesfully read, but never actually failing, slowing down the copy time? Is the hard drive itself fine, but something like the control board the problem?

I'm very worried about where the logfile is likely going. I can't depend on my computer staying steady, and the command not erroring for four months. If I'm talking at all about keeping it running for even weeks, I'd like to get that logfile onto a flash drive. I originally thought it was going onto the new larger hard drive, but now I realize its likely on the RAM drive clonezilla_live is utilizing. Is it safe to insert a formatted USB drive, mount it, and copy over the log file, then restart the ddrescue? Will the clonezilla shell even recognize that I inserted the USB stick that wasn't there on boot, so I can mount it?

I'm assuming I'd try sudo fdisk -l to list the disks, then make a directory? sudo mkdir /logfile/usb then mount it? sudo mount /dev/sdb1 /media/usb, then copy?

ANY feedback would be appreciated. I've screwed around in Unix shell a bit, setup a z-pool raid, but always when I knew exactly what I was doing, and not in linux, let alone a bare-bones version.

Answer 1

If anyone is interested or comes across an archived version of this in a few years. I waited the two months, establishing a log file to resume copying. Twice it just started getting reading errors (until the computer was restarted), and once I lost power. After months of copying, I plugged the backup in via a USB adapter to another laptop, I probably had 7.5 mb of the ~2 tb that wasn't copied (still had errors after -r3 (3 retries)). It was unreadable, but I rebuilt the partition table per these instructions: https://perrohunter.com/repair-a-mac-os-x-hfs-partition-table/ - I did have to change the block size since this drive is much larger than the older drives.

It then worked close to flawlessly. I did a disk verify and repair, and permissions repair in disk utility, and it booted up fine.

Real lesson learned? I'm using backblaze for the really important files (photos and documents) and a mirrored bootable backup on-site.

Answer 2

ddrescue marks bad sectors not until it reaches the second phase: https://www.gnu.org/software/ddrescue/manual/ddrescue_manual.html

(Second phase; Trimming) Trimming is done in one pass. For each non-trimmed block, read forwards one sector at a time from the leading edge of the block until a bad sector is found. Then read backwards one sector at a time from the trailing edge of the block until a bad sector is found. Then mark the bad sectors found (if any) as bad-sector, and mark the rest of the block as non-scraped without trying to read it.

And the problem is: It can take a looong time until this phase starts. Its devided up into three passes:

1. copy forward and mark blocks as rescued, non-trimmed and non-tried depending on timeouts etc.
2. copy backwards and read all non-tried blocks
3. copy forward without skipping to prepare large errors for trimming

Unfortunately nobody can predict how long this phase will take as it depends on the amounts of errors (hours, days, weeks or even month as in your case).

Note: The --retry-passes=n (r) flag is only important for the fourth phase:

(Fourth phase; Retrying) Optionally try to read again the bad sectors until the specified number of retry passes is reached.

So it does not speed up the first phase with its passes by reducing the retrys.

But you can see in the ddrescue log file if it has marked some blocks as "rescued" so you can hope it will rescue some or all data of the drive. Here is an example:

#      pos        size  status
0x00000000  0x00117000  +
0x00117000  0x00000200  -
0x00117200  0x00001000  /
0x00118200  0x00007E00  *
0x00120000  0x00048000  ?

If the log file contains lines with the +-status there is hope. It means "rescued". But if it only contains ? (non-tried) and * (non-trimmed) I think you can give up. Of course there could be a chance that the drive is only defective at the beginning, but I think this is only a small chance. But if you can afford to run ddrescue through a second pc you should try it depending how important the data is. The final hope could be to replace the head/electronics but this could be expensive.

An alternative to analyze the logs is to use ddrescue log viewer: https://sourceforge.net/projects/ddrescueview/

I use Parted Magic as it contains ddrescue GUI and ddrescue log viewer.

Here you can see a screenshot of the viewer in the middle of phase 1 pass 2 (copy backwards):

The arrow shows the current position. As you can see this drive has many possible bad sectors (in this phase marked as "non-trimmed") in the middle and that was the reason why I gave up.

Answer 3

Make sure that you data is still being copied - check the output files, and make sure that their size keeps increasing. Failing hard drives have a tendency to freeze up when you try to copy a lot of data off them at once.

If it looks like it isn't doing anything, it's probably best to stop the operation, then go back and copy one directory at a time, so that if this happens again you will at least have a complete directory. If it is working, you can leave it be for another day or two. Time estimates are often terribly incorrect, but it definitely shouldn't take a month!

I'm not to familiar with ddrescue but I often use Data Rescue at work, and I've never seen a complete hard drive image complete if it doesn't do so within a day. That being said, it's best to only copy over the directories you need (probably /home,) since applications can be reinstalled and settings reconfigured, but documents and pictures can't be replaced.

As far as the log files, I wouldn't touch them while a data rescue utility is running.