I've had plans for a while now to set up a backup system using a Debian Linux server and rsync to back up my MacBook Pro laptop. At first glance, it seemed like it would be pretty straight forward. I've been able to make a bootable copy of my entire MBP using nothing but rsync (thanks to some very helpful directions by Mike Bombich, the creator of the popular, and free, Carbon Copy Cloner software). And by bootable copy I mean I could literally plug in the USB drive and boot my MBP from the drive (hold down the Alt/Option key while booting). Restoring a backup is as simple as running the rsync command again, but in the reverse direction. I know this solution works because I used it when I upgraded to a 320GB hard drive.
To start, I needed to create a big enough partition on the external USB drive using Disk Utility (formatted with Mac OS Extended (Journaled)). I then made a bootable copy of my MBP with one rsync command:
sudo rsync -aNHAXx --protect-args --fileflags --force-change
--rsync-path="/usr/local/bin/rsync" / /Volumes/OSXBackup
But my dream backup system was more unattended. I wanted something that would periodically (a couple times a day) run that rsync command over SSH (in the background) and magically keep an up-to-date bootable copy of my MBP on a remote server.
I love Linux and I jump at any opportunity to use it for something new, especially in a heterogeneous network environment. So when I decided to set up a backup server, I naturally wanted to make use my existing Debian Linux machine (which just so happens to be running on an older G4 Mac Mini).
So, after making a bootable copy of my MBP using the local method mentioned above, I plugged the drive into my Linux machine, created a mount point (/osx-backup), and added an entry to /etc/fstab to make sure it was mounted on boot (note the filesystem type is hfsplus):
/dev/sda /osx-backup hfsplus rw,user,auto 0 0
All that's left to do now is to run the same rsync command as earlier but this time specifying the remote path in the destination ([email protected]:/osx-backup/). This causes rsync to tunnel through SSH and run the sync. Unfortunately, this is where things started to fall apart.
OS X uses certain file metadata which must be copied for the backup to be complete (again, we're talking about a true bootable copy that looks no different than the original). Several of the flags used in the rsync command above are required to maintain this metadata and unfortunately Linux doesn't support all the necessary system calls to set this data. In particular, here are the necessary flags that don't work when rsyncing an OS X partition to Linux:
-X (rsync: rsync_xal_set: lsetxattr() failed: Operation not supported (95))
-A (recv_acl_access: value out of range: 8000)
--fileflags (on remote machine: --fileflags: unknown option)
--force-change (on remote machine: --force-change: unknown option)
-N (on remote machine: -svlHogDtNpXrxe.iL: unknown option)
According to the man page for rsync on my MBP, the -N flag is used to preserve create times (crtimes) and the --fileflags option requires chflags system call. When I compiled the newer rsync 3.0.3 on my MBP, I had to apply two patches to the source that were relevant to preserving Mac OS X metadata:
patch -p1 <patches/fileflags.diff
patch -p1 <patches/crtimes.diff
I thought that maybe if I downloaded the source to my Linux server, applied those same patches, and then recompiled rsync, that it would be able to use those options. Unfortunately, those patches require system-level function calls (such as chflags) that simply don't exist in Linux (the patched source wouldn't even compile).
So I tried removing all unsupported flags even though I knew lots of OS X metadata would be lost. After the sync finished, I tried booting from the backup drive to see if everything worked. It booted into OS X, but when I logged into my account lots of configuration was gone and several things didn't work. My Dock and Desktop were both reset and accessing my Documents directory gave me a "permission denied" error. Obviously that metadata is necessary for a viable bootable backup.
So, where to from here? Well, I obviously cannot use Linux to create a bootable backup of my OS X machine using rsync. I read of other possibilities (like mounting my Linux drive as an NFS share on the Mac and then using rsync on the Mac to sync to the NFS share) but they seemed like a lot more work than I was looking for. I liked the rsync solution because it could easily be tunneled over SSH (secure) and it was simple (one command). I can still use the rsync solution, but the backup server will need to be OS X. I'll be setting that up soon, so look for another post with those details.
Now, that’s an interesting problem.
Off the top of my head, the only thing that I think would work anywhere near flawlessly would be to create, say, a xen instance on your server running opendarwin or some such to use for backup purposes. FreeBSD or OpenBSD might work as well, but I’m admittedly a bit ignorant as to how much stuff Apple changed for Darwin. Also, I don’t know how much the usage of a DomU as the main server will mess with cpanel, to be honest (probably a lot), and it may not be in check with the provider’s TOS.
Another option would be to use a combination of dd, netcat, and ssh (so you can netcat over a secure tunnel), but then you’re talking about a handful of other possible problems. At the very least, this would more-or-less remove the ability to restore, say, a single directory from the backup.
Ooh … the NFS solution will have the same problem that rsync to linux does, as the endpoint still runs on a hosted filesystem. An alternative that would almost certainly work, however, would be to install and configure iscsid on your server, then initiate and initialize it from your MBP. You could do the rsync to the mounted iscsi target at that point, and things would Just Work, since there is not a hosted filesystem in place. Consider this to be the halfway point between a straight rsync solution and the dd solution that I mentioned previously.
Hey DWalters,
Those are some great alternatives! I forgot all about OpenDarwin but unfortunately it appears the project shutdown in 2006. I’ll have to look closer, but I suppose it’s possible the latest release supports everything necessary to copy all the HFS+ metadata to a filesystem.
I had thought about the dd option (although admittedly not dd+netcat+ssh) but realized it wouldn’t work for me because I needed a way to do incremental backups (sync only the stuff that changed). Besides, I have a 320GB HD in my MBP with only 15GB of free space and dd+netcat+ssh over the network to transfer that much data seems to be asking for trouble (data reliability, etc).
With the NFS solution, I was under the impression that mounting an NFS share and then rsyncing data to the share would work because only the rsync on my MBP would be called, but I realize now that NFS is just an abstraction and that the extra metadata wouldn’t even be copied (right?).
I’ll definitely look into FreeBSD/OpenBSD to see if they support everything necessary to make a bootable HFS+ backup of my MBP. I haven’t really done anything with FreeBSD/OpenBSD and I suppose this is a great reason to start learning.
Thanks a ton for the clarification and suggestions!
No problem at all, man.
As a quick clarification, while the NFS layer would inevitably fail for the reasons that you mentioned, the iSCSI method that I mentioned earlier will almost certainly work, as the filesystem operations are done completely on the end that initiates the connection to the target, seeing as the initiator sees the target as a raw block device. Roughly, it’s the same idea as ATAoE, but a different protocol.
I’ve never used iSCSI before (in fact I had not heard of it until you mentioned it), but the Wikipedia page on iSCSI is very informative and it sounds like a very promising solution. It doesn’t appear that Leopard supports iSCSI out of the box, but there are several commercial products, and at least one free iSCSI product for OS X that should give me what I need.
Ideally, I’d like to stick to using rsync for doing the transfers and by using iSCSI it looks like I will be able to do that.
Thanks again! 🙂
Have you had any luck with further trials following the suggestions in the comments, especially ISCSI?
A later post suggests that you have re-installed Debian and played around with HFS+ disks (i.e. you haven’t made your server run on Mac OS X), but I didn’t see anything else mentioned.
By the way, if you use only one rsync process (i.e. on the client alone) because both the disk with the data to be backed up and the disk to write the backup to are attached locally (e.g. when the target disk is mounted via NFS or ISCSI), you will not be able to use the delta transfer algorithm of rsync 3 which speeds up transfers a lot for cases where not much data has changed. As Matt McCutchen, an rsync developer, puts it:
Hey HBF,
The iSCSI solution actually worked perfectly and I can backup to an HFS+ drive (that’s sitting inside a Debian Linux box) using rsync! I’m in the process of writing a post with the details of how I set that up and as soon as I publish that post, you’ll be able to find a link to it at the bottom of this post.
Thanks for the note on the delta transfer algorithm! I wasn’t aware that it couldn’t be used with only one rsync process. That definitely explains why rsync seems slower when using the iSCSI method.
Thanks for the reply, good to know it’s working! When your post with the details is out, I’ll read it with interest. I will (hoepfully) also be able to play around with this method in a few days and see if the lack of the delta transfer algorithm slows things down to much for me.
Any updates on this? I would be interested to know how managed to solve this problem (Mac backup to Linux network drive) … I don’t think any quick solutions have been developed in the meantime.
Hi Dan,
It’s been a while since I’ve done anything with this but I did have some success with Walter’s suggestion to use iSCSI. If you read the comments above, I posted a link where you can download a free iSCSI app for Mac (again, this was a while ago, so I’m not sure if the app works with the latest OSX).
The only issues I had with using the iSCSI method were that OSX seemed to lose the connection to the remote drive. I never investigated to see if it was a problem with my network or a problem with the iSCSI app on OSX.
Earlier this year I sold all my possessions and now I’m a nomad traveling with just my laptop, so backing up to a Linux server really isn’t feasible anymore. Now I use Carbon Copy Cloner to do a full mirror to an external USB drive.
Good luck and let me know if I can help with anything else!