Draconis Software Blog

It’s day four of backups week at the Draconis Blog, and today we’re going to be taking a look at the MacOS. Similar to the Linux setup, getting rsync to work on MacOS X is very easy (it should already be installed with your system).

If you’ve been following along, you’ll notice there are lots of similarities between the different platforms we’ve covered (Linux, Solaris, and Windows) and today’s focus is on the Mac. The main issues we faced are slight platform discrepencies (i.e. using Scheduled Tasks in Windows over cron, directory path names, and using the Cygwin tool in Windows), but using rsync has been universal. And today is no different.

As a quick recap, we have a single Linux rsync server setup to facilitate the transfers between any other computer on the network. This Linux box has plenty of free disk space (mounted at /backups) and has a different rsync profile for each host. Remember also that transferring to the server or from the server makes little difference, as far as rsync is concerned.

Before we get started, though, there are a couple of notes:

First, if you’re using the FileVault protection system (which encrypts all the files in your home folder), then you need to decide whether you want to backup the files encrypted or unencrypted. This is important as it determines how you’ll be running your backup script. If you run it normally (i.e. as the same user who owns the files), then your files will be backed up unencrypted (the system automatically decrypts them before they reach rsync). If you’d rather keep the files encrypted for backups, then you’ll want to run rsync as a different user (which the system will interpret as someone else logged in – thus leaving your home files encrypted).

Second, I’ve heard from several sources that rsync bundled with MacOS prior to 10.4 doesn’t preserve resource forks. Resource forks in the MacOS are data portions of applications for Classic (i.e. MacOS prior to X) and are necessary to preserve MacOS Classic applications. To preserve resource forks in rsync (MacOS 10.4 and later), you must specify the -E flag (more on this later). If you have MacOS prior to 10.4 and need to preserve resource forks (i.e. you’re backing up MacOS Classic applications), then you’ll need to upgrade your rsync.

Now that we’ve got that out of the way, let’s take a look at configuring rsync for backups on the Mac. After making sure you have the right rsync installed (for resource forks, if they matter to you), the next step is to set up the recipient computer: in this case, the Linux box (as I mentioned earlier). In order for the Linux computer to receive files from the Mac, it has to have a “profile” in rsync’s configuration file that tells rsyncd what to do with the received files. Creating the profile is easy. Login to the Linux box and open the rsyncd.conf file (usually in /etc/rsyncd.conf):

[upsilon]
path=/backups/upsilon
uid = ryan
gid = ryan
read only = true
auth users = ryan
secrets file = /etc/rsyncd.secrets

Adding this block to your rsyncd.conf file (and restarting rsyncd if it’s running as a daemon) will tell it to store received files from clients using the upsilon profile into the directory /backups/upsilon. Additionally, as we’ve been doing all along, we keep an rsyncd.secrets file, which contains the password for our rsync users (in this case, the username is ryan, so in our rsyncd.secrets file, we have a line that looks like ryan:password). Additionally, we set several other options, including whether files stored in /backups/upsilon should be marked read only (I turn it on so there’s an extra layer of protection, just in case), and what user/group IDs should be set for the files (rsync sets these when storing the files, and should match with users/groups on the Linux box).

Now that we have the receiving end set up, the next step is to setup the transferring end – in today’s case, that’s our Mac. Luckily, this is incredibly simple (since rsync should come installed by default). Here’s an example command that backs up a home directory:

/usr/bin/rsync -vrtpog –password-file=/etc/rsync.secret –delete /Users/ryan ryan@10.0.0.2::upsilon

Let’s take a look at this command: First, we call rsync directory (which in this case, was installed at /usr/bin/rsync). I do this because I will be adding this command to a cron entry to run on a regular basis, and don’t want to have to deal with potential PATH issues.

Second, we pass several command arguments:
-v is to be verbose (this will print out what it’s doing and the files that are being backed up to stdout)
-r is recursive, so we get everything in /export/home (and not just one level)
-t preserves file access/modification times
-p preserves file permissions
-og preserves file/group ownership IDs (even if those IDs don’t map to users on other systems)

Third, we also reference a file called /etc/rsync.secret, which, as we’ve done in the past, points to a simple text file containing the password for the user ryan (and which matches the password stored in /etc/rsyncd.secret on the Linux recipient end). This is important, as rsync will pull the password for the user from that file rather than prompt us to enter it every time we run the command (and allowing us to automate the process).

Fourth, we use the –delete argument, which keeps the backups side in sync with the transfer side (and if we delete a file on the Mac, it will get deleted in Linux).

Finally, the last two arguments specify where we copy files from, and where we copy files to. In this case, I’m copying the files in the ryan user directory (on the Mac, that’s /Users/ryan, rather than /home/ryan) to the Linux rsync server’s upsilon profile (which, ultimately, ends up in /backups/upsilon in Linux).

If you’d like to copy directories outside your home directory, such as all user home directories, then you’ll need to run the above command as root (thus, add “sudo” to the front of the command) – just be sure the account running the backups has Administrator privileges.

Try running the command in a Terminal (Applications -> Utilities). It’s likely to take a few minutes, but you should see plenty of file names scrolling past as they get copied to the backup computer. If you have problems, double check you have the server’s address right, that the passwords on both sides match, and you got your from and to arguments correct. Once you get it working, you should have a complete backup of your files on your Linux computer! The next step, then, is to automate the process.

Automating the backups
In the MacOS, there are several ways to automate tasks: you can attach Folder Actions (so a command/program is executed whenever you modify the contents of a certain folder; you can attach commands/programs to events in iCal, to schedule when certain things run; or you can use cron, the scheduled tasks system that exists in Linux, Solaris, and just about every other UNIX-like operating system). In this case, the best solution is to use cron.

Setting up a cronjob for the backups is very easy, but you need to figure out what needs to be backed up first. If you’re only copying over files for one user (and then, only files owned by that user), then you can setup the cron entry to run as that user. If you’ll be copying the entire /Users directory, or potentially files that are not all owned by one user, then you’ll need to run the backup commands as root. To login as the root user, open a Terminal and type sudo su (enter your sudo password).

Now, in the Terminal, we need to add the cron entry. Type cron -e (to go into edit mode), and add the following:

0 3 * * * /usr/bin/rsync -vrtpog --password-file=/etc/rsync.secret --delete /Users/ryan ryan@10.0.0.2::upsilon 1>/backups.log

This will run our rsync command at 3 am every day. A couple things to note here:

First, I kept the verbose flag set and redirected standard output to /backups.log (a text file that’s overwritten every time the command is run). This shows us what was most recently transferred, and can be a great tool to double check that files are being transferred.

Second, due to the way cron works, any output that appears on standard error will be emailed to the user specified by the MAILTO command in the cron entry (so be sure that’s set properly!). This should give you useful info should a backup fail to work one day.

When you’re done editing the cronjob, save it and close your editor – it should go into effect immediately (and thus backups should run next at 3am).

And that’s it! You now have a working backup system from your Mac to your Linux box. If you’re interested in setting rsync up as a server on your Mac, just replicate the steps for the Linux rsyncd setup (though the main difference is to run rsyncd in daemon mode instead of from xinetd/etc).

Tomorrow we’ll wrap everything up and take a look at some advanced options for rsync.