Understanding and Deploying LDAP Directory Services > 16. Backups and Disaster Recovery > Backup and Restore Procedures |
Backup and Restore ProceduresLike file systems and databases, a directory's data is stored on disk drives . This data can become damaged for a number of reasons, including the following:
If one of these unfortunate events happens to your directory, you need some way to recover. You can accomplish this by restoring a backup of your directory data to the affected servers. There are two ways you can back up your directory data: by using traditional backup techniques such as tape backups and disk mirroring, or by using directory replication. Each approach has advantages, and a comprehensive backup approach that aims to provide high availability benefits from using both approaches simultaneously . We'll discuss the advantages of each approach throughout this chapter. Backing Up and Restoring Directory Data Using Traditional TechniquesJust like user files stored on a file server, your directory data should be backed up to some sort of medium such as magnetic tape. You can also back up to an alternate disk drive that is local or over the network. The backups can be used to restore the data in the event that data damage or loss occurs. However, backing up a directory is different from backing up a file system in several important ways:
Your actual backup procedure depends on the particular directory server software you use. Backing up Novell Directory Services (NDS) server data, for example, is accomplished using an SMS-compliant backup utility in conjunction with NetWare Loadable Modules (NLMs) on each NDS server. The NDS backup utility reads the directory contents over the network and copies the data to a backup device. Backing up Netscape's Directory Server is accomplished by running the ns-slapd db2archive utility, which creates copies of the database files in a backup directory. The contents of this directory can then be copied to tape, if desired. Both NDS and Netscape Directory Server backups can be performed while servers are online and being updated. Other directory software may require that you shut down the server or place it in read-only mode to obtain a consistent backup. This is undesirable, of course, because it introduces downtime. Consult the directory server vendor's documentation for details. It is also possible to back up a directory using mirrored disks. In a mirrored system, any writes to the disk are performed on a primary disk or disk array, as well as a mirror , or second copy of the data. In the event that the primary disk or disk array fails, the mirror can be used as a backup. Note Even if you use mirroring to back up your directory data, you should also use backup media that can be transported offsite. A backup of your critical directory data isn't much good if it goes up in flames with all of your servers! Another way to back up your directory data is to read all the entries using the LDAP protocol and write them to disk or tape. For example, you can use the Netscape ldapsearch command-line utility to read all directory entries underneath dc=airius, dc=com in the following command: ldapsearch -h directory.airius.com -p 389 -D "cn=Directory Manager" -w secret -s sub -b "dc=airius, dc=com" "(objectclass=*)" Note This command should all be typed on a single line; it doesn't appear on one line in this book because of page size constraints. The example ldapsearch command connects to the LDAP server running on port 389 on host directory.airius.com , authenticates as cn=Directory Manager with password secret , and performs a subtree search rooted at dc=airius, dc=com . (These parameters should be tailored for your environment.) The filter, (objectclass=*) , matches any entry. Assuming that cn=Directory Manager has read privileges on all entries within the subtree dc=airius,dc=com , the server will respond by sending all entries, and the client will generate LDIF output that can be redirected to a file or tape. There are some caveats with this approach. First, the ldapsearch command as given would not return any operational attributes such as modifiersname and modifytimestamp . These attributes must be explicitly mentioned on the command line. This can be accomplished by adding to the command line as follows : ldapsearch -h directory.airius.com -p 389 -D "cn=Directory Manager" -w secret -s sub -b "dc=airius, dc=com" "(objectclass=*)" "*" modifiersname modifytimestamp creatorsname createtimestamp The additional arguments at the end of the command line specify that all user attributes are to be returned (as called for by the * ), along with four operational attributes ( modifiersname , modifytimestamp , creatorsname , createtimestamp ). The second caveat is that the command-line utility may return entries that do not reside on the specified server. This can happen if your directory is distributed across multiple servers using chaining or referrals (as discussed in Chapter 9, "Topology Design" ). Receiving these entries may be what you want, of course, if your aim is to copy all your directory entries across your whole distributed directory. If this is not what you want, you can use the -R command-line flag to ldapsearch to instruct it not to follow referrals. If your directory uses chaining, however, there is no way to ask for entries that are local to only one server. A third caveat is that if the directory is modified while the backup is taken, certain inconsistencies may result. For example, if a group references members, those members may not appear in the backup snapshot if they are added while the directory was being backed up. The final caveat is that data backed up in this manner is likely to be incomplete. There may be quite a bit of additional information stored in the directory to support its operation, such as superior and subordinate knowledge. The manageDSAIT control, available on LDAPv3 “compliant servers, can be used to access this type of data (this control is discussed in Chapter 3, "An Introduction to LDAP" ). The bottom line is that backing up data over LDAP may not produce a backup that can be used to recover from complete data loss. However, this type of backup is quite useful in protecting against problems that arise as a result of erroneous information in the directory. Other Things to Back UpAlthough backing up your critical directory data is important, it's likely that there is additional information you should back up. For example, you should back up your configuration files for your directory server when you back up your directory data; re-creating them from scratch would be a time-consuming experience. Additionally, your directory schema configuration and access control information may reside in separate files or databases; be sure these are backed up as well. Consult your directory server documentation to learn about other configuration files and data you should back up. Note When maintaining a complex set of configuration files like those in most directory server software, it's beneficial to keep a history of changes made to them. This allows you to revert to an older version of the configuration if an error is made. One way of accomplishing this is to use a revision control system such as SCCS, RCS, or CVS (all of these are available on UNIX platforms). Revision control systems allow you to retrieve any previous version of a file's contents and determine who made a particular change. Such tools can also help protect against erroneous configuration changes. Backing Up Netscape Directory Server Configuration Data Netscape Directory Server stores all of its configuration data within a single directory named config underneath the server instance directory. For example, if the directory server is instal- led on a UNIX host in a server root directory named /usr/netscape , and the server instance name is directory , configuration files for the server are stored in the directory / usr/netscape/slapd-directory/config . Backing up this configuration data can be accomplished by copying all the files in that directory to a backup location such as a remote disk drive or a tape. You can use the UNIX tar (tape archive) utility to place all the configuration files into a single archive. For example, if you wanted to back up all the configuration files and place the tar archive in the directory /n/backups , you could use the command tar c /n/backups/slapd.config.backup.tar/usr/netscape/slapd-directory/config . Using Replication for Backup and RestoreAlthough traditional backup techniques can protect you against many types of problems, they have one major drawback: Restoration of data is time- consuming. Copying data from the backup media to the server may take many minutes or even hours for a large directory. However, if you use replication as your primary means of providing redundancy and fault-tolerance, you can avoid the costly downtime that would be required for the restoration phase. Because replicas are online copies of your critical directory data, no delay is incurred while data is being restored from backup media. If a server fails, you can simply remove it from the set of replicas and repair the failure. After the server is repaired, you can bring it back online and re-establish it as a replica. Users will generally be unaware of the problem ”as long as there is sufficient capacity across the remaining replicas to handle the client load. Using replication for backup and restoration has another advantage: Directory data are usually more up-to-date on replicas than on backup tapes. Of course, most directories support loose replica consistency; that is, it's possible for changes to be held on a replica for some time before being propagated to other replicas. Thus, there is no absolute guarantee that all replicas are completely in sync at any given time. Directory server software that supports multi-master replication makes this backup procedure simple. Because any server can accept updates in such a configuration, there is no loss of functionality when a server is missing from the replica set. The process of repairing a failed server in a multi-master environment is depicted in Figure 16.1. In the situation depicted, replica 3 experiences a failure of its disk drive. The server is removed from the set of replicas, and the disk drive is replaced . The replica is added to the set of replicas as soon as its directory data is reinitialized from one of the other replicas. Figure 16.1 Multi-master replication provides protection against server failure.If your directory server software supports only single-master replication, the backup process can become a bit more complicated. In single-master replication, only the master server can be updated; all other servers are read-only copies. If the master server fails, no updates can be processed by the directory until the master is repaired and brought back online (see Figure 16.2), or until a different server is designated as the master (see Figure 16.3). Figure 16.2 Single-master replication: A master server fails, is repaired, and is brought back on lineFigure 16.3 A master server fails, and a slave server is converted into a master.Converting a slave server to a master can be a complicated process. At the very least, it involves configuring the new master to send replication updates to all the consumer servers covered by the failed master (excluding the new master). Additionally, it may be necessary to update state information stored in each replica, such as the last update number received from the master, to reflect the update numbers on the new master. Because this can be a complicated procedure, be sure you understand the process thoroughly. For more information, consult your directory server software manual. Using Replication and Traditional Backup Techniques TogetherAlthough replication provides you with redundancy and high availability in the event of a single server failure, it cannot protect you from incorrect data being placed in your directory. For example, if an automatic data update process begins erroneously deleting entries from your directory, replication unfortunately ensures that these incorrect updates end up on all your replicas! To protect yourself from this type of problem, you should perform periodic backups of directory data to media such as magnetic tape. A hybrid approach that uses both backup methods is shown in Figure 16.4. One of the replicas is equipped with a tape backup unit, which is used to back up the directory contents periodically. Figure 16.4 A hybrid approach to backup, incorporating both replication and traditional backup techniques.Safeguarding Your BackupsIt's important to keep your backup media in a safe place. This means protecting them from damaging environments such as extreme temperatures and magnetic fields. You should also keep copies of your backups offsite. In the event of a disaster such as a fire, the offsite backups can be used to restore data to replacement servers. You can outsource the transportation and storage of offsite backups to reduce costs. We'll discuss disasters and disaster recovery in detail later in this chapter. Another important aspect of safeguarding your backups is the physical security of the backup media storage facility. No matter how good your privacy and security design, it is all for naught if someone can just stroll up to your cabinet holding the backup tapes and walk off with a copy of your sensitive directory data. Backups should be well-secured; this might mean placing backups in a locked, fireproof vault in an offsite facility and using a bonded courier service to transport the backups. Finally, consider storing your offsite backups in a location that is unlikely to be affected by a natual disaster that damages or destroys your main location. For example, an offsite backup storage facility 10 miles away may be adequate in the Midwestern United States, where the primary natural disaster is severe weather. In California, where the primary concern is earthquakes, it may be prudent to store offsite backups at a location in a region that is less active seismically. Verifying Your BackupsBacking up your critical directory data is very important. However, the act of backing up is futile if the backups can't be restored. You need to take steps to check the integrity of the backups you produce. At the very least, check that your backup media are readable and free of media errors. How you verify your backups depends on the server software you use. One option is to actually restore the backup onto a test server, start the server, and then verify that the contents of the server are correct. This may not always be practical, however. For example, the NDS backup copies data from the entire set of distributed NDS servers onto a single backup. Restoring the directory to a test server may be impractical because of the number of partitions in the directory; it may be difficult to fit them all onto a temporary server used for verification. If you run NDS, consult your backup software documentation for instructions on verifying backups. You should verify backups immediately after the backup completes. If the verification fails, the cause of the failure should be determined and fixed, and another backup should be performed immediately. You may also want to incorporate your backup process into your monitoring system so that you'll know if something goes wrong. You should be especially careful to fully verify your backups when you initially develop and deploy your backup procedure or change it in some significant way. Backup software, like any other software, can contain bugs. It's always better to discover this, and other flaws in your backup procedures, before you need to restore critical directory data from a bad backup.
|
Index terms contained in this sectionapplicationserroneous reasons for backups backups configuration files 2nd 3rd disk mirroring magnetic media 2nd 3rd 4th 5th 6th reading and writing all entries 2nd 3rd 4th 5th reasons for replication 2nd 3rd 4th 5th 6th combining with magnetic media security 2nd verifying 2nd 3rd bugs software reasons for backups configuration files backing up 2nd Netscape Directory Server controllers disk drive failures backing up converting slave servers to master servers data backups combining replication and magnetic media configuration files 2nd 3rd disk mirroring magnetic media 2nd 3rd 4th 5th 6th reading and writing all entries 2nd 3rd 4th 5th reasons for replication 2nd 3rd 4th 5th 6th security 2nd verifying 2nd 3rd disaster recovery backups combining replication and magnetic media configuration files 2nd 3rd disk mirroring magnetic media 2nd 3rd 4th 5th 6th reading and writing all entries 2nd 3rd 4th 5th reasons for replication 2nd 3rd 4th 5th 6th security 2nd verifying 2nd 3rd disk drives failures backing up disk mirroring backups erroneous applications reasons for backups errors user reasons for backups incremental backup support ldapsearch command-line utility backing up entries magnetic media backups 2nd combining with replication incremental backup support restoring replicas server size issues servers multiple manageDSAIT control master server converting from slave servers mirroring backups multimaster replication multiple servers backing up Netscape Directory Server backing up configuration files Novell Directory Services backing up ns-slapd db2archive utility backing up Netscape Directory Server replication backing up with combining with magnetic media data accuracy multimaster repairing failures single-master slave to master conversion backups restoring replicas restoring backups replicas safeguarding backups 2nd security safeguarding backups 2nd thefts reasons for backups servers backing up failures repairing replicas master converting from slave servers slave converting to master single master replication slave servers converting to master servers software bugs reasons for backups storage backups 2nd tape backups 2nd incremental backup support restoring replicas server size issues servers multiple servers theft reasons for backups users errors reasons for backups verifying backups 2nd 3rd |
2002, O'Reilly & Associates, Inc. |