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