ServerBackup is a new command included in Lion Server, located in the /usr/sbin/ServerBackup directory. The ServerBackup command is used to backup the server settings for services running on a Lion Server. The command is pretty easy and straight forward to use, but does require you to be using Time Machine in order to actually run.
In the most basic form, ServerBackup is invoked to run a backup using the backup command. Commands are prefixed with a -cmd followed by the actual command. As you might be able to guess, the commandlet to fire off a backup is backup. The backup command requires a -source option which will almost always be the root of the boot volume (/):
/usr/sbin/ServerBackup -cmd backup -source /
The data backed up begins in a .ServerBackups directory on the root of the host running Time Machine. Once the backup is complete the data is moved over to the actual Time Machine volume, using a path of:
/Volumes/<TimeMachine_volume_name>/Backups.backupd/<hostname>/<date>/<GUID>/<Source_Volume_Name>/.ServerBackups
The output of a backup should look similar to the following:
2012-02-01 10:05:17.888 ServerBackup[15716:107] Error encountered creating ServerMetaDataBackupFolder at path := /.ServerBackups!
*** nextPath := 40-openDirectory.plist
*** nextPath := 45-serverSettings.plist
*** nextPath := 46-postgresql.plist
*** nextPath := 55-sharePoints.plist
*** nextPath := 65-mailServer.plist
*** nextPath := 70-webServer.plist
2012-02-01 10:05:18.480 ServerBackup[15716:107] SRC := /etc/apache2/
DST := /.ServerBackups/webServer
Failed to copy /etc/apache2/ to /.ServerBackups/webServer/etc/apache2; ret -> 0
2012-02-01 10:05:18.483 ServerBackup[15716:107] SRC := /etc/certificates/
DST := /.ServerBackups/webServer
Failed to copy /etc/certificates/ to /.ServerBackups/webServer/etc/certificates; ret -> 0
*** nextPath := 75-iChatServer.plist
*** nextPath := com.apple.ServerBackup.plist
curServicePath := /.ServerBackups/openDirectory/openDirectory.browse.plist
WARNING: Service openDirectory folder does not exist for browsing.
curServicePath := /.ServerBackups/serverSettings/serverSettings.browse.plist
WARNING: Service serverSettings folder does not exist for browsing.
curServicePath := /.ServerBackups/postgresql/postgresql.browse.plist
WARNING: Service postgresql folder does not exist for browsing.
curServicePath := /.ServerBackups/sharePoints/sharePoints.browse.plist
WARNING: Service sharePoints folder does not exist for browsing.
curServicePath := /.ServerBackups/mailServer/mailServer.browse.plist
WARNING: Service mailServer folder does not exist for browsing.
curServicePath := /.ServerBackups/webServer/webServer.browse.plist
WARNING: Service webServer folder does not exist for browsing.
curServicePath := /.ServerBackups/iChatServer/iChatServer.browse.plist
WARNING: Service iChatServer folder does not exist for browsing.
There are usually a lot of warnings, as any given server might not be in use on the server. There is a postBackupComplete commandlet that is supposed to remove the .ServerBackups directory following the backups; however, the default behavior seems to be to remove the directory without requiring that option.
You can then view the backup snapshots by path (they can also be viewed by cd’ing straight into them):
/usr/sbin/ServerBackup -cmd list
To delete a snapshot from the list shown (where <PATH> is a path from the output of list):
/usr/sbin/ServerBackup -cmd purgeSnapShot -path <PATH>
The backup files themselves are actually the service name followed by a .conf extension; however, the data in the configuration files are just the output of a serveradmin settings of the service, such as what you would get from the following:
serveradmin settings afp > afp.conf
For running services, there’s also a .status file (personally, I’d prefer a .fullstatus file instead if I had my druthers). While all services are exported, and can be manually restored by flipping that > from the above command to a <, some services can also be restored using the services commandlet. To see a list of services that are backed up specifically and can be granularly installed as an option:
/usr/sbin/ServerBackup -cmd services
To restore:
/usr/sbin/ServerBackup -cmd restore -path /Volumes/VOLUMENAME/Backups.backupdb/HOSTNAME/SNAPSHOT -target /
To restore a specific service (for example, the iCal Server):
/usr/sbin/ServerBackup -cmd restoreService -path /Volumes/VOLUMENAME/Backups.backupdb/HOSTNAME/SNAPSHOT -target / -service
Currently, ServerBackup is not included in the daily, nightly or monthly periodic scripts and it does not back up actual data, just settings, so if you’re going to rely on it, you might need to automate server settings backups as needed. The ServerBackup command does a few pretty cool things. However, there is a lot more work needed to get it to be holistic. We’ve been working on scripts for similar tasks for a long time. For more information on that see sabackup.sourceforge.net (although we’re likely to relocate it to github soon). For more information on ServerBackup itself, see the help page (no man page as of yet):
/usr/sbin/serverbackup -help
To see what version that ServerBackup is using (not actually very helpful but can be used to programatically verify ServerBackup is using the latest version):
/usr/sbin/ServerBackup -cmd version
Supposedly there is a prefs command, but I have yet to actually get it to do anything:
/usr/sbin/ServerBackup -cmd prefs
Finally, if you are scripting this stuff, don’t forget quotes (as you might have a space in the hostname). Also, a quick sanity check to determine size and make sure there’s available capacity using the size command let, which only outputs the required space for a ServerBackup backup:
/usr/sbin/ServerBackup -cmd size
