Looks like no one’s replied in a while. To start the conversation again, simply ask a new question.

Backing up open directory on Mountain Lion

Hello all,


I've installed 10.8 Server and I am once again a bit concerned on the available features... While the features of 10.8 are a bit better than 10.7, I believe that they are far from those of 10.6. (Anyway, that's another story...)


My question has to do with the Server Admin tools, which don't seem to be available for 10.8 (and might never be from what I read...):


If I were to need to backup my Open Directory (LDAP) database, how should I proceed? With Server Admin, this is a simple task. And God knows that it saved my a** a few times in the past! Must I use a command-line task, or is there a tool somewhere to do this?


Thanks for anyone's insight!

OS X Mountain Lion

Posted on Jul 26, 2012 4:15 PM

Reply
22 replies

Jul 27, 2012 5:18 AM in response to Blaidd Drwg

Hi Blaidd,


Thanks for your answer.


I'm used to 10.6 Server, and in that version, you counldn't count on TM to do an correct backup job for a server environment. Actually, Apple documented how to back up iCal, Address book, etc. using scripts (ditto and such) in their great user manuals.


I know TM is good for a snapshot in time, but for system files such as OD, I wouldn't count on it. Unless of course there's a new feature in 10.8 where TM could restore complexe system files such as OD relatively easily, but I would doubt it.


What this seems to sum up to (and insight from some users would be nice) is that for a SMB environment, 10.6 still remains the best solution our there and that the upgrade to 10.8 would be a relatively high risk in terms of system administration. Is this a correct statement? I am indeed currently managing a 100% Apple SMB environment (25-30 users) using 10.6 and I do need all the administrative features offered by that version, either OD administration tools, system logs, flexibility in file systems, etc. Things that have disappeared in 10.7 and seems to be a bit back in 10.8 Server, but far from 10.6 Server.


Thanks.

Aug 20, 2012 8:48 AM in response to Blaidd Drwg

Hi all,


Actually, I believe that I found my answer with the "slapconfig" command. I have not tried it in production, but "sudo slapconfig -backupdb" is supposed to do the trick, according to the man page of slapconfig.


Does anyone have experience with this method, and is there any DOS and DONTS?


For starters, I would encrypt the backup file which it probably doesn't do by default. Any other insights?


Thanks!

Sep 1, 2012 6:34 PM in response to °Bernz°

There is an opendirectorybackup script at:


/Applications/Server.app/Contents/ServerRoot/usr/libexec/server_backup/opendirec torybackup.


It will save an OD archive using slapconfig in /var/backups. I am not sure if this is supposed to run automatically with Time Machine, but if you manually load this launchd job, it will run daily:


/Applications/Server.app/Contents/ServerRoot/System/Library/LaunchDaemons/com.ap ple.opendirectorybackup.plist.


The OD archive in /var/backups is only accessible by root, but it will not require a password.

Oct 22, 2012 9:57 AM in response to Guru Evi

I would caution you heavily against doing this unless you have disabled backup of the System folder in time machine.


Serverbackup drops it's backups in .ServerBackup in the root of the system drive (which then gets picked up by TM, which is actually pretty great). However it does need to be scheduled to run using chron or it will not do anything.


This may or may not be what's called when time machine backs up open directory, but I've had multiple cases in multiple environments (all documented by apple) where because of one reason or another the time machine backup actually trashes OD completely.


Sr level engineers recommended strongly to me that the only sure fire way to backup OD was to script it and exclude it from time machine.


I'm still not settled on how I want to standardize this in my environments, given some discussions I've had with apple server support about restoring those backups. I don't know if they were just being lazy, but they all really want you to just roll your server back using time machine...................which is the opposite of what they recommend in config....very conflicting.

Oct 22, 2012 3:34 PM in response to °Bernz°

°Bernz° wrote:


sudo slapconfig -backupdb

Does anyone have experience with this method, and is there any DOS and DONTS?


Apple support told me to use this to backup and restore Open Directory. It worked fine. You can protect the backup with a password. I am now tempted to make a daily backup this way ;-)


I did a restore using time machine some time ago and that did not work out very well as it seemd that it had restored a very old version of the postgress database. So calendars, wiki, etc. were back to months before. I do not know what caused this, but since then I do not trust time machine backups very much for os x server.

Nov 9, 2012 3:02 PM in response to NA_Joey

