magpiebrain

Sam Newman's site, a Consultant at ThoughtWorks

Now we’ve worked out what files you want backed up, and we’ve sorted automatic authentication, the only thing left to do is schedule our backups. Unfortunately we can’t make use of the very handy iSync or Backup tools to do this (Apple don’t seem keen on opening up these tools up, as they no-doubt help sell expensive .Mac accounts).

h3. cron

cron is available on all *NIX systems, and is a well established solution to running all kinds of house keeping tasks. On OSX 10.4 however cron is being phased out in favour of launchd which we’ll look at next.

launchd

As of OSX 10.4 a new daemon called launchd has been added. Eventually this will replace tools such as cron, rc and xinetd – however it’s low on the userfriendly scale right now. Unlike cron’s simple crontab file, launchd requires XML files which can be a pain to edit without something like the shareware program launchd editor. Hopefully later OSX releases might bundle a decent UI for managing it.

Anacron + launchd – for those who like to switch their computers off

Both cron and the newer launchd suffer from the same problem when it comes to running routine housekeeping tasks – if the computer isn’t on when a task is scheduled, the task won’t get run, and even when you switch the computer on again, neither tool can work out that it should try and catch up by running the task on startup.

So using either cron or launchd means that if we use either task to manage our backups, the computer has to be on when the backup is scheduled to run.

Anacron attempts to solve these deficiencies. It stores a record of when each job was last run, so on startup it can work out if it needs to catch up. This is especially handy for laptops which are probably only on for a few hours a day.

Depending on your operating system, you can either get anacron setup to work with cron, or launchd. Assuming you take the anacron + launcd approach, grab Ronald Florence’s highly useful Anacron for OSX 10.4 installer. Once installed, you should have a file /etc/anacrontab which will look like this:


	

#period delay job-identifier command 1 5 cron.daily periodic daily 7 10 cron.weekly periodic weekly 30 15 cron.monthly periodic monthly

The first field is the frequency of the job – 1 means daily, 7 means weekly and 30 means monthly. The second value is the delay in minutes between anacron realising a job needs to be run, and it actually getting scheduled. The third field is a unique identifier for the job, and finally the command itself.

To simplify things we should create a simple script which contains our rsync command(s) – for now you can place it into your bin directory, and call it something sensible like backup. Next, assuming you want to run the backup job daily, add the following line to /etc/anacrontab:


	

1 10 backup.user /Users/johnsmith/bin/backup

To make sure anacron is working (and is picking up your job) simply start Console.app, and select Open System Log from the File menu – you should see its output. If you need to tweak your backup job, you can remove the record of the previous run /var/spool/anacron/ – it should contain one file per record in anacrontab. Then, you can force anacron to rerun the job by executing anacron -n.

And there you have it! Trouble free, secure backups that will get run even if you switch your computer on for only a few hours each day.

Advertisements

2 Responses to “Trouble free backups, Part Three – Scheduling backups”

  1. Gerhard

    Hi mate, congrats on the great tutorials!

    I keep getting this error with anacron:

    Aug 22 11:04:01 apalia anacron[3031]: Anacron 2.3 started on 2006-08-22
    Aug 22 11:04:01 apalia anacron[3031]: Can’t open timestamp file for job cron.daily: Permission denied

    Any ideas on how to correct the error?

    Reply
  2. Fisslefink

    Thanks, this almost solved my problem… and then a major stumbling block for me was getting cron jobs to authorize SSH keys with the ssh-agent started by SSHKeychain.

    I was getting lots of ‘mail’ from cron that said “Permission denied, please try again.” Clearly the ssh job being run from cron was not authorizing my SSH keys through SSHKeychain!

    This forum post clued me in to the answer: http://forum.strongspace.com/viewtopic.php?pid=700

    What went wrong? The ‘global environment variable’ set by SSHKeychain does not propogate all the way down to cron, which is run with a separate ‘environment’. So you have to tell it where to find the SSH authorization socket. Here is how:

    1) First, make sure you set SSHKeychain to “Manage and modify global environment variables” in the Preferences -> Environment tab
    2) Take note of the “SSH_AUTH_SOCK” variable name … the default is /tmp/501/SSHKeychain.socket
    3) Set that variable in your crontab by putting it at the very top of the file. Use crontab -e to do this from the terminal (you might want to google “vim” to learn how to edit a crontab!). My crontab looks like this:

    SSH_AUTH_SOCK=/tmp/501/SSHKeychain.socket
    0 15 * * 1-5 /usr/bin/backup

    (my backup job runs at 3pm, monday through friday)

    NOTE: I don’t know if this also works for anacron, or if anacron avoids the problem of environment forking entirely (since it is not mentioned in the tutorial)

    Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Basic HTML is allowed. Your email address will not be published.

Subscribe to this comment feed via RSS

%d bloggers like this: