I find that I don't recall exactly what I did when I originally asked this question - I think I may have ended up recreating the database (as in painfully by hand.) Anyway, two years on it happened again (and exactly the same start condition - shutdown did not shutdown when time machine had been "stopping" for days without stopping, or backing up, so the machine had to be powered off.)
Suggestions in the wild seem to be split between 10.6 and 10.7 commands even when they say lion server, or perhaps there are early and late 10.7 command changes; I certainly don't recall precisely. The answer I linked to in a comment above (How to fix failing Open Directory (database "cn=authdata" cannot be opened, err 12) after hang) seemed helpful, but the problem recurred within a few hours at most - and I actually had to run what by the answer's lights would be both 10.6 and 10.7 commands for even that to work.
So, on my Lion system (10.7.5) running Server.app 10.7.5(1.5.0), I'd have to do:
$ sudo launchctl unload /System/Library/LaunchDaemons/org.openldap.slapd.plist
$ sudo db_recover -h /var/db/openldap/authdata/ # Mac OS X 10.7
$ sudo db_recover -h /var/db/openldap/openldap-data/ # Mac OS X 10.6 (this one too, even on 10.7)
$ sudo launchctl load /System/Library/LaunchDaemons/org.openldap.slapd.plist
Rebooting or not seemed to make little difference. It would work for a relatively short time, then crap out again. The users were restive, the sysadmin was sleep-deprived and grumpy.
Eventually I found a procedure that once again had to be somewhat modified on a site I'll try to link to again, as a comment on an answer similar to the above process. As modified for my system...After doing the above repairs (you can skip the load step above)
1) sudo to root
sudo -i
2) shutdown LDAP (if you started it again)
launchctl unload /System/Library/LaunchDaemons/org.openldap.slapd.plist
3) dump a copy of the Open Directory database to an LDIF format text file
mkdir /var/root/opendirectory
cd /var/root/opendirectory
slapcat -l dir.ldif
If you don't do the repairs (or I suppose, if they don't work) the .ldif file will be empty - so check that it seems reasonable, and if not, start digging into backups.
4) move the old (corrupt) database files out of the way (or remove them).
cd /var/db/openldap/openldap-data
mkdir SAVE
mv *.bdb SAVE/
be sure you don’t move, rename or delete the file named DB_CONFIG. It’s needed.
5) recreate the database from the LDIF format file
cd /var/root/opendirectory
slapadd -l dir.ldif
slapindex
You will see some harmless warnings during slapadd. Ignore them.
Restart LDAP
launchctl load /System/Library/LaunchDaemons/org.openldap.slapd.plist
And at this point you might just as well reboot, too. Comment by "Ranj" on this page (with "service" commands that don't work for me) http://www.prestonlee.com/2009/07/08/recovering-a-corrupt-openldap-database-on-osx-server/
I won't swear that it's cured, because I thought that I had it cured two days ago and I was wrong, but it's run for 12 hours without screwing up totally, which is an improvement on where it's been since 2-1/2 days ago.
I also twigged upon an annoying (possibly related, who knows exactly what upsets the thing) issue relating to accounts created with workgroup manager rather than with server.app - they have an incorrect entry (untitled_1 rather than the user's shortname) in AltSecurityIdentities. I tried the fix as automated by this script https://github.com/arekdreyer/Lion-Server/blob/master/FixAltSecurityIdentities.sh and also by hand as described in several sites (either via GUI or by deconstructing the command line from the linked script) and it would fail every time I went to write. Once I had done the above fix to rebuild the databases I could actually re-write the incorrect data. Evidently the "cure" is to create accounts only with Server.app (but if you have this problem, you can't, until after you fix them...)
Finally, I am reminded by this joyful experience to spit out a
slapcat -l LDAPBackup<date>.ldif
on a more regular basis to make the recovery process less agonizing (as well as actually putting "what I did when this thing happened" in here as an aswer in case it happens again - or to someone else.)
Meanwhile, this whole business has also helped to crystallize the feeling that MacOS Server went to heck in a handbasket after 10.6, so given that the only thing this machine really does is file service, I'm probably going to replace it with a Nas4Free box, or perhaps two boxes in HAST configuration. I'm somehow less than interested in what delights 10.11 brings to the utter mess that is Server.app (IMHO at this point in this week) and I cannot begin to say how thrilled I'm not that upgrading to anything but 10.11 is a non-option in the days of "all software comes only from the app store, and you can't get any version you like, only the bleeding edge ones."
