IBM Tivoli Directory Server, Version 6.3

Using DB2 backup and restore

Basic examples for both offline and online backup of the database are described in the following sections. The examples shown are for the AIX® operating system, and may need to be modified for other operating systems. These examples also incorporate name of the days in a week abbreviation in the naming of the backup locations.

Offline backup and offline restore procedures for Tivoli Directory Server database using DB2 backup and restore

Backing up the directory database:

  1. Determine a secure location to store the files to be used for backup and recovery, such as a backup machine, separate media, etc. In the examples listed, the /safeplace directory is used as a location to store files. The DB2® instance owner must have write permission for the /safeplace directory.
  2. Save Tivoli® Directory Server configuration and schema files in a secure location. These files need to be updated only if you change the topology, configuration parameters, or schema. In the examples, the Tivoli Directory Server instance and database are named ldapdb2. 
    cp /home/ldapdb2/idsslapd-ldapdb2/etc/* /safeplace/etc
  3. Make sure that ibmslapd is not running. 
    ibmslapd -I ldapdb2 -k
  4. Create a full database offline backup. You must run all DB2 commands as the DB2 instance owner. 
    db2 force applications all
db2 backup db ldapdb2 to /safeplace/sun-full-ldapdb2

Restoring the directory database on a different machine:

  1. If necessary, install Tivoli Directory Server.
  2. Configure a database, using the same information that was specified on the backup machine.
  3. Copy or ftp the configuration, schema, and backup image files from the backup machine to /safeplace on this machine.
  4. Copy the backed-up configuration and schema files to this machine. 
    cp /safeplace/etc/* /home/ldapdb2/idsslapd-ldapdb2/etc
  5. Restore the directory database. 
    db2 restore db ldapdb2 from /safeplace/sun-full-ldapdb2 replace existing
Note:
In some versions, DB2 supports cross-platform backup and restore operations and mixed version backup and restore operations. From a Tivoli Directory Server perspective, you cannot back up a database on one version of Tivoli Directory Server and then restore that database on another version of Tivoli Directory Server. It is advisable to use the same version of db2 backup and db2 restore for both DB2 operations.

DB2 online backup and offline restore procedures for Tivoli Directory Server

Setting up online backup for the directory database (without change log)
  1. Use a secure location to store files to be used for backup and recovery, such as a backup machine, separate media, etc. In the examples listed, the /safeplace directory is used as a location to store files. The DB2 instance owner must have write permission for the /safeplace directory. In the examples, the Tivoli Directory Server instance and database are named ldapdb2.
  2. Save Tivoli Directory Server configuration and schema files in the secure location. These files need to be updated only if you change the topology, configuration parameters, or schema. 
    cp /home/ldapdb2/idsslapd-ldapdb2/etc/* /safeplace/etc
  3. Make sure that ibmslapd is not running. 
    ibmslapd -I ldapdb2 -k
  4. For recovery purposes, log files should be kept on a different physical drive than the database. In this example, the /safeplace/db2logs-ldapdb2 directory is used as the secure location. You must run all DB2 commands as the DB2 instance owner. 
    db2 update db config for ldapdb2 using newlogpath /safeplace/db2logs-ldapdb2
  5. Update the directory server database for online backup support with log archiving on. 
    db2 update db config for ldapdb2 using logarchmeth1 logretain 
db2 force applications all
db2stop
db2start
  6. After archival logging is set, you must make a full offline backup. Create a full offline backup of database. 
    db2 backup db ldapdb2 to /safeplace/sun-full-ldapdb2
  7. Start the directory server instance. 
    ibmslapd -I ldapdb2
Creating full online backup for the directory database
  1. On a nightly basis (or more frequently if necessary), create full backup and copy log files from the log file path.
    Note:
    You can use an online backup image for recovery only if you have the logs that span the time during which the backup operation was running.
    db2 backup db ldapdb2 online to /safeplace/mon-ldapdb2
  2. Verify the log path. DB2 appends the node to the path specified. 
    db2 get db config for ldapdb2 | grep -i “Path to log files"
The following is an example of the information returned: 
Path to log files        = /safeplace/db2logs-ldapdb2/NODE0000/
Restoring the directory database
Suppose that a disk drive failed on Wednesday morning on the machine being used, since the /safeplace directory is used to back up the files and logs was not affected, it can be used for restore.

If a different machine is being used to restore the database, the /safeplace directory on the backed up machine must be set up on the new machine to a local /safeplace directory. This must include all backup directories being used, as well as the log files in the /safeplace/db2log-ldapdb2/NODE0000 directory.

  1. If necessary, install Tivoli Directory Server.
  2. Configure a database, using the same information that was specified on the backup machine.
  3. Copy or tar the configuration and schema files backed up previously. 
    cp  /safeplace/etc/*  /home/ldapdb2/idsslapd-ldapdb2/etc
  4. Restore the directory database from Tuesday. 
    db2 restore db ldapdb2 from /safeplace/tues-ldapdb2 taken 
                                  at <timestamp_of_backup>
    Note:
    The <timestamp_of_backup> option is only required if there are more than one backup image in the specified directory path.

    If you are restoring on a new machine, the following warning message is displayed:

    SQL2523W  Warning!  Restoring to an existing database that 
is different from the database on the backup image, but 
have matching names. The target database will be 
overwritten by the backup version. The Roll-forward 
recovery logs associated with the target database will be deleted.
Do you want to continue ? (y/n) y
DB20000I  The RESTORE DATABASE command completed successfully.
  5. Set the new database's log path to the same path that was used for the log files. If you are restoring on a new system, you must copy the log files from the old system to the new. 
    db2 update db config for ldapdb2 using 
               newlogpath /safeplace/db2logs-ldapdb2
  6. .Roll forward all logs located in the log directory, which include changes since the Tuesday night backup. 
    db2 rollforward db ldapdb2 to end of logs and stop
Note:
In this case, recovery requires only the last full backup image and the logs spanning the time since the backup was made.
Setting up incremental online backup for both the directory and change log database to be used for recovery
This section and the following sections are based on a backup strategy with a weekly schedule of doing full backups on Sundays, and then using incremental backups during the week.
Figure 22. Incremental cumulative and Delta backup
This figure illustrates incremental cumulative and delta backup
  1. Use a secure location to store files to be used for backup and recovery, such as a backup machine, separate media, etc. In the examples listed, the directory /safeplace is used as a location to store files. If the change log is not configured, all commands containing ldapclog can be ignored.
  2. Save the Tivoli Directory Server configuration and schema files in a secure location. These files need to be updated only if you change the topology, configuration parameters, or schema. In this example, ldapdb2 is used as the Tivoli Directory Server instance and database instance name. 
    cp /home/ldapdb2/idsslapd-ldapdb2/etc/*  /safeplace/etc
  3. Make sure that ibmslapd is not running. 
    ibmslapd -I ldapdb2 -k
    Note:
    In this example, the path of the log files has not been modified from the default locations. Here, the default log path locations are used for both directory and change log databases. For recovery purposes, log files should be kept on a different physical drive than the databases.
  4. Update the directory server database and change log database for online backup support with archival logging on, and incremental backup with trackmod on.
    Note:
    Setting trackmod on for incremental backup support can have an impact on the runtime performance for database update or insert operation.
    db2 update db cfg for ldapdb2 using logarchmeth1 logretain trackmod on
db2 update db config for ldapclog using logarchmeth1 logretain trackmod on
db2 force applications all
db2stop
db2start
Creating full offline backups for both the directory and change log databases
  1. Create full database offline backups for both directory and change log databases on Sunday. 
    db2 backup db ldapdb2 to /safeplace/sun-full-ldapdb2 
db2 backup db ldapclog to /safeplace/sun-full-ldapclog
  2. Start the directory server instance. 
    ibmslapd -I ldapdb2
Creating incremental online backups for both the directory and change log databases
  1. On a daily basis or more frequently if determined necessary, create incremental backups.
    Note:
    You can only use an online backup image for recovery if you have the logs that span the time during which the backup operation was running. Note that the directory and change log database logs are kept in different paths with identical names, for example, S0000000.LOG and S0000001.LOG, so they need to be saved in different directories if the change log is configured.
    db2 backup db ldapdb2 online incremental to /safeplace/mon-ldapdb2
  2. Verify the path to the log files for the directory database. 
    db2 get db config for ldapdb2 | grep -i “Path to log files"

    An example of the output displayed:

    Path to log files = /home/ldapdb2/ldapdb2/NODE0000/SQL00001/SQLOGDIR/

cp /home/ldapdb2/ldapdb2/NODE0000/SQL00001/SQLOGDIR/* 
                               /safeplace/db2logs-ldapdb2
db2 backup db ldapclog online incremental to /safeplace/mon-ldapclog
  3. Verify the path to the log files for the change log database. 
    db2 get db config for ldapclog | grep “Path to log files"

    An example of the output displayed:

    Path to log files   = /home/ldapdb2/ldapdb2/NODE0000/SQL00002/SQLOGDIR/

cp /home/ldapdb2/ldapdb2/NODE0000/SQL00002/SQLOGDIR/* 
                                     /safeplace/db2logs-ldapclog
Restoring the directory and change log databases

Suppose a disk drive failed on Wednesday morning on the machine being used, since the /safeplace directory used to backup the files was not affected, it can be used for restore.

If a different system is being used to restore the database, the /safeplace directories on the backed up system must be set up on the new system to the local /safeplace directory. This must include all backup directories being used, as well as the log files in the /safeplace/db2log-ldapdb2/NODE0000 and the /safeplace/db2log-ldapclog/NODE0000 directories.

  1. If necessary, install Tivoli Directory Server. Configure a new database, using the same information that was specified earlier. Copy the configuration and schema files backed up previously. 
    cp  /safeplace/etc/*  /home/ldapdb2/idsslapd-ldapdb2/etc
  2. Make sure that ibmslapd is not running. 
    ibmslapd -I ldapdb2 -k
  3. Restore the directory database. The last backup image to be restored is called the target image. The target image must be restored twice, once at the start of the restore procedure and again at the end. In order to restore Tuesday's incremental backup. 
    db2 restore db ldapdb2 incremental from /safeplace/tues-ldapdb2
db2 restore db ldapdb2 incremental from /safeplace/sun-full-ldapdb2
db2 restore db ldapdb2 incremental from /safeplace/tues-ldapdb2
  4. Copy the log files backed up previously to the default log path locations. 
    cp /safeplace/db2logs-ldapdb2/* 
                   /home/ldapdb2/ldapdb2/NODE0000/SQL00001/SQLOGDIR

db2 rollforward db ldapdb2 to end of logs and stop
  5. Restore the change log database. 
    db2 restore db ldapclog incremental from /safeplace/tues-ldapclog
db2 restore db ldapclog incremental from /safeplace/sun-full-ldapclog
db2 restore db ldapclog incremental from /safeplace/tues-ldapclog
  6. Copy the log files backed up previously to the default log path locations. 
    cp /safeplace/db2logs-ldapclog/* 
                 /home/ldapdb2/ldapdb2/NODE0000/SQL00002/SQLOGDIR

db2 rollforward db ldapclog to end of logs and stop
Note:
In this case, recovery requires a full backup image and the last incremental backup. Note that the Monday incremental backup is not needed to restore up through Tuesday.
Using incremental delta backups

In the examples using incremental backup, the incremental backup increases in size until the next full backup. This is because the backup contains accumulated changes over time, so there are many more changes saved for Saturday than there were for Monday. DB2 also allows “delta" backups, which save only changes made since the last backup of any kind. These delta backups are much smaller and can be done in lesser time. When restoring, you must have all deltas since the last full or incremental backup.

The commands to perform online delta backups for the ldapdb2 database on a daily basis are listed:

db2 backup db ldapdb2 online incremental delta to /safeplace/mon-delta-ldapdb2
db2 backup db ldapdb2 online incremental delta to /safeplace/tues-delta-ldapdb2
db2 backup db ldapdb2 online incremental delta to /safeplace/wed-delta-ldapdb2
db2 backup db ldapdb2 online incremental delta to /safeplace/thurs-delta-ldapdb2
db2 backup db ldapdb2 online incremental delta to /safeplace/fri-delta-ldapdb2 
db2 backup db ldapdb2 online incremental delta to /safeplace/sat-delta-ldapdb2

When using delta backups, the log files for the database must be kept in a secure location. If you are using the default log paths, you must copy them to the /safeplace/db2logs-ldapdb2 directory or modify the database configuration to save them directly in the /safeplace/db2logs-ldapdb2 directory.

Restoring from incremental delta backups

In the examples, the log files for the database from the backup machine must be available on the machine being used for restoring the delta backups. If you are using the default log paths, you must copy them from the /safeplace/db2logs-ldapdb2/NODE0000 directory on the backup machine to the default log path on the machine being restored, or modify the database configuration newlogpath on the new machine and copy them directly to the /safeplace/db2logs-ldapdb2/NODE000 directory. When restoring from delta backups, you must have ALL deltas since the last full or incremental backup.

The commands to restore online delta backups for the ldapdb2 database are as listed:

db2 restore db ldapdb2 incremental from /safeplace/sat-delta-ldapdb2
db2 restore db ldapdb2 incremental from /safeplace/sun-full-ldapdb2
db2 restore db ldapdb2 incremental from /safeplace/mon-delta-ldapdb2
db2 restore db ldapdb2 incremental from /safeplace/tues-delta-ldapdb2
db2 restore db ldapdb2 incremental from /safeplace/wed-delta-ldapdb2
db2 restore db ldapdb2 incremental from /safeplace/thurs-delta-ldapdb2
db2 restore db ldapdb2 incremental from /safeplace/fri-delta-ldapdb2
db2 restore db ldapdb2 incremental from /safeplace/sat-delta-ldapdb2
Note:
The target image must be restored twice, at the beginning and at the last restore.

Copy the logs and do rollforward:

cp /safeplace/db2logs-ldapdb2/* 
                 /home/ldapdb2/ldapdb2/NODE0000/SQL0001/SQLOGDIR/

db2 rollforward db ldapdb2 to end of logs and stop

Pros and cons of different backup and restore strategies

If a database is used for high write activity, an online full backup may be more efficient. Although minimal, the tracking of updates to the database can have an impact on the runtime performance of transactions that update or insert data.

Incremental backup can be used as a way to protect a database that is mostly read-only and has some write activity, which makes it important to be recoverable. An incremental backup image is a copy of all database data that has changed since the most recent, successful, and full backup operation. This is also known as a cumulative backup image. The predecessor of an incremental backup image is always the most recent successful full backup of the same object. With this approach, you must save the last full backup and the last cumulative incremental backup because both will be used for restoring the database.

An incremental delta backup image is a copy of all database data that has changed since the last successful backup, such as full, incremental, or incremental delta. This is also known as a differential or noncumulative backup image. While delta backups are smaller, all deltas since the last full or cumulative incremental backup are required to restore the database.

Managing the archived logs

When using online backup, you need to keep archived logs for as long as they might be required for restoring a database, which depends on your backup methodology and goals. This applies even if you have configured one of the log archival options that “automates" log archiving, you still must have a plan to delete old log files as they become expendable so that your archive space does not get full. One key decision that you must make is whether you want to recover your data up to the most recent backup, or you want to recover data right up to the time of the system failure. In case is a disk fails and you have to restore a database from a backup, you must have the log files that were taken during the backup. After the restore activity, the log files are rolled forward to bring the database to a consistent state that existed after the last backup. If you have saved all the log files generated since the last backup, you can replay the logs right to a time just before the crash. This helps reduce loss of updates to the directory considerably. The next main factor is your backup methodology and schedule. Consider the following examples:

  1. If you perform daily full online backups, then you must at least keep the log files that were active during the last backup operation. If you have saved all logs generated since the beginning of the last backup, then you would have all the data necessary to restore the database to the point in time immediately before an event, such as disk or system failure. Any log files archived before the last backup can be deleted to free disk space.
  2. If you perform a full online backup once a week and thereafter daily incremental backups in between, then you must at least save the logs that were active during the latest backup, full or incremental. Also, with this approach all the archived logs before the last full backup are no longer needed and can be deleted.
  3. If you perform a full online backup once a week and thereafter daily incremental delta backups, then you need to save the logs that were active during the latest backup, full or delta. In order to restore data up to the point in time of the data loss, you must save all the logs since the last backup operation. Any log files archived before the last full backup can be deleted.

Other examples of DB2 backup, restore, and rollforward command options

In cases where you want to restore a database to a specific point in time and not roll forward any changes made after than point in time, the “without rolling forward" option will prevent DB2 from changing the restored database in rollforward pending state.

db2 restore db ldapdb2 from /safeplace taken at 20040405154705 without rolling forward

To restore a database without prompting for a path that has only one backup database image stored, use the following command:

db2 restore db ldapclog from /safeplace/full-backup-ldapclog without 
                       rolling forward without prompting

The command for offline rollforward database to a point in time:

db2 rollforward database ldapdb2 to 2004-04-22-14.54.21.253422 and stop

This command rolls forward all logs located in the log folder specified in the database configuration file up to and including the point-in-time as stated in the example. The “and stop" key phrase completes the rollforward recovery process by rolling back incomplete transactions and tuning off the rollforward pending state of the database.

Common problems that may occur during DB2 backup, restore, or rollforward

In the scenarios listed below, the database name ldapdb2 is used. For change log, the change log database ldapclog can be used.

Scenario 1
When you try updating database configuration for online backup parameters while ibmslapd is running: 
db2 update db cfg for ldapdb2 using logarchmeth1 logretain trackmod on

DB20000I  The UPDATE DATABASE CONFIGURATION command completed successfully.

SQL1363W One or more of the parameters submitted for immediate modification
were not changed dynamically. For these configuration parameters, all
applications must disconnect from this database before the changes become
effective.

If you receive the displayed message, you must stop and restart ibmslapd for the changes to take effect. Use the following commands:

ibmslapd -I ldapdb2 -k
ibmslapd -I ldapdb2
Scenario 2
When you try performing online backup without setting logretain: 
db2 backup database ldapdb2 online to /safeplace

SQL2413N Online backup is not allowed because either logretain or userexit 
for roll-forward is not activated, or a backup pending condition is in 
effect for the database.

To set the archival logging parameters to enable rollforward recovery for the database ldapdb2 the following DB2 command must be run:

db2 update db config for ldapdb2 using logarchmeth1 logretain

After archival logging is configured, the user must make a full backup of the database. This state is indicated by the backup_pending flag parameter. If a full backup has not been made, the following message will be displayed when the user connects to the database:

db2 connect to ldapdb2
SQL1116N A connection to or activation of database <ldapdb2> 
cannot be made because of a BACKUP PENDING.

The database will be in backup pending state until an offline backup is performed. This could cause a server to fail when it connects to the database and will start in configuration mode only.

Scenario 3
Taking a full backup: 
db2 backup database ldapdb2 to /safeplace

If the backup is successful, the following message is displayed:

Backup successful.  The timestamp for this backup image is : 20040308170601
Scenario 4
When you try to restore a database while ibmslapd is running, the following message is displayed: 
db2 restore db ldapdb2 from /safeplace 
SQL1035N The database is currently in use.
Scenario 5
If rollforward must be done following a restore: 
db2 connect to ldapdb2
SQL1117N A connection to or activation of database “LDAPDB2" cannot be made 
because of ROLL-FORWARD PENDING.  SQLSTATE=57019
The database will be in rollforward pending state until a rollforward command is issued. This could cause a server to fail when it connects to the database and will start in configuration mode only.

[ Top of Page | Previous Page | Next Page ]