General Methods for Database Recovery

There are three general methods for restoring a database when the type of database inconsistency cannot be determined or the recovery steps followed for a specific type of inconsistency do not solve it:

Recovery from an LDIF dump file
Recovery from a backup archive
Recovery from a total update

The following table compares the pros and cons of these methods and the level of data loss they can cause.

Method	Restore using an LDIF dump	Restore using a backup archive	Restore by initiating a total update
Pros	Data defragmentation occurs automatically LDIF is interchangeable with other vendors	Fast	No backup needed Restored data are "up-to-date"
Cons	Loading process slower than with backup archive	Must be verified to ensure usability Not interchangeable with other vendors	More complex to execute Increased network traffic during total update
Data loss	Modifications since the LDIF dump was created	Modifications since the backup was created	No data loss in a synchronous agreement and maybe a few modifications in an asynchronous agreement

Method

Restore using an LDIF dump

Restore using a backup archive

Restore by initiating a total update

Pros

Data defragmentation occurs automatically

LDIF is interchangeable with other vendors

Fast

No backup needed

Restored data are "up-to-date"

Cons

Loading process slower than with backup archive

Must be verified to ensure usability

Not interchangeable with other vendors

More complex to execute

Increased network traffic during total update

Data loss

Modifications since the LDIF dump was created

Modifications since the backup was created

No data loss in a synchronous agreement and maybe a few modifications in an asynchronous agreement

These procedures cannot account for all details of all customer installations. If your directory service configuration is more complex than a supplier DSA and one or more full shadow DSAs, we recommend contacting a DirX consultant to create a customized recovery plan that is specific to your setup.

The next sections describe how to perform each procedure.

Restore Using an LDIF Dump

To restore a database from an LDIF dump file:

Stop the DirX service.
Reset the database with the dbamboot command.
Load the data from the LDIF file with the dirxload command.
Start the DirX service.
Reload any saved LDIF change files with the dirxmodify command.
Synchronize the databases of the supplier and consumer(s) nodes:
If the recovered database is held by the supplier node, initiate a total update by running the dirxadm commands sob terminate and sob establish on the supplier node for all SOB agreements.
If the recovered database is held by a consumer node, initiate a total update by running the dirxadm commands sob terminate and sob establish on the supplier node for the SOB agreement(s) between the supplier and the recovered consumer.

Restore Using a Backup Archive

Note: Backup archives created with dirxbackup are simply a dump of the blocks stored in the database.The current state of the database cannot be determined, so it’s possible that the inconsistency will recur after a short period of time in a database recovered using a backup archive.As a result, we recommend using an LDIF dump file if it’s available.

To restore the database from a dirxbackup archive:

Stop the DirX service.
Restore the backup archive and any delta backup archives with dirxbackup.
Start the DirX service.
Synchronize the databases of the supplier and consumer(s) nodes:
If the recovered database is held by the supplier node, initiate a total update by running the dirxadm commands sob terminate and sob establish on the supplier node for all SOB agreements.
If the recovered database is held by a consumer node, initiate a total update by running the dirxadm commands sob terminate and sob establish on the supplier node for the SOB agreement(s) between the supplier and the recovered consumer.

Restore by Initiating a Total Update

If there is a consistent database in the system, an inconsistent database can be recovered by replicating the data from the consistent database using a total update.The procedures for recovering a consumer inconsistency and a supplier inconsistency are a bit different; each one is described below.

Note that this recovery method cannot be used when there is no consistent database in the system.In this case, use the "Restore Using an LDIF Dump" or the "Restore Using a Binary Backup" methods instead.

Recovering an Inconsistent Consumer

When a consumer database becomes inconsistent, perform the following steps to recover it:

Terminate the agreement between the supplier and the inconsistent consumer by running the dirxadm sob terminate command.
Create a backup of the inconsistent consumer.
Stop the inconsistent consumer.
Reset the database on the inconsistent consumer with the dbamboot tool.
Start the inconsistent consumer.
If the SOB agreements in the system are configured to use the “total update by media” feature:
Establish the agreement using the dirxadm sob establish command.
Run the dirxadm sob show command on the inconsistent consumer and check whether the SOB agreement configuration was properly replicated.
Create a backup (preferably in LDIF format) on the supplier.
Transfer the backup to the inconsistent consumer.
Load the backup created in the previous step on the inconsistent consumer.
Enable the agreement using the dirxadm sob enable command.
If the SOB agreements in the system are configured to use the “total update by DISP” method:
Establish the agreement again using the dirxadm sob establish command.
If the Context Prefix (CP) of the SOB agreement is not root, you may want to transfer the indexing configuration from the supplier, too. To do this:
Run the dirxadm export_dbconfig command on the supplier.
Transfer the file DirXDBconfig.out to the inconsistent consumer. It’s generated into the $DIRX_INST_PATH/tmp directory and should be moved into the same directory on the inconsistent consumer.
Run the dirxadm import_dbconfig command on the inconsistent consumer.

Recovering an Inconsistent Supplier

When a supplier database becomes inconsistent, perform the following steps to recover it:

Switch to a consistent consumer using the dirxadm sob switch command.
Terminate the SOB agreement between the old and the new supplier.
Create a backup of the old supplier.
Stop the old supplier.
Reset the database on the old supplier with the dbamboot tool.
If the SOB agreements in the system are configured to use the “total update by media” feature:
Establish the agreement using the dirxadm sob establish command.
Run the dirxadm sob show command on the old supplier and check whether the SOB agreement configuration was replicated.
Create a backup (preferably in LDIF format) on the new supplier.
Transfer the backup to the old supplier.
Load the backup created in the previous step on the old supplier.
Enable the agreement using the dirxadm sob enable command.
If the SOB agreements in the system are configured to use the “total update by DISP” method:
Establish the agreement using the dirxadm sob establish command.
If the Context Prefix (CP) of the SOB agreement is not root, you may want to transfer the indexing configuration from the new supplier, too. To do this:
Run the dirxadm export_dbconfig command on the new supplier.
Transfer the file DirXDBconfig.out to the old supplier. It’s generated into the $DIRX_INST_PATH/tmp directory and should be moved into the same directory on the old supplier.
Run the dirxadm import_dbconfig command on the old supplier.