IBM Tivoli Directory Server backup and restore

Directory Server, Version 6.1

Appendix M. IBM Tivoli Directory Server backup and restore

Introduction

IBM® Tivoli® Directory Server uses IBM DB2® relational database to store directory information. To ensure the availability of directory information and to recover critical data from loss or corruption, it is necessary for Tivoli Directory Server directory administrators to design a backup and restore strategy for their Tivoli Directory Server environments.
DB2 provides online backup feature, which allows taking backup of a database while the database is being accessed by other applications, such as Tivoli Directory Server. Before considering a backup and restore strategy that includes online backup, be aware that performing an online backup consumes a significant amount of DB2 resources.
This appendix starts with a description of the Tivoli Directory Server v6.1 database and tablespace definitions. Individual sections describe alternatives to Tivoli Directory Server backup and restore procedure that include DB2 offline and online backup, DB2 offline restore, and redirected restore.

Tivoli Directory Server v6.1 directory schema and database definitions

Tivoli Directory Server v6.1 uses directory schema files to define the underlying DB2 directory database, which is used to store data. In order to recover a data stored on Tivoli Directory Server, you are required to back up the files containing the Tivoli Directory Server directory configuration and schema and the DB2 databases.

Tivoli Directory Server v6.1 directory schema

By default, Tivoli Directory Server maintains its schema files in the etc directory under the directory server instance owner's home directory. For example, for the ldapdb2 instance owner, the schema file location would be:
/home/ldapdb2/idsslapd-ldapdb2/etc
Note:

