22.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:
  • Backing up databases and verifying the backups regularly
  • Multi-master replication, chaining, backing up databases, and monitoring the server with a named pipe script
  • Chaining
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.

22.3.1. 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 cron jobs. For example:
0 7 * * 1 /usr/sbin/db2bak.pl -Z instance_name
The db2bak.pl Perl script backs up the directory data without having to stop the server first.

Note

Red Hat recommends to back up the data on all servers in a multi-master replication environment.
Backing up both directory databases and the directory configuration (dse.ldif file) are covered in Section 6.3, “Backing up and Restoring Data”.

22.3.2. Multi-Master Replication for High-availability

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.

Note

To protect against data corruption being propagated through replication, frequently back up the database.
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 22.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 15, Managing Replication.

22.3.3. Chaining Databases for High-availability

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