Directory-Specific Issues in Disaster Recovery

A cold-site disaster recovery plan for a directory is much like that for the other critical data repositories you might use. The recovery procedures are, for the most part, like recovering a database. If you use a cold site, directory server software must be installed on the replacement machines, and backup tapes containing the directory data must be restored.

With hot-site disaster recovery, however, directory replication offers unique opportunities to improve recovery time significantly. By using replication to maintain the hot standby servers, you can make your directory available much more quickly. For example, with hot standby replicas no recovery at all is necessary; because the replicas are always updated, they are ready to take over at a moment's notice.

This does not mean, however, that it's impossible to lose transactions when replication is being used. A server at the primary site certainly could be destroyed before having a chance to transmit all its replication updates to its peers. Directories almost always use loosely consistent replication, as discussed in Chapter 11, Replication Design. To minimize data loss due to replication latency, configure your server to replicate changes immediately.

One issue that arises with replication is the reassignment of master servers. Directory server software that supports only single-master replication requires additional steps to recover from the destruction of the master server. In such a case, another server must be configured to be the updatable master and to supply updates to the backup servers at the alternate site. The recovery plan must be modified to include time for these steps if necessary.

Another issue to consider is the distributed nature of directories. Recall that a single directory tree can be spread across multiple servers, each holding a portion of the tree. To provide a backup set of servers, at either a cold or a hot site, you need to either provide equivalent computing power (number of servers, speed of CPUs, and so on) or make a conscious decision that the standby site will be limited in some fashion.

For example, at your primary site your directory may be divided into three partitions, each residing on a separate server. The backup site, however, might have all three partitions on the same server. Although the backup site would have less capacity than the primary site, you might choose this approach to limit costs. Reduced capacity may be perfectly acceptable anyway, especially if you can reduce the load on the directory by shutting down less important directory-enabled applications while the backup site is in operation. However, the backup site must meet at least some minimum performance requirements for it to be useful at all.

You can, of course, install additional replicas at the backup site after disaster recovery commences. Doing so would reduce the amount of replication update traffic that must flow from your primary site to your backup site under normal conditions. For example, if your primary site consists of three directory partitions replicated three times each (a total of nine servers), a complete hot standby site would also have nine servers. Maintaining the backup replicas might significantly increase the workload of the servers at the primary site, however. If instead you maintained a single server at the hot site that held all three partitions, replication update traffic to the remote site would be reduced significantly. Additional replicas could be rebuilt from the single server at the hot site in the event of a disaster at the primary site. This might be considered a hybrid hot/cold site approach: The online replica at the remote site is hot, and the other servers are cold, put into service only if a disaster occurs (see Figure 17.5).

Figure 17.5. A Hybrid Hot/Cold Strategy