I'm trying to use ddrescue to help a family member whose 750gb laptop HDD is failing (Windows 7). They went and bought a 1tb laptop drive and so I loaded up the SystemRescue CD on their laptop and popped the new one into a USB enclosure, used fdisk to set up matching partitions (for the 3 partitions that matter) and began to try and run ddrescue on the main data partition:

1. For the first 50 gb or so, it seemed like 95% of it was "rescued" while the errsize was maybe 5 gb. I left it and came back about an hour or two later and it was now at 150 gb, but now the errsize was about 146 gb and the rescued was only 4 gb. My first question is - why would suddenly all of that "rescued" amount go away and become errors?

2. After pass 1 (copying), it's now trimming failed data. Pass 1 ended with roughly the same ratio with only about 25 gb rescued out of the 700 gb on the partition. It's "trimmed" about 500 gb so far and the rescued amount has only increased to about 45 gb.

3. I noticed the old drive has a 4k physical sector size and 512 byte logical sector size - would not specifying a 4k sector size have anything to do with the problems? Here's fdisk -l output for the drives:

Here's the current output:
Any help would be appreciated. Also, my understanding is that since I'm using a logfile, I can interrupt and re-run the same command to resume where I left off. Is that correct? And if I do that, but change the sector size, will it cause problems since it's already beyond the first pass?

Going through a similar process now.

generally you can change a large number of options when you stop and restart. the log file just keeps track of your last location and which areas on the drive have and have not been tried (and the outcome). it will just read that file, and pick up where it left off.

I've never seen the Rescued actually drop. but I have noticed that on the drive I'm rescuing, the disk will go non-responsive if an error gets hit too often. (drive basically goes temporarily dead, not even appearing in an fdisk -l). When this happens, ddrescue doesn't know, and just gets an error on the read attempt. so it starts logging errors for each spot tested. My drive will come back to life a minute or so later, but in that time ddrescue will fill almost the entire remaining log with these false 'errors' (because each read is much faster when it's not actually reading anything).

After it's finished with trying to copy from all untried areas, ddrescue will then move into the next phase, splitting/trimming all the failed blocks. since almost all of your drive looks like failed blocks, it'll stay there for a while. I don't know exactly what it's doing there, but I imagine it could be slower than the 'copying untried blocks' stage.

Because my drive drops out so often, I use the -i and -s options to give it chunks to try at a time (start at 5GB, copy up to 5 GB, etc.) then if it drops out, it'll only fill that 5GB chunk with errors. If I come back later and see that, I can run the same command with a -A --retrim to mark all of those errors as 'not tried'. then set it to run again, maybe skipping to a slightly later section. As you can guess, it has turned running the program into a very hands-on process.

SO...It's possible that you're drive went non-responsive and ddrescue filled the log with a ton of 'errors' that may or may not be real. since they're filling almost the whole hard drive, you could clear them with the -A --retrim option and re-run the recover. it'll start trying to copy where the first error was. this can include actual bad sectors, however, which could cause your drive to drop out again. in that case you may want to set it to start at a different location with the -i option, or have it work backwards with the -R, etc.

If you want a better idea for what it's doing, download 'ddrescueview'. you can open the log file and it'll give you a visual display that it periodically updates while you're running ddrescue.

forgot to add: if you use ddrescueview, the physical layout of the errors / rescued spots on the disk might give an indication of what happened.

if you have good sectors mixed in with the bad, then I guess the drive was at least partially responsive during the rescue. If it's one solid block of red, then maybe the drive dropped out.