General Methods for Database Recovery

When it comes to recovery, the first step for a DirX Directory administrator is to determine the best and most suitable recovery source. These might be the following:

  • A previous LDIF dump file of the database or an LDIF dump created from the inconsistent database if directory service can start.

  • A previous backup archive of the database created with the dirxbackup command. In this case a backup of the inconsistent database makes no sense, as the binary backup will contain the database inconsistency.

  • In a shadowing environment, a consistent database on another node can be used to recover the inconsistent database by initiating a total update.

In most cases directory service is used in a shadowing environment, where a supplier node maintains a consistent database and one or more consumer nodes maintain copies of the supplier database. In this case, the supplier database can be used to recover an inconsistent consumer database or an inconsistent supplier database can be recovered by switching to a consistent consumer and using it as the new supplier. This is the preferred method of recovery, as it can loose the least amount of data and requires no previous healthy backup.

In case there is a standalone node or a shadowing environment with no consistent database, the only recovery options are to restore the database from an LDIF dump file or a healthy verified backup archive.

The following table presents the recommended recovery options for each case mentioned above as their 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

When to use

  • Standalone node

  • shadowing with no consistent database node

  • Standalone node

  • shadowing with no consistent database node

  • Shadowing environment with a consistent database

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.

  • In case this would be a shadowing environment:

    • DirX service will be stopped on all nodes.

    • dbamboot is run on all nodes to reset the databases.

    • dirxload is run on the supplier node to load the data from the LDIF file.

    • all nodes are started again.

    • new TOTAL UPDATE is initiated on the supplier node (sob terminate and sob establish) to synchronize the databases of all consumer nodes. Pay attention to agreements with TOTAL by MEDIA, they need further steps to be synchronized.

Restore Using a Backup Archive

Note: Backup archives created with dirxbackup are simply a dump of the blocks stored in the database.The cusrrent 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.

  • In case this would be a shadowing environment:

    • DirX service will be stopped on all nodes.

    • dbamboot is run on all shadow nodes to reset the databases.

    • dirxbackup is run on the supplier node to load the data from the backup archive.

    • all nodes are started again.

    • new TOTAL UPDATE is initiated on the supplier node (sob terminate and sob establish) to synchronize the databases of all consumer nodes. Pay attention to agreements with TOTAL by MEDIA, they need further steps to be synchronized.

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.