Home / server / Questions / 148682
In Process
gav
Asked: 2010-06-07 05:29:26 +0800 CST

Finding optimal ddrescue command line options where Accuracy > Speed

  • 772

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

data-recovery

2 Answers

  1. 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).

    • 5

  2. I had this issue with a Seagate 500 GB 2.5" 7200 RPM disk in early April 2011. (That disk had a volume that used NTFS.)

    With the commands suggested in the first answer, recover as much as possible to the disk image then:

    • make a copy of that image
    • get the latest binary of CGSecurity TestDisk – free (open source), very good but quite geeky to use.

    Geometry

    If the failed disk lost its boot sectors, then knowing the geometry – information about the cylinders, heads, sectors (CHS) of the disk – might help TestDisk to process the copy of the recovered image. So if possible, discover the geometry – manufacturer's specifications, in PDF, might be found by Googling for the make and model.

    diskutil

    If recovery was from a disk that included the HFS+ startup volume for an Intel Mac, then the disk for that volume would have used the GUID Partition Table (GPT). I'd therefore use diskutil (one of the utilities that is used by Disk Utility):

    • open a Terminal window
    • enter the following command:

    diskutil verifyVolume <PATH-TO-THE-DISK-IMAGE>

    If output in the Terminal window reveals an inconsistency in the file system within the image, then use Terminal to run a slightly different command:

    diskutil repairVolume <PATH-TO-THE-DISK-IMAGE>

    If that attempt to repair the volume fails, then you can proceed with TestDisk.

    A screenshot of TestDisk

    Running sudo testdisk in a Terminal window presents three logging options. After choosing one, the window will appear something like this:

    screenshot of the media selection menu of TestDisk 6.14

    CGSecurity documentation on how to proceed with TestDisk is online.

    If the partitions are messed up bad enough

    Your only option might be 'file carving' to recover just the files – excluding file names, excluding directories/folders.

    • 3