Ask Different is a question and answer site for power users of Apple hardware and software. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a partially corrupted HD that can not be repaired by Disk Utility, but which can be mounted read-only making the data on it accessible.

I am trying to copy all the recoverable contents onto a spare HD, but every method I try fails when an error is encountered - leaving the remaining files uncopied.

Finder - Fails. SuperDuper - Fails. Ditto (terminal command) - Fails.

I was hoping that Ditto would do the trick, the Ditto man page says:

ditto returns 0 if everything is copied, otherwise non-zero. ditto almost never gives up, preferring to report errors along the way. Diagnostic messages will be printed to standard error.

I have submitted a bug to Apple re ditto failing to perform as advertised.

Any other ideas?

share|improve this question
up vote 8 down vote accepted

rsync (from Terminal) has an option for that (--ignore-errors). However crafting the right command line arguments may be somewhat complicated. A nice rsync GUI is Carbon Copy Cloner (donationware)

After you are satisfied with the cloning setting, launch clone in CCC and immediately after run from terminal

ps axuww| grep rsync

and you will see the right command line arguments. Then just add --ignore-errors

share|improve this answer
rsync is very nice since when you ask it to recursively copy entire directory trees, it will log errors and move on. You can then kill the sync - look over the errors and then exclude some of the worst offenders if the depth-first search jumps to a really corrupt directory before reaching files you need to copy. – bmike Feb 7 '12 at 15:52
--ignore-errors does not what you think it does. It tells --delete to go ahead and delete files even when there are IO errors. – LCC Aug 21 '13 at 9:22
This is the worst answer. 1. It answers the wrong question. 2. The answer is wrong, even for the question it tries to answer. – Sam Watkins Jul 23 '15 at 5:28
copying commands and executing without knowing what they actually do. Wow...! This is the worst answer possible! – Preexo Aug 18 '15 at 11:58
--ignore-errors does exactly the opposite of what is wanted. With --ignore-errors enabled, rsync will delete files that have been previously synced if they now have I/O errors. – inxilpro Oct 3 '15 at 0:32

I use cp -Rfv sourcefile destinationfile with success on a pretty regular basis.

cp = copy

R = maintains file hierarchies

f = if an existing destination file cannot be opened, remove it and try again

v = verbose mode, displays files transferred as it progresses

sourcefile = data you want to copy

destinationfile = directory/drive you want to copy to

share|improve this answer
How does this ignore errors on the source drive (see the question)? – patrix Aug 21 '13 at 5:42
@patrix It doesn't "ignore" errors but the "f" flag forces through them, only copying intact data. As you watch the progress (thanks to the verbose flag) you will see output along the lines of "data not copied due to I/O error" when it encounters bad data. Once the error is displayed it moves on to the next file without any user input. The poster's scenario sounds extremely similar to the dozens of times I've used this command to retrieve data from flakey disks/volumes. – Mr Rabbit Aug 21 '13 at 15:17
Is there a way to copy a failing file with some postfix, so all the missing files are better found? – user106278 Dec 27 '14 at 3:20

Try Gnu ddrescue -- it's a data recovery program that does block-based copying with corrupt data recovery during the copy operations. You can get it for OS X if you're using Homebrew by typing in an Terminal window:

brew install ddrescue

A guide on arstechnica describes how to rescue a failed disk using ddrescue. Make sure you read through the guide, as it contains helpful information. Here is a gist on how to get there.

  • Locate the drive using diskutil list. The identifier column is what you are looking for:

       #:                       TYPE NAME                    SIZE       IDENTIFIER
       0:      GUID_partition_scheme                        *750.2 GB   disk1
       1:                        EFI EFI                     209.7 MB   disk1s1
       2:                  Apple_HFS Macintosh HD 2          80.0 GB    disk1s2
       3:                  Apple_HFS Home                    509.1 GB   disk1s3
  • Unmount the disk in question:

    diskutil unmount /dev/disk1s3    
  • Start a rescue operation of the disk into an image. Make sure the location of Rescue.dmg is replaced with your desired location.

    sudo /usr/local/bin/ddrescue -v -n -c 4096 /dev/disk1s3 Rescue.dmg Rescue.log
  • Recover the image onto a new drive:

    sudo /usr/local/bin/ddrescue --force -v -c 4096 Rescue.dmg /dev/disk2s0 recovery.log

Be advised to also read the manual of ddrescue to educate yourself on the available options by running man ddrescue.

share|improve this answer

We're looking for long answers that provide some explanation and context. Don't just give a one-line answer; explain why your answer is right, ideally with citations. Answers that don't include explanations may be removed.

To add to the moderator notice: this could be a very good answer to the problem but it needs more work. Can you add some sample ddrescue commands for OS X devices to the answer? I've fixed it up a bit with the kind of background and information we like to see in answers here. If you do that, I'm sure it'd be a great response. – Ian C. Apr 21 '14 at 17:10

This Macworld hint suggests using dd to make a bit-by-bit copy (ignoring errors) then mounting the resultant image in Finder to recover your files. I've not tried it, but it sounds like it might work.

share|improve this answer
This is good, because you want your data off fast if that disk is duff. In this way, you get a block for block copy, including errors, that will then be available for inspection at your leisure without worrying that the disk will peroperly die before you get everything off it. I will perform one operation, in a nice neat start to finish without skipping all over the place from file fragment to file fragment which will be harder work on the drive that created the DD copy. – stuffe Feb 7 '12 at 11:26
ddrescue is better than dd at this, since it'll retry bad sections over & over for as long as you leave it running -- see this previous answer where the OP god his data off after a couple of weeks' grinding(!). Note that this is a good approach if the HD hardware is failing, but does nothing at all to fix volume structure corruption -- that just gets copied along with the files. – Gordon Davisson Feb 7 '12 at 18:36

You might consider using the dd command to perform a block-by-block copy from your corrupt HDD to your new HDD.

Assuming your new-HDD (/dev/disk2) is of equal or greater size than your corrupt-HDD (/dev/disk1), then you can issue:

dd if=/dev/disk1 of=/dev/disk2 bs=4096 conv=notrunc,noerror

blocksized @ 4k, don't truncate any data blocks, ignore all errors

To find the device names, run mount from Terminal first.

share|improve this answer

The ditto command should work, I would use ditto in conjunction with the -v option for verbose so you can see exactly what gives you an error of what it copies.

share|improve this answer
According to the asker ditto doesn't work. Why do you think it does? – patrix Aug 20 '13 at 17:22

Had the same issue so I came up with the following command to copy all files from a source to a destination directory:

rsync -avzh --ignore-errors /path/to/source /path/to/destination
share|improve this answer

Your Answer


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.