Backing up Snow Leopard Server with mlbackups

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 – 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?
# What is the name of this backup set?

# 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" "">
        <string>Back up the disk RA Server Data every day.</string>

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]

Fixing Mangled Contact Labels on iPhone

Image representing iPhone as depicted in Crunc...
Image via CrunchBase

A coworker sent this along.  I’ve had this issue on a few contacts and didn’t really have time to delve into it.

Name removed to protect the innocent and good intentions.  Be very careful with this and make sure you have a backup of all data that you plan to manipulate.


After serially using every calendar/address book interface under the sun and transitioning to Snow Leopard with Exchange syncing, I ended up with a bunch of munged Address Book extension labels in my iPhone Contacts like:


The extra long labels forces the text to be tiny, and rarely displays even then to say whether this is the work/home number.

If you encounter this problem and you’re a Mac user with a Unix background, I’m sure you can think of a dozen ways to fix this … else see some rudimentary Address Book/iTunes/command line steps below to handle large numbers of Contacts at once.

Caveat emptor.

The munged contacts had labels like:


… the bracketing parts are the problem. I can live with “HomePhone” versus “Home Phone”. YMMV.

Correcting this involves a few steps and a tiny bit of command line stuff:

– Attach your iPhone to your computer. Let it sync. Leave iTunes open.

– Open Address Book, select all your contacts, then File->Export to your Desktop, call it “backup.vcf” — don’t touch this file — if something goes wrong you’ll restore this.

– Do a second export of all the contacts to another file “munged.vcf”, or some name equally meaningful to you.

– Open a Terminal window, and cd to your Desktop (“cd ~/Desktop”). Just for paranoia’s sake, type “more *.vcf” and use the space bar to step through the files, making sure they contain all your contacts. Type “ls *.vcf” to confirm the files are the same size. Yeah — sheer paranoia, but who wants to reenter all their contacts? 🙁

– In the previously opened Terminal window paste this command and press return:

cat munged.vcf | sed -e 's/EX-//' | sed -e 's/_$!<//' | sed -e 's/>!$_//' > fixed.vcf

– in the Terminal window type “more fixed.vcf” — confirm the ABLabel fields are corrected before going onto the next step. If the fixed.vcf file doesn’t look right, stop and consult a local Unix person. You did something wrong or your problem wasn’t the one I had. Bail out or get help.

– Go back to Address Book, select all the contacts (if not still selected), then Edit-> Delete Cards. Delete all your contacts. Paranoia now seems appropriate.

– Go back to the iTunes window. Select the iPhone in the Devices list on the left (if not selected), then select the Info tab at the top of the main window and scroll to the very bottom to the Advanced items, select Contacts under “Replace information on this iPhone:”. Click Apply and let the phone sync. Check the Contacts on the iPhone to see they are gone.

– Go back to the Address Book window and File->Import, selecting (you guessed it) “fixed.vcf” from your Desktop. Check the reloaded vcards/Contacts.

– Go back to the iTunes window, and again select the option to Replace the Contacts info, Apply, and let the iPhone sync.

– Try the Contacts on the iPhone, and the labels should be corrected. Delete all the ancillary files on your Desktop.

– Avoid whatever odd combination of things you did that caused the problem in the first place. 😉

In case you want to mess with any other fields/changes, vcard format is described here:

Reblog this post [with Zemanta]

Quick Safari/Snow Leopard Tip

If you’re having stupid amounts of trouble with your plugins loading in Safari 4 on Snow Leopard, go to your Finder and open /Applications.  Right-click on the Safari app and choose “Get Info.”  On that screen, you’ll see a checkbox to run the app in 32-bit mode.

Check that.

Restart Safari if it’s open.

Now you’ll find that your plugins magically work.  I guess this whole 64-bit thing has caught developers with their pants down.  Not sure how that happened since they’ve only been talking 64-bit on the Mac and Windows side for years.

Reblog this post [with Zemanta]

Scaling Guidance

Image representing Microsoft as depicted in Cr...
Image via CrunchBase

At WWDC 2009, I stood up in a session on Snow Leopard server and lightly rattled Apple‘s cage about its poor scaling guidance for the product. They were spending a great deal of time talking about the benefits of Wiki Server 2, but there was little to take away from the session on what to tell any prospective customers regarding cost.

I think in the Apple world, there’s this unspoken rule of “whatever’s good enough” to suffice for an environment. That’s fine, but what I’d really like to be able to do is recommend a solution that will do the job.

In the past, Microsoft was very good about providing specific scaling guidance. Around the Dark Ages (which I define as the day SQL Server 2005 came out and every product hence), Microsoft pulled back on several things. Most notably, they stopped providing specific scaling guidance on products and very clear documentation.

The documentation that was offered with each product varied and was mostly vague and notional. Once my Microsoft TAM asked me as part of some kind of survey if I thought that blog content provided by Microsoft developers and whatnot could be considered as official documentation. It seems like some folks within the organization believe this to be so, but Goddess forbid you end up in the India support organization… where only the script in front of them is official documentation.

Back to Apple. They provide documentation and it’s usually quite good. They provide fairly extensive documentation. Sometimes it’s wrong, but it’s still documentation. It’s something to point to and say, “See here, it says this should function this way.” That’s a nice level of comfort. What they do NOT provide is scaling guidance. They will never ever tell you, “It will take x amount of Snow Leopard servers to run Wiki Server 2 for 10,000 users doing y amount of data.” Why not? I suspect it’s because they don’t know.

As Apple becomes more and more relevant in the enterprise, this has to change. If I’m going to propose an Apple-based solution to any of my prospective customers, I have to have something to work from. It cannot be “we’ll just throw some servers in there, watch it, then buy more.” Most customers… at least the government for sure… do not like that approach.

Ironically, I started this post as a complaint against Microsoft for providing not just vague information on this… but a box full of vague smoked up with an opaque fog on the glass.

That sucks, guys. Stop contributing to the failures of the IT industry and fix it.

I’m looking at you too, Apple.

Reblog this post [with Zemanta]