What Can a Directory Do for You?

Understanding and Deploying LDAP Directory Services > 16. Backups and Disaster Recovery > Backup and Restore Procedures

<  BACK CONTINUE  >
153021169001182127177100019128036004029190136140232051053054012004127032231101107119160

Backup and Restore Procedures

Like 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:

  • Disk drive media or controller failure.   The magnetic media on which the directory data is stored can fail, resulting in corruption or total loss.

  • Software bugs .   The directory software or operating system may have a bug that corrupts the data in the database.

  • Erroneous applications.   Directory applications can go haywire, placing incorrect data in the directory or deleting directory entries that should not be deleted.

  • Operator error.   Files or directory entries and attributes can be inadvertently erased.

  • Theft.   Your directory server equipment and the data stored on it can be stolen.

  • Disasters.   These include fires, floods, and earthquakes, which can completely destroy all your equipment.

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 Techniques

Just 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:

  • File servers are usually much larger than directories; therefore, more data needs to be backed up. This means that it's usually feasible to back up your directory by copying it to an alternate disk, whereas file system backups generally require the use of higher-capacity backup media such as tape. However, very large directories, which may be many gigabytes in size , cannot be copied to an alternate disk.

  • Unlike file systems, directories are frequently replicated, so it's important to understand the implications of restoring a replica from a backup tape. In most cases, it's better to rebuild a damaged replica from its peer replicas than to restore it from a backup tape; the data in the peer replicas should be more up-to-date.

  • The tools provided to back up directories generally do not support incremental backup, in which only the data that has changed since the last backup is copied to tape. This may change in the future; but for now, directories are generally backed up as a unit.

  • The directory service may be spread across a number of individual servers. To back up the entire service, you must either back up all the servers individually or back up all the directory data from a central location.

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 Up

Although 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 Restore

Although 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 line
Figure 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 Together

Although 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 Backups

It'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 Backups

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



Understanding and Deploying LDAP Directory Services,  2002 New Riders Publishing
<  BACK CONTINUE  >

Index terms contained in this section

applications
         erroneous
                    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.



Understanding and Deploying LDAP Directory Services
Understanding and Deploying LDAP Directory Services (2nd Edition)
ISBN: 0672323168
EAN: 2147483647
Year: 1997
Pages: 245

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net