17.3. Identifying Useful Directory Server Features for Disaster Recovery

The hardest part of a recovery is not the hardware; it is getting a reliable copy of the data in the server. There are three Directory Server features that are excellent tools for preparing data copies for disaster recovery:
  • Multi-master replication, chaining, backing up databases, and monitoring the server with a named pipe script.
  • Chaining
  • Backing up databases regularly
Additionally, monitoring the server with a named pipe script and with other Directory Server performance counters can be effective at catching and quickly responding to specific, critical events.

17.3.1. Multi-Master Replication for Disaster Recovery

Multi-master replication is the best defense against losing a single server and, possibly, even an entire office or department. While a small number of servers are data masters, multiple servers all hold the same data — potentially dozens of masters and hubs in a single replication environment. This keeps information accessible to clients even if multiple servers go offline.
Replication can be used to copy over data to servers and bring replacements online more quickly.


To protect against data corruption being propagated through replication, schedule a lag in replication to a backup server or to another server cluster. This way, replication can be stopped before the corrupt data are replicated over to the backup site.
Replication configuration also allows write operations to be referred to failover servers if the primary supplier is inaccessible. This means that write operations can proceed as normal from the client perspective, even when servers go offline.

Example 17.1. Scenarios for Multi-Master Replication

Replication is a versatile tool for disaster recovery in several scenarios:
  • For a single server failure, all of the data stored on that instance is both accessible and retrievable from other servers.
  • For the loss of an entire office or colocation facility, servers can be mirrored at an entirely different physical location (which is aided by Directory Server's wide area replication performance). With minimal effort, traffic can be redirected to the replicated site without having to bring new servers online.
Configuring replication is covered in Chapter 11, Managing Replication.

17.3.2. Chaining Databases for Disaster Recovery

Chaining is a configuration where a client sends a request to one server and it automatically forwards that request to another server to process. There can be multiple servers configured in the database link (or chain) to allow for automatic failover if one server is not available.

Example 17.2. Scenarios for Chaining

When chaining is combined with a list of failover servers, client traffic can be automatically redirected from a single server (or even group of servers) when they are offline. This does not help in recovery, but it helps manage the transition from primary to backup servers.

17.3.3. Backing up Directory Data for Disaster Recovery

The most useful tool for disaster recovery is to do frequent backups of a directory instance. Archives can be stored on physical media, at different locations than the primary data center or on-site at a cold backup location. Because both backup and restore operations can be done through either shell or perl scripts (such as db2bak.pl) backups can be automated to run regularly through simple cron jobs.
0 7 * * 1 /usr/lib[64]/dirsrv/slapd-example/db2bak.pl


The db2bak.pl Perl script backs up the directory data without having to stop the server first.
Backing up both directory databases and the directory configuration (dse.ldif file) are covered in Section 4.3, “Backing up and Restoring Data”.

17.3.4. Using a Named Pipe Script for Disaster Recovery

Named pipe scripts can be used to do two very good things: identify specific error messages and work with plug-ins or other scripts to respond to events. For certain kinds of failures and recoveries, this could be used to essentially automate a response, such as rerouting client traffic or bringing a virtual machine online.
Using named pipe scripts is described in Section 15.5, “Replacing Log Files with a Named Pipe”.