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-supplier 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.
Backups can be automated to run regularly through cron jobs. For example, to create a backup of the
ldap://server.example.com instance daily at 22:00 (10pm):
0 22 * * 1 /usr/sbin/dsconf -D "cn=Directory Manager" ldap://server.example.com backup create
The
dsconf backup create command 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-supplier replication environment.
Backing up both directory databases and the directory configuration (
dse.ldif file) are covered in Section 6.3, “Backing up Directory Server”.
22.3.2. Multi-Supplier Replication for High-availability
Multi-supplier 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 suppliers, multiple servers all hold the same data — potentially dozens of suppliers 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-Supplier 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.
Chaining databases is covered in Section 2.3, “Creating and Maintaining Database Links”.