Off course, you can always use Perl for this. I think I modified this back in the day from someone else (don't have any credits, sorry). This has been taking backups for well over a decade. I think I just spotted a bug too since it's still using +1900 instead of +2000.


After this you should sleep a couple of seconds/minutes while the system is backing up before your file appears if you want to then copy this file to a backup system.


#!/usr/bin/perl -w



use strict;



my $archive_password = 'backuppassword';

my $archive_path = '/private/var/root/odbackup/';



my $max_keep_time = 1; # MONTHS TO KEEP ARCHIVES AROUND



my @date = localtime();

my $year = $date[5] + 1900;

my $month = sprintf("%.2d",$date[4] + 1);

my $day = sprintf("%.2d",$date[3]);



my $filename = $year.$month.$day;

my $archive_file = $archive_path.$filename;



print "Archiving to $archive_file...\n";


if (open(CMD,"|/usr/sbin/serveradmin command")) {

print CMD "dirserv:backupArchiveParams:archivePassword = $archive_password\n";

print CMD "dirserv:backupArchiveParams:archivePath = $archive_file\n";

print CMD "dirserv:command = backupArchive\n";

close(CMD);

print "Archive successful.\n";

} else {

print "Error: $!\n";

exit;

}



$month -= $max_keep_time;

if ($month < 1) {

$month = 12;

$year--;

}



my $expire_date = sprintf("%.4d%.2d%.2d",$year,$month,$day);



print "Cleaning up old archives...\n";



if (opendir(DIR,$archive_path)) {

while (my $file = readdir(DIR)) {

chomp($file);

next unless ($file =~ /^\d{8}\.sparseimage$/i);

my $file_date = $file;

$file_date =~ s/[^0-9]//g;

if ($file_date < $expire_date) {

print "Removing ".$archive_path.$file."\n";

unlink($archive_path.$file);

}

}

print "Cleanup successful.\n";

} else {

print "Error: $!\n";

}



exit;

Mar 15, 2013 2:08 PM in response to °Bernz°

Short answer:

While it might not be suitable for everyone, a solution that has worked quite well for me is to just periodically make disk images of the server. Not as easy to automate, but much more reliable when it comes to restoring a dead OD server. Plus, it backs up user passwords this way, whereas just backing up the ldap database does not.


Long winded (detailed) answer:

Unfortunately, Apple doesn't seem to think that we need tools to fix broken directory services, because the company seems to live in a delusional bubble where nothing they create ever breaks or behaves unexpectedly. Even Snow Leopard Server lacked the proper toolkit to ensure that OpenDirectory is "Enterprise Grade" in my opinion. While Server Admin offered a built-in Backup and Restore feature for Open Directory, it was an illusion of safety, because account passwords were not included. So yes, you could restore your directory nodes, (such as group memberships and policy settings) but it didn't do any good since the user accounts were ruined.


I have been fortunate enough to be in situations where I've had to rebuild directory services from scratch on several occasions because backup and restore wasn't good enough for one reason or another. So over the years, I've come up with my own "best practice" for setting up Apple Open Directory, because I like to minimize downtime in the event of a disaster.


1, If your situation is a single campus with no remote locations, then you should forget about replicas altogether. They were awesome in Novell's NDS, barely tolerable in Microsoft's AD, but absolutely dismal in Apple's OD. In most cases with Open Directory, they provide no actual fault tolerance or any sort of automatic load balancing. All they are good for is corrupting your LDAP database when they fall out of sync. So getting rid of these actually reduces the chance you will actually need to restore the database in the first place. (Obviously if you do have remote offices, you will still probably need at least one replica. Make sure the remote clients all point to that replica and NOT your primary master. Better yet, switch to AD for this scenario.)


2, If not already done, set up the OD environment and implement it.


3, Now that your OD is live and users and computers are all bound the way you want it, you are ready for making the backup. Reboot the server in "Target Disk Mode" and connect a Thunderbolt or FireWire cable to another system. Alternatively, you can also "Option Boot" the server to an external FireWire disk that has the same or newer copy of OS X installed and plenty of free space to hold your backup image. Yet another alternative would be to use a custom NetBoot image that has a server volume available for writing the backup to.


4, Use Disk Utility to create a "Disk Image from Folder", selecting the OD Server's Macintosh HD (or whatever it's called) as the folder. If your OD server is dedicated to the purpose and only has the OS installed and OD configured, the process will take about 30-45 minutes or so to complete. (Despite the gargantuan size of problems it can create, the OD database itself is actually very small.)


