I'm trying to move my time machine backup files all under Backups.backupdb to another drive. I initiated a file copy overnight (b/c I saw that it took OSX forever to prepare for the copy...it basically was counting the files for hours). In the morning I saw that only certain backups(folders with dates) got copied over. I then tried to copy over the ones that didn't get copied...but the OS wouldn't allow me to do that. I got and error that "The operation can’t be completed because backup items can’t be modified." So my plan is to delete the incomplete copy on the new drive and then try to copy over the Backups.backupdb folder again.

Pretty frustrating. Is there a faster way to copy these files via a terminal command so that it doesn't perform all of that file counting prep?

I probably can tar up the entire folder and then do a copy, but will that interfere with any of the file permissions, etc.? The one thing with this approach is that I don't have any more space on my source volume for the tar.


I've tried some of the methods that people have suggested below, specifically using Disk Utility's restore function and it's giving me some error messages and unexpected results (at least to me). I've tried to do the restore two ways:

  • With "Erase Destination" checked : Each time (I've tried twice), when the restore has finished I see a message "Could not restore - Invalid Operation" and "Could not restore - Invalid Argument". However, my destination disk does get a copy of my TM files. The weird thing is that my destination disk is EXACTLY like my source disk...even the size. My destination disk is actually 1 TB but after the restore, it shows as 200 GB when I get info from the finder. But in Disk Utility, it shows a 1 TB partition!

I then tried to verify/repair the disk and got:

    Invalid B-tree node size
    Checking Journaled HFS Plus volume.
    Invalid B-tree node size
    Volume repair complete.
    Updating boot support partitions for the volume as required.
    Error: Disk Utility can’t repair this disk. Back up as many of your files as possible, reformat the disk, and restore your backed-up files.

Don't know if I'm even suppose to verify/repair a TM disk...

  • With "Erase Destination" UNchecked : The restore never starts and I get:
    Could not restore - Operation not permitted
up vote 3 down vote accepted

A normal copy (or copy via rsync or ditto) will not replicate a Time Machine fully as it will convert two directories linked together (as occurs in successive TM backups with no change between) into two separate directories.

The best way is to copy the whole the disk using Disk Utility or the block copy part of Carbon Copy Cloner and probably similar on SuperDuper.

Please see @milesmeow comment below. SuperDuper eventually worked flawlessly to copy his TM files from one drive to the next. He cites this blog entry for a clear explanation of attempts with Disk Utility, CCC and SuperDuper.

  • From the ditto man page: "ditto preserves file hard links (but not directory hard links) present in the source directories" so no help here. It's either Disk Utility or a tool like SuperDuper or CCC. – nohillside Jan 1 '12 at 12:20
  • @patrix Thanks - the web man page says nothing on that - CCC uses ditto or rsync for copying so will only do this if it does a block copy help.bombich.com/kb/troubleshooting/… – Mark Jan 1 '12 at 21:33
  • My Source disk only contains the Time Machine backup. My Destination disk contains other files. I don't want a clone of my Source disk. I just want to copy the Time Machine files to the Destination disk. – milesmeow Jan 2 '12 at 11:44
  • Due to the use of hard links there is no easy (unix level) way of exactly duplicating a TM backup without significantly increasing the needed disk space. If you just want to store the latest backup on another drive I would recommend to rsync (or ditto) the latest folder in Backups.backupdb. – nohillside Jan 2 '12 at 12:17
  • After looking at Disk Utility again as per @Mark. I've basically decided to move the files that are currently on my Destination drive to another drive. Now I'm basically using Disk Utility's Restore function to erase the contents of my Destination drive and replace it with the contents of my Source drive. – milesmeow Jan 2 '12 at 12:49

Why not just use terminal:

cp -RnpP Backups.backupdb
  • -R recursive
  • -n do not overwrite (if existing copy remnants remain from previous attempt)
  • -p preserve ACL's, permissions, creation/mod dates, etc.
  • -P preserve hard links, do not follow any hard or symlinks.

This answer will not get it done faster, but I've found is a way to copy the data properly while preserving the de-duplication (hard links) and permissions. As an added bonus I use this to make a compressed dmg of the final product for archiving.

  1. Using Disk Utilities, make a disk image that is larger then your Backups.backupdb directory. I would also suggest that you use sparse bundle disk image for Image Format and Hard disk for Partitions. After this image is mounted, Get info on it and unselect Ignore ownership on this volume.

  2. Now turn off Time Machine, and using the finder copy the Backups.backupdb folder to the mounted image. The finder will ask you for super user permissions to copy the data. Get a drink or do something else for a while.

  3. When the copy is finished, look to be sure everything is okay and unmount the image. From Disk Utility, select Convert and turn the sparse bundle image into a compressed image. Again, this may take a while.

You should end up with two copies of your Time Machine backup, you can delete the sparse bundle version, and put the dmg in a safe place as an archive in time.

One thing I haven't tried with this is to do a system restore from the dmg, but I suspect that it should work, my goal was more for archiving the time machine incremental changes and keeping the hard link structure.

I have also tried rsync and cp, but they didn't seem to keep the hard link structure which would end up making x times the size, x being the amount of dates you had in the past. This method worked well, but again may not get speed of a block copy solution.

Apple has an official tutorial for this.

  • 3
    I for one am looking at this question because following that tutorial (which suggests copying the backup folder with Finder) and leaving it running overnight, it ended on some permission issue with about 500/940gb copied. I then did a sudo rsync last night, but this morning find ERROR: out of memory in flist_expand [sender] and my copy is now ~600gb. I haven't decided what to do next, but suspect most people reading are already aware of the official tutorial. – PeterT Dec 13 '14 at 9:00
  • @PeterT I have just tried the tuto too and got the same issue as you. I am not sure anyone knew about the tutorial, otherwise someone would have mentioned it here and the outcome following it. Now, people know it is not worth trying. – David Andreoletti Dec 14 '14 at 9:39
  • Using finder to copy the folder takes an age to build the file list and then fails anyway with not enough disk space so must be miscalculating. – malhal May 5 '17 at 9:13

rsync is a great utility for stuff like this. I generally use it for stuff like this. In this case I might use the -aP flags. I think part of -a ("archive") is also to preserve permissions, ACLs and the like, but I'm not sure.

IIRC, there's also a --delete option that allows you to delete the source file once it has been successfully copied to the destination. I'd be wary of using that though - usually I do a complete mirror without the --delete option, then I'll re-run the command with the -c and --delete options. -c is checksum, so it checks all the files you've downloaded against all those on the source via checksum, then deletes the source if there's a match, otherwise it re-copies or resumes copying as the case may be.

  • 5
    rsync doesn't maintain hard links on directories. Copying a while TM backup will duplicate a lot of directories – nohillside Jan 1 '12 at 19:41
  • 1
    @patrix - I can confirm this. I've tried it. Directory hard-links are nearly unique to HFS+, and rsync does not understand them. – Fake Name Jan 2 '12 at 12:22
  • 2
    -H, --hard-links preserve hard links – Pete Ashdown Jun 4 '17 at 21:23

With hard drives, when you move multiple files from one drive, the reader moves back and forth making a scary clicking noise, and it slows the transfer rate significantly, for example- one file with usb 2.0 moves at 30 mbps on my computer from 2 external harddrives, but 2 files move at 11 mbps. and 3 files move at 6 mbps. etc etc. zip files will move faster than files.

  • 2
    How does this answer the OP's question? – fsb Aug 12 '16 at 14:37

Your Answer


By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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