Apple’s Snow Leopard Server product is one lovely implementation of UNIX. I’ve thoroughly enjoyed using it for the power and simplicity that it offers. I’ve loved using Apple’s operating systems thanks to the combination of UNIX power and elegant design. Snow Leopard server is no exception to this rule.
The barrier to entry with Snow Leopard server was lowered when Apple reduced the price of the product to $499 USD and offered an unlimited client version only. It was even more palatable when the Mac Mini server version was introduced at $999. Previously, you could build your own Mac Mini server for about $1300 USD, but this new model allows small developers and workshops to get into the product at a very low price point.
With that in mind, I’m anticipating that there’s a number of people that are checking out Snow Leopard server for the first time. You might be enthralled with all of its features and niceties. One of those niceties includes Time Machine. However, when you look at what Time Machine really backs up, you’ll discover that it doesn’t back up any elements of your server data.
That’s right. Snow Leopard server is not backing up your mail data, Open Directory data or anything else of that nature. It’s backing up enough to restore the server to an operational state, but you’ll find yourself rebuilding the Open Directory and mail data from scratch. The Apple documentation states that they offer a number of other command-line utilities for backing up server data. These utilities are a number of powerful little guys like “ditto” and “rsync.” For the uninitiated, this means you’re now plunging into the world of search to discover a backup script that will save your hindquarters.
When I was researching this, I came across SuperDuper! and Carbon Copy Cloner most often. While these serve the purpose of making a bootable clone of your server drive, the developers recommend that you do not use their products against Snow Leopard server while the services are running. So, guess what? Now you’re back to looking into a script to stop all of your services, back up the data, then start them back up again.
One side note here: it’s dreadfully easy to stop services with a terminal command or bash script, but I’m not going to go over that here. If interested in this information, let me know and I’ll post it in another article.
After more searching, I came upon a little resource at http://maclemon.at – a site where a fellow has created the backup script “mlbackup.” The site is mainly in German, so it’s not entirely clear what to do with the program. However, it seemed to fit the bill for what I wanted so I decided to check it out.
mlbackup is provided as an installation package. After downloading it, double-click on the pkg to install it. Installation is pretty straightforward but implementation is a different story.
After installing mlbackup, it’s important to know what was placed on your system:
/usr/local/maclemon/* – the binaries for mlbackup and man pages
/etc/maclemon/backup/* – sample configuration file and globalexclusions
Start by copying the sample configuration file to a new file for modification. In my case, I created a backup configuration file that is named after the volume that contains the data for my server. My server’s name is “Ramona” and the server data is stored on a volume named “RA Server Data.” Therefore, I did:
sudo cp demo.mlbackupconf.sample ramona_serverdata.mlbackupconf
This creates a copy of demo.mlbackupconf.sample and names it “ramona_serverdata.mlbackupconf.” Next, you’ll want to edit that new file and make the necessary changes for your server.
I use “vim” to edit, so I type next:
sudo vim ramona_serverdata.mlbackupconf
Using “vim” is an article in and of itself, so I’m certainly not going to cover its usage here. If you’re an innocent newcomer to vim, it can quickly turn you into an innocent bystander of a violent gunfight. Be careful.
Once you’re in vim, hit “i” for insert mode and make the necessary changes to the file. Notably, you’ll want to change some of the items listed below. I’m pasting in the contents of my file and the changes that I made.
# What is the name of this backup set?
MLbackupName=”Ramona_Server_Data”
# What is the name of this backup set?
MLbackupName="Ramona_Server_Data"
...
# What file or directory to Backup. (No trailing Slash for directories)
# Default: $HOME
MLsourcePath="/Volumes/RA Server Data"
...
# Where shall the Backups be stored (local path on the destination machine)
# Default: /Volumes/Backup
MLdestPath="/Volumes/Ramona Backup/mlbackups"
...
# Where to send the eMail notification about the backup to?
# Default: $USER
MLadminEmail="<my email address>"
…
Hit “esc” to get out of insert mode. Then hit “:” and type “wq” and enter. This will save the file.
In case you haven’t deduced it from examining the file, I have two external drives hooked up to this Mac Mini server. One is a firewire800 drive called “RA Server Data.” The other is a larger drive on USB called “Ramona Backup.” My intention is for mlbackup to execute against RA Server Data and back it all up to Ramona Backup. I intend for it to keep 5 sets of backups. mlbackup is pretty nice in that it will automatically clean up the prior backup sets so it only keeps the amount of sets you want. If you’re running this every day, you’ll have 5 days of backups.
One other note here. There’s a bug in the mlbackup script that if the “MLbackupname” parameter contains a space in the name, mlbackup won’t clean up the old backup sets automatically. Found this one out the hard way. If you intend to have a backup set name that contained spaces, replace the spaces with an underscore character to prevent this issue from biting you.
The first half of your mlbackup configuration is complete. You’ve told mlbackup what to do, but now you need to tell it when to do it. The old way of setting up scheduled tasks in OS X was to use a cron job, just like a regular UNIX or Linux implementation. However, Apple has replaced cron with launchd. Now you need to configure launchd.
Launchd is a complex beast. I’ll summarize what I learned about it. Launchd will fire up any tasks on your behalf at any time you define, much like cron used to do. It uses an XML file to define the job and depending on the parameters in the XML file and where you put it, launchd will do different things.
Since it’s so complex, I’m only going to talk about what I did for this launchd task. Your ideas and mileage may vary. I’m interested in hearing what others do with this, so be sure to let me know what you put together.
In my case, I created a new file in /Library/LaunchDaemons. I put it there because I want mlbackup to be executed as root (spare me the speeches, I’m trying to back up server data here) and I want it to have access to the system.
Here’s the contents of the file I created there in /Library/LaunchDaemons. The name of the file is at.maclemon.mlbackup.radata.daily.plist:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<dict>
<key>Label</key>
<string>at.maclemon.mlbackup.radata.daily</string>
<key>ServiceDescription</key>
<string>Back up the disk RA Server Data every day.</string>
<key>LowPriorityIO</key>
<true/>
<key>ProgramArguments</key>
<array>
<string>/usr/local/bin/mlbackup</string>
<string>/private/etc/maclemon/backup/ramona_serverdata.mlbackupconf</string>
</array>
<key>Debug</key>
<true/>
<key>StartCalendarInterval</key>
<array>
<dict>
<key>Hour</key>
<integer>4</integer>
<key>Minute</key>
<integer>0</integer>
</dict>
</array>
<key>AbandonProcessGroup</key>
<true/>
</dict>
</plist>
Again I’m not going to go into a whole lot of detail here about what I did, but I will point out a few items of interest.
Note the “ProgramArguments” directive. There, you see that I’m calling mlbackup and giving it the full path of the config file I created earlier. This is vitally important, otherwise mlbackup won’t do a thing.
The “StartCalendarInterval” element tells launchd when to start the task.
The “AbandonProcessGroup” item is required if you intend mlbackup to send you email at the completion of the job. Without this element, mlbackup won’t send an email and may not clean up the backup sets in a way that you intend.
Finally, tell launchd that you created the file and you want the system to load it up and pay attention:
sudo launchctl load -w at.maclemon.mlbackup.radata.daily.plist
Launchctl is the terminal command to force launchd to load up the file. For some odd reason, without the -w, it won’t load. Why you have to do this is unclear in the Apple documentation for Snow Leopard. In the past, -w controlled whether the job was enabled or disabled. In Snow Leopard it seems, without using -w, launchctl just looks at you funny.
That should do it. You should receive an email from the root user at the end of the backup task if all goes well. If you didn’t receive an email, be sure to check your backup volume and verify that something was written there by mlbackup.
One other note that I forgot to include. mlbackup is mainly just a bash script, but it does contain a newer version of rsync. mlbackup uses this version of rsync over the one that Apple supplied with OS X because it has some vital optimizations for the backup to take place.
That should do it. Hope this helps get your server backups running well.
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=7482d87f-4015-4556-b688-0289644b9f17)
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=1e869009-27b9-4cb4-8aa6-6021660eff20)