We can also specify a different location for the schema files during instance creation provided the instance owner has write access on the directory.
Each time you start the server, it checks the schema files, validates them against the underlying DB2 database, and checks that the database is correctly configured to support the schema.
A new instance can be configured to have the same schema by copying the schema files to the new server instance owner's <inst_owner_home>/idsslapd-<inst_name>/etc directory. For example, to back up the schema files on AIX®, where ldapdb2 is the Tivoli Directory Server instance being used and the directory /safeplace/etc is the location where the schema files are to be saved, issue the following command:
cp /home/ldapdb2/idsslapd-ldapdb2/etc/* /safeplace/etc
To set up a new instance with the same schema, issue the following command:
cp /safeplace/etc/* /home/<newuser>/idsslapd-<new_user>/etc
Tivoli Directory Server directory database and tablespaces

When Tivoli Directory Server creates a database for the directory, it uses the db2 create database command to create the database. Tivoli Directory Server creates this database with four System Managed Space (SMS) tablespaces.
Since DB2 backup and restore can be done at the database level, the tablespace level, or both levels, it is important to understand the underlying structure to determine which backup and restore method might be best for different Tivoli Directory Server environments. In general, it is advisable that users do not use DB2 backup and restore at the tablespace level for reasons listed.
In the examples, ldapdb2 is used as the database name. We can use the db2 list database directory and db2 list tablespace show detail commands to find the database and tablespace information for your environment.
We can view the tablespaces by using the following DB2 commands run under the context of the DB2 instance owner. In this example, ldapdb2 is used:
db2 connect to <databasename>
db2 list tablespaces
The following examples show tablespace output for the Tivoli Directory Server directory database on an AIX, Linux®, Solaris, or HP-UX system:
Tablespaces for Current Database

 Tablespace ID                        = 0
 Name                                 = SYSCATSPACE
 Type                                 = System managed space
 Contents                             = Any data
 State                                = 0x0000
   Detailed explanation:
     Normal

Tablespace ID                         = 1
 Name                                 = TEMPSPACE1
 Type                                 = System managed space
 Contents                             = Temporary data
 State                                = 0x0000
   Detailed explanation:
     Normal

Tablespace ID                         = 2
 Name                                 = USERSPACE1
 Type                                 = System managed space
 Contents                             = Any data
 State                                = 0x0000
   Detailed explanation:
     Normal

Tablespace ID                         = 3
 Name                                 = LDAPSPACE
 Type                                 = System managed space
 Contents                             = Any data
 State                                = 0x0000
   Detailed explanation:
     Normal
Tivoli Directory Server data is stored in two separate tablespaces: USERSPACE1 and LDAPSPACE. By default, there is only one container or directory for each tablespace. To view the details about the USERSPACE1 tablespace, issue the following DB2 command:
db2 list tablespace containers for 2
An example output for the Tivoli Directory Server instance ldapdb2 is shown below:
Tablespace Containers for Tablespace 2

 Container ID                         = 0
 Name                           = /home/ldapdb2/ldapdb2/NODE0000/SQL00001/SQLT0002.0
 Type                           = Path
The default container or directory that DB2 uses for tablespace 2 (USERSPACE1) is /home/ldapdb2/ldapdb2/SQL00001/SQLT0002.0. It contains all of the ldapdb2 database tables, which have rows that fit in a 4K page size. This includes the attribute tables that are used for fast DB2 lookups. Tablespace 3 (LDAPSPACE) contains the remainder of the database tables that require a 32K page size. This includes the ldap_entry table, which contains the majority of the Tivoli Directory Server directory data and the replication tables. To view the tablespace container information for the LDAPSPACE tablespace, issue the following DB2 command:
db2 list tablespace containers for 3
An example output is as follows:
Tablespace Containers for Tablespace 3

 Container ID                         = 0
 Name                                 = /home/ldapdb2/ldap32kcont_ldapdb2
 Type                                 = Path
It is important to notice that data in Tivoli Directory Server is spread out between tablespace 2 and tablespace 3, and both tablespaces need to be accessed for most of the single Tivoli Directory Server operations. In case of a search operation, the attribute tables in tablespace 2 are used to find the entries that match the given criteria but the entry information is returned from the ldap_entry table in tablespace 3. For an update operation, the attribute tables in tablespace 2 and the ldap_entry (and possibly the replication tables) in tablespace 3 must be updated. For this reason, users should perform backup and restore only at the database level, so that the related sets of data are kept together. If the related sets of data are not kept together, recovering to a point in time where all of the data is consistent would be unlikely.

Tivoli Directory Server change log database and tablespaces

In Tivoli Directory Server 6.0 and later versions, the change log feature records all updates to the directory in a separate change log DB2 database, which is different from the database that holds the Tivoli Directory Server directory information tree (DIT). The change log database can be used by other applications to query and track LDAP updates. By default, the change log function is disabled. The change log function should be configured only if needed because it reduces update performance due to the additional logging overhead. A way to check for existence of the change log function is to look for the suffix CN=CHANGELOG. If it exists, the change log function is enabled.
When Tivoli Directory Server creates a database for the change log, it uses the db2 create database command to create a database named ldapclog. IBM Tivoli Directory Server creates this database with four SMS tablespaces identical to the ldapdb2 database.
We can view the tablespaces by using the following DB2 commands run under the context of the DB2 instance owner. In this example, ldapdb2 is used.
db2 connect to ldapclog
db2 list tablespaces
It is important to notice that the Tivoli Directory Server directory information is stored in a database (ldapdb2) which is different to the change log database (ldapclog). In order to keep related sets of data together, care must be taken to ensure they are backed up and restored in a consistent manner.

Overview of backup and restore procedures for LDAP

In a Tivoli Directory Server environment, we can back up and restore a database using the DB2 commands, Tivoli Directory Server backup and restore commands, and Tivoli Directory Server tools. These options have their advantages and disadvantages.
DB2 backup and restore are built-in commands available in DB2 to back up and restore databases. The advantages of using db2 backup and db2 restore commands or the dbback and dbrestore commands is that the DB2 configuration parameters and database optimizations parameters are preserved for the backed-up database. In addition, the restored database has the same performance tuning specifications as that of the backed-up database. One of the disadvantages of using db2 backup and restore is that the database backed-up on one hardware platform cannot be restored on a different platform. For example, a database backed up on AIX system cannot be restored on a Solaris system. In addition, database backed up on a Tivoli Directory Server version cannot be restored on a different Tivoli Directory Server version. You are also required to use the same version of DB2 for both the db2 backup and db2 restore operations. See DB2 Administration Guide to know more about DB2 backup and restore procedures. See DB2 Command Reference to know more about the DB2 commands. The DB2 Administration Guide and the Command Reference are part of the online library installed with DB2 and the Tivoli Directory Server.
The Tivoli Directory Server commands, idsdbback and idsdbrestore, for back up and restore of databases use the DB2 backup and restore commands. In addition to the features provide by the DB2 backup and restore commands, idsdbback and idsdbrestore also backs up and restores Tivoli Directory Server configuration and schema files. However, it is important to note that idsdbback does not support DB2 online backup in Tivoli Directory Server v6.0. The idsbback command can be used only when the Tivoli Directory Server is not running. For more information about the use of these commands, see the Server utilities section in IBM Tivoli Directory Server Version 6.1 Command Reference.
An alternative to the DB2 and Tivoli Directory Server backup and restore commands are Tivoli Directory Server tools, such as the LDAP Data Interchange Format (LDIF) export and import commands, db2ldif and ldif2db. These tools can be used across dissimilar hardware platforms but the process is slower. These tools do not preserve the DB2 configuration parameters and database optimizations parameters. For more information about the use of these commands, see the Server utilities section in IBM Tivoli Directory Server Version 6.1 Command Reference.
Note:

If you restore over an existing database, any performance tuning tasks on that existing database is lost. You must check all DB2 configuration parameters after performing a restore. Also, if you do not know whether a db2 reorgchk was performed before the database was backed up, run db2 reorgchk after the restore.

Examples of offline backup and restore procedure for a directory database

The DB2 commands to perform offline backup and restore operations for a directory database, ldapdb2, are as follows:
su - ldapdb2
db2start
db2 force applications all
db2 backup db ldapdb2 to <directory_or_device>
db2 restore db ldapdb2 from <directory_or_device> replace existing
where, directory_or_device is the name of a directory or device where the backup is stored.
The DB2 commands to perform offline backup and restore operations for the change log database are as follows:
su - ldapdb2
db2start
db2 force applications all 
db2 backup db ldapclog to <directory_or_device>
db2 restore db ldapclog from <directory_or_device> replace existing
The most common error that occurs while restoring is a file permission error. Following are some reasons why this error might occur:
The DB2 instance owner does not have permission to access the specified directory and file. One way to solve this is to change directory and file ownership to the DB2 instance owner. For example, enter the following command:
chown ldapdb2 <fil_or_dev>
The backed-up database is distributed across multiple directories, and those directories do not exist on the target system of the restore. Distributing the database across multiple directories is accomplished with a redirected restore. To solve this problem, either create the same directories on the target system or perform a redirected restore to specify the proper directories on the new system. When creating the same directories, ensure that the owner of the directories is the DB2 instance owner.
Replication considerations

Backup and restore operations may be used to initially synchronize a consumer with a supplier or whenever the supplier and consumer get out of sync. A consumer can get out of sync if it is not defined to the supplier or is not reachable by the supplier. In this case, the supplier does not know about the consumer and does not save updates on a propagation queue for that consumer.

Overview of online backup and restore procedures for Tivoli Directory Server

When a Tivoli Directory Server database is created, only circular logging is enabled for it. This means that log files are reused in a circular fashion, and are not saved or archived. With circular logging, rollforward recovery is not possible but crash recovery is possible. The directory server must be stopped and should be offline when backups are taken. Before performing online backups, administrators must plan a strategy to manage the DB2 log files that will be needed to perform a restore from an online backup.

Log management

When log archiving is configured for the database, rollforward recovery is possible. This is because of the following reasons:

The logs record changes to the database during and after the backups are taken.
Log files are kept even after they contain committed and externalized data referred to as "inactive" logs.

To configure log archiving, change the logarchmeth1 database parameter from OFF to an appropriate value by selecting the archiving mode desired. The possible values for mode are:

LOGRETAIN

In this mode, inactive log files are never overwritten. This means that inactive logs must be moved to an archive location to avoid running out of disk space for primary logs. The database configuration specifies the number of active primary log files and active secondary log files that can be created. When LOGRETAIN is set, DB2 will first fill up the primary logs, and then if the first primary log is still active, DB2 will create secondary logs. If the number of primary and secondary logs have been created and filled has reached the maximum limit before the first primary log becomes inactive, a "log full" condition will occur. As primary logs become inactive, DB2 will create additional primary logs as needed. In the LOGRETAIN mode, it is important to monitor the disk space available for the log files because if the disk fills up, directory updates will not be possible until the condition is rectified.

USEREXIT

In this mode, archival and retrieval of logs is performed by a user-supplied user exit program called db2uext2. The user exit program is called to copy a log file to an archive location as soon as the log file is full. This allows DB2 to rename and reuse the file once it becomes inactive. During recovery operations, after restoring a database from a backup, when inactive log files are required, DB2 will call the user exit program to retrieve the necessary logs from the archive location.

DISK:directory

With this setting, log management is performed using an algorithm similar to the USEREXIT mode. The difference between the two modes, USEREXIT and DISK:directory, is that instead of calling the user exit program, DB2 will automatically archive the logs from the active log directory to the specified directory. During recovery, DB2 retrieves these logs from that location.

TSM:[management class name]

This mode is similar to the USEREXIT mode except that logs will be automatically archived on the local Tivoli Storage Manager server. The management class name parameter is optional. If not specified, the default management class is used.

VENDOR:library

In this mode, logging operates in a mode similar to USEREXIT except that the specified vendor library is invoked to archive or retrieve the logs.

When this parameter is configured, the database is enabled for rollforward recovery. After logarchmeth1 is set to for log archiving, a full offline backup of the database must be made for the "backup pending state" to be satisfied so that the database can be used. To check if the database is in "backup pending state", look at the "Backup pending" value returned from the following DB2 command, which could either be YES or NO.
db2 get db config for ldapdb2
When the database is recoverable, the backups of the database can be completed online. Rollforward recovery reapplies the completed units of work recorded in the logs to the restored database, tablespace, or tablespaces. We can specify rollforward recovery either to the end of the logs or to a particular point in time.
A recovery history file is created with each database and this file is updated automatically with summary information whenever you carry out a backup or restore of a full database or tablespace. The recovery history file is a useful tracking mechanism for restore activity within a database. This file is created in the same directory as the database configuration file. It is automatically updated whenever one of the following activities is performed:

Backup of a database or tablespace
Restore of a database or tablespace
Rollforward of a database or tablespace
Alter of a tablespace
Quiesce of a tablespace
Rename of a tablespace
Load of a table
Drop of a table
Reorganization of a table
Update of table statistics

For information about existing backed-up databases, enter the following DB2 command:
db2 list history backup all for db ldapdb2
The database configuration file contains the logarchmeth1 and other parameters related to rollforward recovery. In some cases, since the default parameter settings will not work well, you may need to change some of these default settings for your setup. See the DB2 Administration Guide for detailed information about configuring these parameters in DB2.

Primary logs (logprimary)

This parameter specifies the number of primary logs that might be active at a given time.

Secondary logs (logsecond)

This parameter specifies the number of secondary log files that might be created if all active primary logs are full.

Log size (logfilsiz)

This parameter determines the number of pages for each of the configured logs. A page is 4 KB in size.

Log buffer (logbufsz)

This parameter enables you to specify the amount of database shared memory to use as a buffer for log records before writing these records to disk.

Number of commits to group (mincommit)

This parameter enables you to delay the writing of log records to disk until a minimum number of commits have been performed.

New log path (newlogpath)

We can change the location where active logs and future archive logs are placed by changing the value for this configuration parameter to point to either a different directory or a device.

Primary log archive method (logarchmeth1)

This parameter specifies the media type of the primary destination for archived logs. See section "Log management" for details about the options available.

Secondary log archive method (logarchmeth2)

This parameter specifies the media type of the secondary destination for archived logs. If this parameter is specified, log files will be archived using both this method and the method specified by logarchmeth1.

Track modified pages (trackmod)

When this parameter is set to "Yes", the database manager tracks database modifications so that the backup utility can detect which subsets of the database pages must be examined by an incremental backup and potentially included in the backup image. After setting this parameter to "Yes", take a full database backup in order to have a baseline against which incremental backups can be taken.

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:
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.
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 the examples, the Tivoli Directory Server instance and database are named ldapdb2.
cp /home/ldapdb2/idsslapd-ldapdb2/etc/* /safeplace/etc
Make sure that ibmslapd is not running.
ibmslapd -I ldapdb2 -k
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:
If necessary, install Tivoli Directory Server.
Configure a database, using the same information that was specified on the backup machine.
Copy or ftp the configuration, schema, and backup image files from the backup machine to /safeplace on this machine.
Copy the backed-up configuration and schema files to this machine.
cp /safeplace/etc/* /home/ldapdb2/idsslapd-ldapdb2/etc
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, we 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)
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.
Save the 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
Make sure that ibmslapd is not running.
ibmslapd -I ldapdb2 -k
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
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
After archival logging is set, make a full offline backup. Create a full offline backup of database.
db2 backup db ldapdb2 to /safeplace/sun-full-ldapdb2
Start the directory server instance.
ibmslapd -I ldapdb2
Creating full online backup for the directory database
On a nightly basis (or more frequently if necessary), create full backup and copy log files from the log file path.
Note:

We 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
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.
If necessary, install Tivoli Directory Server.
Configure a database, using the same information that was specified on the backup machine.
Copy or tar the configuration and schema files backed up previously.
cp  /safeplace/etc/*  /home/ldapdb2/idsslapd-ldapdb2/etc
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.
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, copy the log files from the old system to the new.
db2 update db config for ldapdb2 using 
               newlogpath /safeplace/db2logs-ldapdb2
.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 20. Incremental cumulative and Delta backup
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.
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
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.
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
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
Start the directory server instance.
ibmslapd -I ldapdb2
Creating incremental online backups for both the directory and change log databases
On a daily basis or more frequently if determined necessary, create incremental backups.
Note:

We 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
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
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.
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  
Make sure that ibmslapd is not running.
ibmslapd -I ldapdb2 -k 
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
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
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
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, 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, 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, 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, we 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 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, 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, we 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:

If you perform daily full online backups, then 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.
If you perform a full online backup once a week and thereafter daily incremental backups in between, then 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.
If you perform a full online backup once a week and thereafter daily incremental delta backups, then we 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, 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, 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 | Contents | Index ]