Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I'm read up a bit about this tool and obviously looked at the man pages. The trouble is that ddrescue takes so long I need to get the command right first time. I wasn't sure how to improve on the vanilla;

$ sudo ./ddrescue -v /dev/disk0s5 MyVolImage.dmg MyVolRescue.log
$ sudo ./ddrescue -v MyVolImage.dmg /dev/disk1s3 MyVolRestore.log
  • From HSF+ to HSF+ drives
  • Source (Broken) HDD is connected via USB 2.0
  • Dest HDD is inside MacBook
  • I would choose accuracy over speed

There seem to be a lot of options but I'm not sure how they impact quality and speed of recovery.

Thanks,

Gav

share|improve this question

2 Answers 2

From HSF+ to HSF+ drives

So this can be found via search, you meant HFS+ (Hierarchical File System).

Helpful tip: you can do sudo -s by itself to drop you into a root level shell thus you only type sudo once (drop it from commands above). So, do so:

$ sudo -s

Indeed, ddrescue is taking an eternity for me but my drive is rather hosed. If you create a log file (as you should), you can always stop it and restart with new parameters. From what I've found so far (updates may follow), the best way to use the tool follows.

First, using either a Unix command (below) or Disk Utility GUI, unmount the failing partition(s) if they mounted

# diskutil unmount disk0s5
# ./ddrescue -v -n /dev/disk0s5 MyVolImage.dmg MyVolRescue.log

The log is critical. It allows you to interrupt the program at any time as well as run it against the drive multiple times.

(Note, both the target image file and the log file must be stored on a reliable drive and not the bad drive (which you unmounted anyway). Ensure you know where they will be stored. The above command would place them in the same folder as ddrescue. Also of note, the entire source disk will be copied into the image so you must have enough disk space on the target volume.)

The -n option tells it to run through the entire disk to copy off everything it can without retrying (rescuing). IMO, this is best as you want a baseline and helps in case the drive fully dies during the process. Once that finishes, run it again to go after the bad areas of the disk:

# ddrescue -v -r 3 /dev/disk0s5 MyVolImage.dmg MyVolRescue.log

The -r 3 tells it to retry bad areas 3 times. Note, we're reusing the log file created the first time. You can set that as high as you have patience for but you may want to save some time for a final run.

# ddrescue -v -r 3 -R /dev/disk0s5 MyVolImage.dmg MyVolRescue.log

as the manual states -Retrimming the areas already marked bad can lead to success as it will retry the sectors in a different order.

Instead of doing this:

# ./ddrescue -v MyVolImage.dmg /dev/disk1s3 restore.log

You may be able to use Disk Utility to mount a copy of the Image, repair if necessary and go from there. It's best to copy the disk image before modifying it in case there are problems. The Finder ought to copy faster than ddrescue, too. I'm thinking working with the image is easier because you don't have to worry about partition size problems with an actual disk.

Further recovery tools are testdisk (didn't try it and not sure I want to) and PhotoRec both are at CG Security and require compiling. PhotoRec can be used to recover a multitude of different types of files which is done by scavenging the drive or image regardless of directory structure.

There is talk about using raw devices to speed access but I have no proof yet that they work reliably. Prepend the letter r before disk to have OS X use it raw (no caching).

share|improve this answer

Had this issue with a Seagate 500GB 2.5" 7200rpm disk last week. It was in NTFS. After you've recovered all you can with the above commands, make a copy of the image and get yourself the latest binary of testdisk (free, VERY good but quite geeky to use). If you can, google the drive model number and find the manufacturer's specifications as a PDF file. They will contain the geometry info for the disk (which might help testdisk make sense of the recovered image if the disk lost its boot sectors). Now, since you posted on this discussion, I take it you are recovering a Mac formatted drive. If it's an Intel Mac, it' a GPT partition scheme with one or more HFS+ Journaled volumes on it. I'd therefore try running the command line version of Disk Utility like so: Open a Terminal. Enter diskutil verifyVolume and see what the output says. If it goes through all the steps and reports errors on the volume, etc... use diskutil repairVolume and see if that makes it mountable again. Otherwise run sudo testdisk and have it analyze the partitions on it and continue with the tutorials on CGSecurity's website. If the partitions are messed up bad enough, your only option might be file carving and recovering just the files, but you will lose all file names and directories.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.