is it possible to keep a boot-able backup drive clone of OS X updated with rsync? If rsync is not a viable option are there alternatives?


drive diagram

My situation is as shown above. One internal Samsung 840 SSD [120g] in use as my OS X 10.8 boot disk on a recent model Mac Mini. I have successfully cloned that drive with Disk Utility to a 125GB partition of another HDD in an external USB 3 enclosure and at that point I am able to boot to it.


As my last system went out in a fiery blaze taking much valuable data with it, I have a new respect for a proper backup solution and really want to do this right. My goal is to achieve an automated differential backup/update from Disk A to Disk B while most importantly maintaining bootability on the external drive. I would prefer to do this differentially to minimize stress on the drives. Hence rsync was the first thing to come to mind.

What I have tried:

following along with Jamie Zawinski's differential Mac bootable backup solution.

running this manually initially worked - I tested it with only very miniscule file change and everything was fine / external booted and all. now after subsequent passes rsync fails throwing errors particularly relating to updating 'boot.efi' (not at the machine currently I will update the precise log message once I return home).

Is this a drive partition size issue? does rsync require more space?

if it can't be done, are there any alternatives? I've heard whispers of dd

  • OS X 10.8.4
  • 2.3 GHz Intel Core i7
  • Mac Mini
  • Disk A is a 120GB capacity SSD with again only about 35GB in use.

  • Disk B is a 125GB Partition as stated above and only has approx 35GB in use with another ~= 90GB of space available

  • I was just throwing this out there as I don't precisely know how rsync operates, but I can't imagine it would utilize more than 125GB of scratch space to differentially back up 35GB of data and settings.


After a few more hours of inability to recreate the issue and failure to successfully operate i stumbled upon a few existing software options and have been giving them a try.

I still would like to know the proper way to differentially update a cloned boot drive with rsync and bless if there is someone with a working process.

  • more details would help, especially the error message. Also OS version, partition capacity and free space (you asked if that might be it, but didn't give the relevant info), what changed (did it ever work incrementally?), ... Jun 29, 2013 at 3:17
  • the initial clone with disk util worked and booted fine- immediately after i created a blank text.txt file ran the rsync and this first attempt was met with success. after a session of use and another rsync attempt, the operation failed and the drive would no longer boot. i have since formatted the external partition to try again.
    – Joe
    Jun 29, 2013 at 17:14

3 Answers 3


My new script wraps rsync, and provides exactly this functionality. It is designed to create clean, bootable clones of Mac OS X, and provides comprehensive logging and error handling.



I’ve used Carbon Copy Cloner for something like this before. Its not free, but it’s pretty cheap and you can use it for 30 days free.


You should review and post (anonymized) /var/log/syslog.log output from after running the script. If that doesn't help you figure it out, please feel free to post relevant anonymized log data. That is how I came to solve my issues with this.

showed permissions errors for me

$ cat /var/log/syslog.log | grep rsync

As you may note, in looking at the logs, there is going to be an error if you cannot write or read the target backup folder. In the original instructions the blog tells you to uncheck "ignore permissions" of the target backup drive in finder (I also had to enable admin to read/write) so that rsync can do it's thing. If you go back and look at the permissions later, you will see that OSX has a tendency to go ahead and change these back to their original configurations anytime the drive is disconnected (i.e. if you restart, sleep, or eject).

Looking through the forums, I found talk that this behavior has something to do with a file named /var/db/volinfo.database. Apparently deleting this file, then setting the permissions you want fixes this behavior. It seems to work for now... I may have to write protect this file, after setting things up, or... like alter the script to change the permissions as required before running the rsync task...

$ sudo rm /var/db/volinfo.database

Please note that if you have set custom permissions for multiple drives... you may want to save the file before you delete it. I'm not sure how deleting this file will affect systems with multiple connected drives, or other saved stuff. Although I think it's a benign fix... it's a good idea to be able to revert easily if you break stuff obviously.

But yeah, this is how I got this solution to work for me. Booted up like a charm. Slow at first... but spotlight/config stuff was happening. Then next try it went much faster...

I believe I will want to tweek the rsync script a little... but yeah... this was a good start for me. I will update later when I have a more finished improvement.

Further, you may wish to try adding to your or any script a command to bless the drive and chown it; OSX does not appear to respect insertable media ownership anymore, and will make your driven no longer bootable, if it has the chance. Also... silly question, but are you holding down option on boot? Even with CCC I can't boot to my bootable drive media in target disk mode... each time it has to be OPT on bootup.

You must log in to answer this question.

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