I am recovering a friend's drive that contains "would be nice to have" data. This is my first go at diy dr. The 650gb drive is mostly full (music I believe). I purchased a $50 pcb and had it adopted by DonorDrives dr company. The drive sounded a lot better after the fact, the clicking became many times quieter. The dr company also indicated that one or more heads is damaged.

I am now running ddrescue to image this drive, estimating it will take a total of 8 days at its current transfer rate. The drive keeps getting into areas that triggers the clicking/head panning every 20mb or so, but never shuts down. Is there a way to disable heads on trial and error basis, to isolate the bad ones, using MHDD or some other free utility? And can someone tell me if the error rate that I am getting means that I may get 1/2 the files or 1/2 of "data" with very little chance of any whole files (once I start carving)?

I am attaching a screenshot of ddrescue session. On occasion I have to relaunch it after it quits from I/O errors, but so far it always managed to pick up where it left off.

Details about the drive:
Drive: WD 640GB WD6400AAKS-00A7B0
PCB: 2061-701537-E00 07PD3

If it indeed has a bad head, even if you disable that head the chances of getting a lot of good data is slim, just because of the ways data is written to the platters.

I am unaware of any free, or even cheap utility that will disable the head, but in the end you will need to swap out the heads to get the one surface reading with a good head.

a 640gb should take no longer then 4-5 or so hours to clone with a good set of parts, even with a minimal amount of bad sectors.

The fact it states 8 days, I would just stop, because you could potentially make things even worse.

I know your friend would like to have the data and probably will not want to spend much on it, luckily the drive is id'ing and reading somewhat, so a head swap may be a somewhat cheap endeavor (around $700) at this moment. If you continue your efforts it could make things worse and more expensive for a pro to handle it, or impossible.

Just a heads up for you

Good Luck

@Ysbelman1,

I agree with Cleanroom and he's answered most of your questions. I'll just add that the ddrescue command line shown is unlikely to be the quickest one, but that may not be important to you (except that as already explained to you, your continued DIY could make things worse).

If your friend chooses to give permission for you to potentially kill the original disk while trying, then I'm concerned about the ddrescue error shown on that screenshot. It's a write error, meaning (in your case) a problem writing to either /dev/sdc1 or to "logfile" (I don't have time to check the ddrescue source code right now, to see if that specific error message gives more clues). Neither of those locations should report a write error, so there is something fundamentally wrong in your setup, or with that system. Then you copy the logfile to a mounted filesystem, and run ddrescue again, using logfile - so why copy it to that filesystem... I don't understand. Anyway, if I was getting write errors while using ddrescue, I would find & fix the cause - otherwise you might end-up losing the clone which you are trying to create (if, for example, the drive which is you /dev/sdc1 is failing). Check for errors logged in dmesg related to /dev/sdc1 or logfile, if you haven't already.

With the write errors...is there any chance you are cloning in the wrong direction? It might not hurt to do an fdisk -l and post the screenshot too.

_________________
Luke
Recovery Force Data Recovery

Lcoughy, way to go to scare me I had to go back and double check my mounts. I think I did that right, at least. /dev/sdb is 640gb source drive, /dev/sdc is 2TB clone target. But very good point, which I missed, that it was a write error, not read. It may have occurred around a time I was running >df on the target drive (maybe expecting it to change in usage statistics, but it probably is correct to stay at near zero used as ddresque image would not create files)

The logfile copy I am doing is just to back it up to another flash disk. I am running a live ubuntu from a flash on a barebones motherboard. And /tmp is in volatile memory. If this setup craps out on me, I will use the flash directly to keep track of the logfile. So far however no kernel panics and no shutdowns.

As far as professional DR, my friend already said goodbye to his drive and no to $1,000 quote from dr company. This thing is totally mine to experiment with.

Speaking of experimenting, is head swap on this 2008 WD drive possible in a home environment? I think I read somewhere that the cover plate controls the platter alignment and once I unscrew it, I will never be able to reapply the same torque on each screw. Is that true?

You didn't give the exact df command that you used, but because you chose /dev/sdc1 as the output file for ddrescue, you do realise that you are overwriting the first 640GB of that 2TB drive, don't you? There is no valid original filesystem (any more) on /dev/sdc1 (if one ever existed) - therefore I don't know what you were trying to "df" on the target drive, as "df" only works on filesystems (if you're writing to a device/partition as the target, then you cannot sensibly have any mounted filesystem on that same device/partition).

Vulcan, thank you for the explanation, Cleanroom as well. The 2TB drive was totally clean before hand. I did create an NTFS partition with gparted tool before I got started with DDrescue. So that's what showed in df. Ddrescue destroyed that ntfs partition sounds like, which is fine.

If this process completes, big if, I should see something on the 2TB drive by running Foremost or PhotoRec, right? Would you recommend halting and inspecting the target or will that disturb the image in some way. Waiting 8 days is not a problem either, but not as much fun

there no software that you can buy that can disable the headstacks.
i think we all wish there was.


only expensive hardware tools.

also hit and miss on the data if the main head is faulty and there data on there
then you wont be getting any of it as it writes to the different platters

Sorry no.
You can try it if you want, since you have nothing to lose as you say, but it will fail.


You mean the top lid of the drive.
No, there is no alignment issues on these models, but as I've said, head swap on non-clean environment and zero experience... <0,1% chances of success.
Sorry.

As said by Cleanroom and Vulcan, waiting 8 days is not a good idea. It means the drive is struggling and will eventually fail. And when it fails, it fails for the worse.
Of course, since there is nothing to lose, you can try and wait. I'm guessing it will take much more than 8 days, but...

Again, if your friend has ANY value for the data, power off the drive and seek for a better solution (a cheaper quote?). I would ask him to have a look at this thread before deciding.

Good luck!

_________________
http://www.northwind.gr
SandForce SSD Recovery
Ransomware Reverse Engineering - NoMoreRansom! partners

Hi again,
Ddrescue finished imaging. It really sped up later into the process, from 900kb/s to 2mb/s. The ratio of rescued per error size is roughly 1:2. Not good. It follows what you guys are saying about data being written to different platters.

Another annoyance, the target drive isn't in pristine condition as I thought. It explains a few write errors ddrescue encountered.

Now I am running TestSisk on target drive, yet another multiday process. Ugh! Attaching screenshot.

Does the result from TestDisk (quick scan) tell you anything ? The first line is "WD640GB", that has to be the image i am after. Are the rest of those entries - left overs from partitions that existed on the drive prior?

Thanks everyone for your input!!

Should have tested it before cloning using MHDD


And erased it (using MHDD) to avoid data contamination


..next time

Hope you get your data though.
good luck