Dec 23, '07 10:30:03AM • Contributed by: lukasha
So I just did my first roll out of Leopard server to a client (one server, six iMacs), and I've run into most of the problems everyone's been having (AFP connection issues, iCal server issues, etc.). Due to the wonderfully large brains that visit this site and the Apple discussion boards, I've got it working together finally. So I felt it was time for me to contribute some of my hopefully good wisdom and share what I did for Time Machine.
Of course I was seduced by the ease of Time Machine (TM for short) and the interface that would let the users recover files simply without harassing IT. But reality set in and I quickly realized that Time Machine does not back up well over the network, even to Leopard Server, which supposedly is made to support it. On top of that, I, like every other sane server admin worth his salt, wants a rotating backup that can be taken off site. For small offices, the best option is usally two external FireWire drives rotated weekly. During Tiger, I used rsync on all the client machines in an office and had them back up directly to the external drive on the office server. When they were swapped out, rsync would keep on backing up as long as the drives and backup destination folder were named the same.
I had hoped that Time Machine would be intelligent to handle this too, but obviously it can't. If the drive is swapped out, the next time TM tries to connect, it fails and I have to manually go to each workstation and tell it to choose the network share I created on the server as a TM destination again. Obviously going around to every client on a weekly basis to do this would suck. So I started my thinking cap and tried to come up with a solution that would give the user the awesome Time Machine interface, but back up over the network to my external drive that gets rotated.
After reading on this site that you could point TM to a partition on your main drive as a backup destination after getting past the "if your drive fails" warning, I figured it out. My clients had new iMacs with 250GB drives, and since they were storing their data on the server, they didn't really need much storage. So using Disk Utility, I added a second partition and shrunk the main partition (thank you Apple for giving us the ability to do this non-destructively in 10.5), so that I had a 150GB main partition and a 100GB backup partition.
Each of the client machines and their hard drives are named in a sequence, ie. clientname01, clientname02 or Apple01, Apple02, etc. So I named the new backup partition with the same number so they would be named differently on the backup server, ie. Backup01 is on clientname01, etc. I went into TM and chose the backup partition as my destination and let it do the first backup. Then I dropped to the Terminal and issued sudo setfile -a V /Volumes/BackupXX, where XX is the number of the backup. This hides the partition from being seen in the Finder. TM still sees it and backs up to it, but users can't accidentally eject it or delete files or otherwise mess it up.
Now, I'm still trying to figure out launchd, so I just made a cron job that runs as root to rsync the backup to the server. 10.5's rsync handles forks and other extended attributes, so you no longer have to download RsyncX. Here's the command I use:
date >> /var/log/rsyncd.log; time rsync -a -H -E --progress --force --delete-after -e ssh "/Volumes/BackupXX/." "root@serveraddress:/Volumes/externaldrive/NetworkBackups/BackupXX" >> /var/log/rsyncd.logThis creates an exact duplicate of the Backup partition in the destination folder on the server. All activity is echoed to /var/log/rsyncd.log so you can monitor it (don't forget to add the rsyncd.log to /etc/newsyslog.conf, so that it gets rotated). All the normal rsync configuration is needed, ie., Remote Login turned on at the destination, rsa keys generated and client keys added to the authorized_keys file on the destination so that a password is not required for ssh, etc.
If your client machine dies and you need to restore from backup, go to the server and share the backup folder. On the client, mount the share. Then tell Time Machine to Browse another Time Machine disk and choose the Backups.backupdb folder on the share.
So this makes Time Machine run quickly because it backs up locally and gives a great user experience to the user, gets the backup onto a server's external backup drive that gets rotated, and allows for simple data recovery.
If there's anyone out there with bigger brains than me that sees a problem with this or can think of ways to tweak it, feel free to add to this. All I hope is that this can help some other server admins out there trying to deal with Time Machine and a sane backup policy.