5, Once that's done, return the OD server to it's normal operating condition and boot it up as you would any other day. Meanwhile, you can tell Disk Utility to "Scan the Image for Restore", which basically reorders the blocks in the image file you just created so that it can quickly be reapplied to any drive big enough to hold it. (If/when that time comes, you can simply use Disk Utility to restore the image. Assuming you did everything correctly, the image will restore using block-level copy and will complete in about 10 minutes or less.)


The drawbacks to my approach are fairly obvious. Primarily, it's just the downtime and manual labor involved in creating the backup. So if your database changes dramtically on a weekly basis, then this may not be the right approach for you. In my experience, however, aside from replacing computers, adding new policies, or users changing passwords, the database hardly ever changes. At least not to a degree that will matter much in a disaster recovery situation. But taking an hour every other month to make a backup is worth it if you seriously rely on your OD. I usually set things up so that I can do all of this remotely after hours. (Which is a bit trickier, because having your OD server down often disables many, if not all, of your network services, too.)


For me, the benefits to my approach outweigh the drawbacks. In the event my OD server has a melt-down or gets corrupted for whatever reason, I can usually have everything back up and running tip-top shape in less than 20 minutes. Even when I had to restore an OD server from a backup image that was over a year old, I was able to get the company back up and running in less time than it would have taken for me to read the slapconfig man page.


So while this may not be an approach that Apple will recommend, real-world experience has led me to this method. If you can beat my maximum down-time of 20 minutes and have a fully working directory service complete with user passwords and all dependent systems running normally as if nothing happened, then please share. Until that day, I'll consider my solution to be the true "best practice".

Mar 17, 2013 12:16 PM in response to Guru Evi

@Guri Evi:


Interesting. In contrast, my personal dealings with Apple support on this matter have always ended up with it not being possible to keep the passwords intact using the built-in backup feature of Server Admin (GUI, CLI, or otherwise.)


Despite having "archivePassword = backuppassword" included, from what I understand about Open Directory is that the actual user passwords are never stored in the LDAP database to begin with. (Specifically designed this way for security purposes, as Kerberos and "Password Server" handle this aspect of the system instead.) So regardless of whether or not you include this parameter, it would not end up restoring user passwords.


You can, according to the OD Administrator's Guide, recover the schema customizations, managed policies, etc from this backup but you are still required to reset all of the user passwords in doing so. I've also found that going this route usually ends up opening a can of worms, especially with mobile accounts and screen savers/locked screens.


The perl script seems useful with auto rotating of the archives and all, and I will have to give it a test run. If it can do as you say then I'm happier than a bear with a honeypot. (But then maybe also a little upset with Apple's support on the matter.) How do you restore from this backup? Can you share an example?

Mar 17, 2013 6:41 PM in response to quickthyme

Hi,


The Perl script basically talks to serveradmin which is the CLI equivalent to the GUI interface. So it does the exact same thing and I have always restored the disk images it creates through the GUI (with the correct password).


I have done migrations from one hardware platform (PPC) to the other (x86) using this backup system even tested 10.8 with it and it will always restore both the LDAP and the Kerberos system. Open the disk image, it should have the certificates, a KerberosKDC and krb5backup besides the LDIF for OpenLDAP.


If you however do a simple file backup/restore of the LDAP/Kerberos system (unless it's bare metal restore where you restore a full disk image) it will not be able to do passwords because besides the passwords you also need the certificates who are locked away in Keychain and I've never been able to do a succesful System Keychain restore on another system.

Mar 18, 2013 9:28 AM in response to Guru Evi

Ok, I tested the script on a live OD server and compared the resulting sparseimage with one that was created using the Server Admin GUI. (Using Lion Server)


Interestingly enough, I noticed that the backup file generated from the CLI (via Guru Evi's perl script) includes a couple of extra files that were not included in the Server Admin GUI backup. In particular, the additional files appear to be related to Kerberos.


Here's a screen shot showing the difference between the two:

User uploaded file


Most notably is KerberosKDC.plist and krb5backup.tar.gz.


I have not yet tested restoring this file, as I will need to find a Mac that I can use as a test OD server, but so far looks like Guru Evi > Apple Support Engineers.


Thanks! If this proves true, then most of my OD nightmares are over. Why won't Apple reveal this information in the Administrator's Guide? And why would the Enterprise Support team there not share the superior CLI method of creating the OD backup??

Backing up open directory on Mountain Lion

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple ID.