2

I recently had a friend with a new Hitachi 2TB 32MB 7200RPM 3.5" SATA 6.0Gb/s Internal Desktop Hard Drive with Win7 Pro OS that was reported by Windows as failing. He asked me to recover it and replace the drive. This was not a boot drive. It still had a few days to return it to the vendor.

I was unable to access it with anything in a new PC (with different known working SATA controller and SATA data and power cables).

Interestingly, Hitachi's DFT reported everything was fine: SMART Status : Healthy

Test Log

    ReadErrStat       : Done
    Result            : Pass


    SMART QT          : Done
    Result            : Pass

Despite 3 Windows Events indicating the same SMART failure. Description: The driver has detected that device \Device\Harddisk3\DR3 has predicted that it will fail. Immediately back up your data and replace your hard disk drive. A failure may be imminent.

I used ddrescue 1.18.1 on System Rescue CD.

Because the HDD was new I expected all the data/files would be in the first quarter of the drive. ddrescue took about 25 hours to burrow its way through the 2TB drive and write to a new 2TB drive (I suspect some now know what my issue will be). I didn't have any bigger drives.

ddrescue -n -f /dev/sdb /dev/sdc resq.log

ddrescue recovered all but 347 files (about 0.5%), but reported it could not properly finish because it ran out of drive space on the destination drive. The slow transfer rate as well as the rising count of non-recovered files ended about one quarter into the recovery process indicating it was past where the--or at least most--data files were present and was literally now recovering virgin territory.

These were both NTFS formatted, single partition of the entire drive drives (new one was a new Toshiba 2TB HDD).

On Linux, I cannot mount the recovered drive to copy it, nor view it. Keep getting NTFS format error.

I do not want to see if anything is visible on a Window OS due to the propensity of such to offer to fix things, which I do not want it to attempt.

To make matters worse, I bought and GPT formatted a 4TB drive and started to repeat the ddrescue and the failing HDD completely failed less than 10% of the way in.

I have been reading the ddrescue manual as well as several forums and cannot find for certain instructions on how to repair the "full" destination drive so it is accessible. I do not want to make any mistakes that could corrupt data further. Anyone have any ideas on rescue/repair so I can make a copy and then see what was recovered and where things stand?

Improve this question
3
  • First I recommend you double check your SMART stats. Some critical SMART stats only update themselves during a disk check, or other disk maintenance utility. if it is not already failed, you have a couple options. if you have no reallocated sectors or current pending sectors, then Testdisk may be the best tool for you. if you do have bad blocks, or testdisk fails, I recommend you try again using this approach for ddrescue: superuser.com/questions/786488/… .
    – Frank Thomas
    Commented Sep 12, 2015 at 4:27
  • 1
    ddrescue is a block-level utility, not file-level, so if your filesystem metadata or other critical disk structures are damaged, you may not be able to mount the disk, but if there is valid file data on the partition, it may be retreivable with file-carving utilities like PhotoRec, recuva, Easus, etc. using a utility like this on the recovered image will hopefully recover much of your file data, though if the filesystem metadata is damaged, it may lose filenames and directory paths. for this reason, its much better on content drives, not system volumes.
    – Frank Thomas
    Commented Sep 12, 2015 at 4:31
  • Thanks to Frank-Thomas for interesting information on ddrescue itself. I should have realized it did not see files, but bits. And recovers as much as possible without regard letting it be sorted out later. The original 2TB drive is now completely dead and RMA'd to vendor. The 2TB drive the material was rescued to is currently undergoing a ddrescue attempt on its partition to the partition on the 4TB drive purchased for the attempt per DavidGo's recommendation. That seems a very safe shot.
    – Fascist Nation
    Commented Sep 13, 2015 at 17:51

1 Answer 1

Reset to default
1

When you say "ddrescue recovered all byt 347 files", what do you mean ? ddrescue should do a bit copy of the hard drive, so it does not deal with files.

Its unclear where your rescue log is/was - do you still have that ?

I would be inclined to do a bit copy from the good 2TB drive onto the 4TB drive.

I would then attempt to do a ddrescue again from the bad 2TB drive to the good 4TB drive - but this time adding the -R switch so it tries to recover from the end of the disk (because I think the 2TB drives were slightly different sizes so it did not get the end bit). If you have access to the log file, try use that as well, as it will probably make life a bit easier - but its not critical I guess

I would then see if I could access the data (off the 4 gig drive) in Linux, if not - and I expect I'd not be able to I would give it a go under Windows and see if it could read it.

If this failed I'd then use photorec on the good 2TB drive to pull off whatever I could, bypassing NTFS.

Improve this answer
2
  • Thank you for your response. My bad, I should have said 347 errors, not files were found. The rescue log is wherever the root directory is which I presume is on the destination drive. That is so simple a solution. Thank you so much! I have already started ddrescue and will report back how it turns out.
    – Fascist Nation
    Commented Sep 13, 2015 at 17:36
  • Update to close the thread: The suggestion to just run ddrescue again on the ddrescue destination drive that failed to close properly because it was the same size as the source drive only now using this destination drive as the source and a bigger drive as the destination worked! Thank you.
    – Fascist Nation
    Commented Sep 20, 2015 at 16:45

You must log in to answer this question.

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