Saturday, 8 March 2008

This post is now out of date!

Old stuff below for historical record only...

So I promised in my previous post that I would give an update on how I got my wireless Time Machine backups working from a Mac running 10.5.2. I’ve also found a useful utility to control how often Time Machine runs (and found out where the appropriate property list files are kept) and I understand a little more why Apple have made this whole shebang an unsupported option…

Setting up from 10.5.2

The setup process is a little convoluted, but it’s not too hard to follow. What you do need, however, is a second Mac on which you can share some space using Apple’s built-in file sharing.

The first trick is to create your initial Time Machine backup on the second Mac, and then copy that backup across to the unsupported share. Once it’s there, Time Machine will happily accept it and continue backing up.

The second trick is to make that initial backup as small as possible so you don’t have to wait for the setup or copy a huge amount from the second Mac to your wireless backup repository. Michael on pastebin came up with the idea of changing your Time Machine preferences to exclude your local hard disks, but to include a very small mounted disk image instead.

You can create this image using Disk Utility (use the “Mac OS Extended (Journaled)” format) and once mounted, go to the Time Machine preferences and remove it from the “Do not back up” list under the Options… button. While you’re here, add all your local hard disks to the list (just while you create the initial backup).

Set Time Machine going, backing up that empty disk image onto the share on the other Mac (it should only take a few minutes). When it’s done, turn Time Machine off for the moment and copy the files that Time Machine created across to your wireless backup. Be careful when you do so — if you’re copying from HFS to a different disk format, you’ll need to use tar as follows:

tar -czpf backup.tgz *.sparsebundle

This will create the file backup.tgz which you can copy across onto your wireless backup server. Once there, run:

tar -xzvf backup.tgz

…and you should end up with both the sparse bundle folder that you copied, and a ._file of the same name that gives Mac OS X some information about the directory.

Now you can go back to the Time Machine preferences and point it at your wireless server where you copied the files (you have already activated the unsupported network drives haven’t you?). Go into the options and remember to remove your local hard disks from the “Do not back up” list, and you can unmount and delete that empty disk image now as well. Your wireless Time Machine should now be ready to go — just be patient for the first backup.

Control how often Time Machine runs

I’ve finally found a utility that claims to control the frequency and times of the backup run — TimeMachineEditor. The previous application I found, Time Machine Scheduler, wouldn’t even install on my Mac, let alone run, and it seemed to be running its own scheduler rather than tweaking the settings of the existing one.

By looking through the binary of TimeMachineEditor, I also found the property lists that it works on: they’re at /System/Library/LaunchDaemons/com.apple.backupd-auto.plist and /System/Library/LaunchDaemons/com.apple.backupd-attach.plist. I’m not sure if this app tweaks these settings or also runs its own scheduler, but it’s happy to install and run.

Caveat Maxtor

So Felix on Apple’s discussion list has documented one reason why Apple has made backing up to an SMB share an unsupported option. When disk space runs out, Time Machine deletes old backups to make room for the new ones. This is by design — the system automatically thins out hourly backups older than a day, daily backups older than a week and weekly backups as needed to maintain space for new backups.

However, Felix noted that when Time Machine was supposed to be cleaning up space, not only could it not reclaim any space, but it then went on to delete all his old backups without telling him. He put this down to a bug in the sparse bundle space recovery code — the old backups were being deleted but the sparse bundle wasn’t getting any smaller. Indeed, when he compacted the sparse bundle by hand, he got loads more disk space back.

I’m wary of this issue as I’ve noticed exactly the same thing in my own logs. I’m going to keep checking the status of my backups as the disk fills up (though there’s plenty of space at the moment!) and will try to run hdiutil compact <sparse bundle> in time to prevent backups going missing!

Update after applying latest Time Machine system upgrade

I just ran the Time Machine and AirPort Updates v1.0 and this problem has been fixed! My logs now show that when there isn't enough space on the disk, Time Machine will delete the least important backup then eject the disk and compact it to recover the free space before trying again. This is fantastic news and the reports that Apple has enabled Time Machine on USB disks attached to Airport Extreme base stations give me much more confidence in using a third party NAS box. More details in my latest post.

About Me

I make things for mobile, web, voice and LEGO; create all sorts of stuff at Tesco Labs using agile development in any language that fits; run a CodeClub for kids in St Albans.
I blog about mobile stuff, Mac stuff (especially Time Machine), agile stuff and the events I attend.
I am @adamcohenrose on twitter — follow me!