OS X Online Backup (Configuration)

If you’ve made it this far, that means that you’ve successfully configured your encryption keys, connected to your backup server, and used rsync to backup some test data — congratulations!

(If you’re just joining us, you’ll probably want to look at Part 1 and Part 2 of this series before continuing.)

The next step is to configure our actual backup.

What to backup?

It’s worth taking a moment to consider what you actually want to backup. While it’s possible to backup your entire Mac, it adds somewhat to the complexity (there are files you have to exclude if you want to backup an entire running Mac), it takes a loooong time, and there may not be much point.

Unlike a “clone backup” on an external drive, you’re not going to ever use this backup to restore your machine from “bare metal”. Instead, if the worst happens and you have to put everything back, you’re going to be reinstalling OS X and an FTP program before you even begin restoring. That being the case, why spend the time and backup space to actually back up OS X?

I feel much the same way about applications — they’re going to fall into two catagories, the ones I have CDs for, and the installers and updates I can replace by downloading them (particularly once I can get my registration keys, etc. from my backup.)

For me, the “sweet spot” of this kind of backup is to backup the OS X “users” directory (or folder, depending on how you look at things) — this gets the majority of the data I care about — my documents, desktop, music, pictures, etc., along with my preferences for applications.

On my Macbook Pro, this amounts to about 30 gig of data at the moment, versus the 65 gig I have in use on the whole drive — in other words, less than half the drive, for virtually everything I’m concerned about being able to recover.

This can be pared down even further — for instance, I keep my music on an external drive, plus my favorite items are on an iPod. If your music is also on your iPod, and you keep the main library in your “Music” folder, you may wish to exclude this from your backup.

Alternatively, you may opt for the precision approach — perhaps you’re an Entourage user, and what you’re mainly concerned about is your Entourage database (with all of your mail, contacts and appointments). You could backup just that data, and (comparatively) very little time and backup space doing so.

Or any combination of the above — you can mix and match, backup your users folder weekly, your mail daily, whatever makes the most sense for you.

Since we’re going to ultimately automate all of this, what we want to build is a Unix “shell script”. Don’t worry, it’s very simple to do.

You’ll want a “general purpose” text editor — not something that’s going to save “rich text”. Anything you use for building web pages is fine, for example. My go-to text editor for stuff like this is the excellent freeware TextWrangler.

Here’s a quick example of my backup script for backing up my “users” directory:

rsync -avz –delete -e “ssh -i /backup/ssh_key” “/Users” username@server1.talanovbackup.com:userbackup

Again, that’s all on one line (replace “username” with the username for your backup server account).

This is saved in my “/backup” folder (that we made previously) as “user-backup.sh”

Let’s break this down a little.

• “-azv” says “archive”, “compress”, and “verbose mode” — this means “backup all of the directories below the one we specify, compress everything, and tell me what you’re doing.”
• “-delete” says that if something is deleted from my machine since the last sync, delete it from the backup too. (careful here — this means that if you accidently delete something, be sure to retrieve it from your backup server before the next time your backup script is run!)
• “-e “ssh -i /backup/ssh_key”" says to do it over SSH (Secure Shell) using the keys we generated earlier to authenticate the session.
• “/Users” is what to backup (along with everything that it contains).
• “username@server1.talanovbackup.com:userbackup” says “log into server1.talanovbackup.com as user “username” and place all of this stuff in a directory called “userbackup” (you could name this anything you like).

We will automate this in an upcoming step, but we’ll want to execute our script manually first, just to make sure it does what we want it to do.

If you haven’t yet, you’ll need to make your script executable, using the terminal application:

sudo chmod 777 /backup/user-backup.sh

To run it, type:

sudo /backup/user-backup.sh

Assuming you’ve followed through with the example I’ve shown, this is probably going to run a looong time the first time around. My 30 gig took two days to do the initial backup, over a Verizon FIOS (fiber optic) connection — remember that for most consumer broadband, your upload speed is far slower than your download speed.

A major advantage of rsync, however, is once you’ve done the initial backup, sending just the changes is quick. My daily run of this same script takes 15 - 30 minutes (depending on what all I changed on my machine), in the middle of the night. It could take 6 - 8 hours for all I care.

You don’t have to worry about disturbing this initial run, either. If you end up having to stop it, reboot your machine, etc., just restart it with the command above — it will pick right up where it left off, with very little lost time (just the initial comparing of the files that it does.

In the next part of this series, we’ll look at some alternative configurations for your backup script.