Backup and Restore Tivoli Directory Server

Overview of backup and restore procedures for Tivoli Directory Server

By Siva Praturi

Tivoli Directory Server provides multiple methods for backing up and restoring directory server instance information. There are methods that back up the complete information for a directory server instance, and methods that back up only the data in the database. You can back up and restore Tivoli Directory Server using below options and they have their advantages and disadvantages.

• DB2 backup (db2 backup) and restore (db2 restore) commands
• Tivoli Directory Server backup (idsdbback) and restore (idsdbrestore) commands
• Tivoli Directory Server tools db2ldif and ldif2db.

Choosing an appropriate backup method is a very important decision in Tivoli Directory Server environments. In my view, it is always a safe side option to choose both automated LDIF export and database backups with LDIF export being stored on a DISK drive and database backup on TAPE device.

DB2 backup and restore commands

The db2 backup and db2 restore commands are provided by IBM DB2. The advantage to using these commands is performance and flexibility for specifying the location of the database files. The db2 restore command can be used to distribute the database across multiple disks or to simply move the database to another directory.

The disadvantage to the db2 backup and db2 restore commands is their complexity. Another disadvantage is the potential for incompatibility in backing up and restoring across platforms and across DB2 versions.

An important consideration when using db2 backup and db2 restore commands is the preservation of DB2 configuration parameters and system statistics optimizations in the backed-up database. The restored database has the same performance optimizations as the backed-up database.This is not the case with LDAP db2ldif, ldif2db, or bulkload.

idsdbback and idsdbrestore commands

The idsdbback and idsdbrestore commands are provided by Tivoli Directory Server to back up both the DB2 database and the directory server configuration. The advantage to using these commands is the backing up of the directory server configuration.

The other ways of backing up the directory server do not include the directory server configuration information. This information includes directory schema, configuration file and key stash file. Although it is possible to back these files up manually, the idsdbback andidsdbrestore commands make this task easier. However, it is important to note that idsdbback command can be used only when Tivoli Directory Server is not running.

The disadvantage to using the idsdbback and idsdbrestore commands is less flexibility in how the underlying DB2 restore is performed. For example, using the idsdbrestore command, the DB2 restore cannot be directed to distribute the database across multiple disks. Another disadvantage is the potential incompatibility in backing up the database on one platform (for example AIX) and restore on another platform (for example Windows).

db2ldif, ldif2db, and bulkload commands

The db2ldif and ldif2db commands are provided by Tivoli Directory Server to dump or restore the database to or from a file in Lightweight Directory Interchange Format (LDIF). The advantage to using these commands is portability, standardization and size. It is important to note that these tools do not preserve the DB2 configuration parameters and database optimizations parameters.

The output LDIF file can be used to restore a directory server on a different platform and possibly with some modification on a different directory server product, for example the Sun ONE Directory Server. The disk space requirement for the LDIF output from db2ldif is approximately 6.5 times less than the backed up database from db2 backup or idsdbback.

The disadvantage to using db2ldif and ldif2db is speed as compared to db2 backup and db2 restore. Because the db2 backup and restore commands are essentially a disk copy, they are the fastest alternative.

For restoring the database, the bulkload utility is many times faster than ldif2db command, yet is still much slower than db2 restore. Thebulkload utility takes approximately 12 times longer than a db2 restore. In order to restore a directory server using bulkload, the directory server must be empty. This is accomplished by restoring an empty database or by unconfiguring, then reconfiguring the directory server.

Choosing an appropriate backup method

What are the factors to consider in choosing a backup method?

The first choice in backup methods is between exporting data to LDIF and using a database backup. There are some advantages to exporting to LDIF:

• For directories with no more than a few hundred entries, it might be more time and space efficient to export the entries to LDIF as a backup, because there is extra overhead for a full database backup.
• The directory server can be running and accepting updates during the export to LDIF.
• LDIF is a portable format, so if you need to move data from an LDAP directory on Windows to one on AIX, using LDIF is the best approach.
• LDIF is also vendor neutral, so if you decide to move your data from some other vendor’s directory server to the Tivoli Directory Server, then exporting to LDIF is a good way to go. 

Now, if you are not moving data between directories and you have more than a few hundred entries, you would be better off doing a database backup. For large directories, it is much faster to do a database backup than to export all the data to LDIF. A database backup has these advantages:

• It is faster and more efficient for directories with thousands to millions of entries.
• It saves the database configuration settings, including those for the underlying tablespaces.
• DB2 provides the options to do either offline or online backups. It includes an option to do full backups or delta backups.
• Your saved backup images and the transaction logs allows for recovery right up to the last transaction completed prior to a disk crash. 

So, database backups are usually the best approach, but you still need to decide if online or offline backups will work best for you. Doing offline backups is the simplest approach. It requires less administrative activity, and if you can afford to stop a directory server long enough to do a periodic backup, then it is probably the best solution for you.  On the other hand, if you cannot afford to stop a directory server to take a backup, then online backups are the way to go. The extra administrative overhead when a database is configured for online backups is related to the accumulation of transaction logs that necessitates some management of them.