4

I have a Hitachi 640GB laptop hard drive that has some bad blocks. I don't believe the blocks are physical bad blocks, because the drive doesn't make any clicking noises. The hard drive is formatted as NTFS, and was used as a Windows 7 drive. I ran CHKDSK on the drive three times, and while it did report multiple orphaned files and corrupted files, and reported fixing them, the drive was still unable to copy the files to another working drive I'm using.

I decided to use ddrescue to rescue the files. I have a 2TB USB drive that I am recovering the files to with ddrescue. The Hitachi drive is hooked up with Firewire 400 to an iMac I am running ddrescue on.

I use the command parameters:

sudo ddrescue -r3 /dev/disk5s2 test.img test.logfile

Ddrescue seemed to run fine for several days, and the img file is the same size as the Hitachi, so that seems normal too. However, for the past 3 days, ddrescue has been stuck on what appears to be the final piece of the drive. The error size reported is 36404KB, and a successful read only occurs once every 12 hours or more. I'm attaching a screenshot of my ddrescue output in the Terminal, as well as my copy of the ddrescue logfile for reference. The drive is continuing to hum away as ddrescue access it, but so far very little progress has been made.

For some reason, when I tried to use direct disc access, the Terminal returned the error: Direct disc access not available, so I wasn't able to use it in my ddrescue operation.

Should I stop the ddrescue operation and restart it? Should I possibly change the command parameters to try the data on this last pesky area of the hard drive? Or is it simply really corrupted so ddrescue can't retrieve it, or if it can, would it simply take a very long time?

Any advice on this matter would be greatly appreciated!

Logfile Output

[logfile output 1

Terminal Output

[terminal output 2

3
  • 2
    First, your supposition that there are no bad blocks because there is no clicking is blatantly incorrect, clicking sounds can be an indicator of many things including bad blocks especially when they are a symptom of a larger problem, but it does not necessarily occur just because you have some physical defects on the drive. Give ddrescue time, I've seen it take several weeks and the behavior your seeing is not uncommon
    – acejavelin
    May 11, 2016 at 11:56
  • Ok thank you for that advice acejavelin. I'll try to be more patient then!
    – Guy Noir
    May 11, 2016 at 20:41
  • 2
    For what it's worth, I recently imaged a 320GB drive with ddrescue that had an errsize of approximately 18000k. It took 6 1/2 days to completely work through all the errors using the same paramater set you used here. Oct 11, 2017 at 18:16

1 Answer 1

2

From GNU ddrescue Manual:

be aware that a bad drive can block ddrescue for a long time until the kernel gives up

There is also this question. The answer there suggests to let the drive get cool. I do not know if it's a good advice though.

As for problem with direct access: the manual mentions raw devices (see example 2). The raw command will be useful here. I admit I have never used (i.e. had to use) ddrescue that way.

2
  • 1
    Thanks for the reply Kamil. I did follow your advice and interrupted ddrescue and let the drive completely cool down. I'm now rerunning it as we speak. I'll keep everyone posted on its progress.
    – Guy Noir
    May 11, 2016 at 20:42
  • 2
    Finally, ddrescue completed the scraping stage, and is now doing the retrying stage. That seems to be blocking it, but I'm going to try to discover which files ddrescue has marked as bad and see if it's worth trying to retry them. The error size is only 35MB, so that's not a whole lot to worry about.
    – Guy Noir
    May 20, 2016 at 6:59

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .