Previous 1 2 Next 22 Replies Latest reply: Dec 11, 2014 11:21 AM by Phil Brown2
°Bernz° Level 1 Level 1

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
  • Blaidd Drwg Level 1 Level 1

    You can simply use Time Machine.

  • °Bernz° Level 1 Level 1

    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.



  • Guru Evi Level 1 Level 1

    TM on Server (10.7) does backup databases such as Postgres and OD. It is described somewhere but it basically runs a backup script before running TM backup.


    You can use serveradmin (from command line) to script dirserv which is now been hidden in /Applications/

  • Blaidd Drwg Level 1 Level 1

    The ServerBackup process does archive OD. See the additional information section of this article:


  • °Bernz° Level 1 Level 1

    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?



  • Claudio Sanchez1 Level 1 Level 1

    There is an opendirectorybackup script at:


    /Applications/ 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/ ple.opendirectorybackup.plist.


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

  • THNC Level 1 Level 1

    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.

  • Peter Jurg2 Level 1 Level 1

    °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. 

  • NA_Joey Level 1 Level 1

    Has anybody wrote a script for cron or launchd for mac let to  automate the task ? or have one that could use with Lingon 3



  • Guru Evi Level 1 Level 1

    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";


      print "Archive successful.\n";

    } else {

      print "Error: $!\n";





    $month -= $max_keep_time;

    if ($month < 1) {

      $month = 12;  





    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)) {


        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";




      print "Cleanup successful.\n";

    } else {

      print "Error: $!\n";





  • quickthyme Level 1 Level 1

    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".

  • Guru Evi Level 1 Level 1



    See the above solution which I posted. It's basically using serveradmin to run the backup commands. I can restore a server in minutes with this including passwords and custom schema.

  • quickthyme Level 1 Level 1

    @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?

  • Guru Evi Level 1 Level 1



    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.

Previous 1 2 Next