Performing Data Recovery When System or Application Fails

After hardware or application failure, you might have to restore the data from backup in some of the synchronized directory sources.

After completing the data recovery, however, you must perform an additional procedure to ensure that the synchronization can proceed normally.

The connectors generally maintain information about the last change that was propagated to the message queue.

This information, which is called the connector state, is used to determine the subsequent change that the connector has to read from its directory source. If the database of a synchronized directory source is restored from a backup, then the connector state might no longer be valid.

Windows-based connectors for Active Directory and for Windows NT also maintain an internal database. The database is a copy of the synchronized data source. The database is used to determine what has changed in the connected data source. The internal database is no longer be valid once the connected Windows source is restored from a backup.

In general, the idsync resync command can be used to repopulate the recovered data source.

Resynchronization cannot be used to synchronize passwords with one exception. The -i ALL_USERS option can be used to invalidate passwords in Directory Server. This works if the resynchronization data source is Windows. The SUL list must also include only Active Directory systems.

Use of the idsync resync command, however, might not be an acceptable option in every situation.

Before executing any of the steps detailed that follow, make sure that synchronization is stopped.

Bidirectional Synchronization

Use the idsync resync command with the appropriate modifier settings, according to the synchronization settings. Use the recovered directory source as the target of the resync operation.

Unidirectional Synchronization

If recovered data source is a synchronization destination, then the same procedure can be followed as for bidirectional synchronization.

If recovered data source is a synchronization source, then idsync resync can still be used to repopulate the recovered directory source. You need not change the synchronization flow settings in the Identity Synchronization for Windows configuration. The idsync resync command allows you to set synchronization flow independent of the configured flows with the -o Windows|Sun option.

Consider the following scenario as an example.

Bidirectional synchronization is setup between Directory Server and Active Directory.

• The database of a Microsoft Active Directory server has to be recovered from a backup.

• In Identity Synchronization for Windows, this Active Directory Source is configured for the SUL AD.

• Bidirectional synchronization for modifies, creates and deletes is setup between this Active Directory Source and a Sun Directory Server Source.

To Perform Unidirectional Synchronization

1. Stop synchronization.

   idsync stopsync -w - -q -

2. Resynchronize Active Directory Source. Also, resynchronize modifies, creations, and deletes.

   idsync resync -c -x -o Sun -l AD -w - -q -

3. Restart synchronization.

   idsync startsync -w - -q -

Directory Source Specific Recovery Procedures

The following procedures correspond to specific directory sources.

Microsoft Active Directory

If Active Directory can be restored from a backup, then follow the procedures in the sections covering either bidirectional, or unidirectional synchronization.

You might, however, have to use a different domain controller after a critical failure. In this case, follow these steps to update the configuration of the Active Directory Connector.

To Change the Domain Controller

1. Start the Identity Synchronization for Windows management console.

2. Select the Configuration tab. Expand the Directory Sources node.

3. Select the appropriate Active Directory Source.

4. Click Edit controller, and then select the new domain controller.

   Make the selected domain controller the NT PDC FSMO role owner of the domain

5. Save the configuration.

6. Stop the Identity Synchronization service on the host where the Active Directory Connector is running.

7. Delete all the files except the directories, under ServerRoot/isw-hostname/persist/ADPxxx. Here, xxx is the number portion of the Active Directory Connector identifier.

   For example, 100 if the Active Directory Connector identifier is CNN100.

8. Start the Identity Synchronization service on the host where the Active Directory Connector is running.

9. Follow the steps according to your synchronization flow in the unidirectional or the bidirectional synchronization sections.

Fail Over and Directory Server

Either the Retro Changelog database, or the database with synchronized users, or both can be affected by a critical failure.

To Manage Directory Server Fail Over

1. Retro Changelog Database.

   Changes in the Retro Changelog database might have occurred that the Directory Server connector could not process. Restoration of the Retro Changelog database only makes sense if the backup contains some unprocessed changes. Compare the most recent entry in the ServerRoot/isw-hostname/persist/ADPxxx/accessor.state file with the last changenumber in the backup. If the value in accessor.state is greater than or equal to the changenumber in the backup, do not restore the database. Instead, recreate the database.

   After the Retro Changelog database is recreated, make sure that you run idsync prepds. Alternatively, click Prepare Directory Server from the Sun Directory Source window in the Identity Synchronization for Windows management console.

   The Directory Server connector detects that the Retro Changelog database is recreated and log a warning message. You can safely ignore this message.

2. Synchronized Database.

   If no backup is available for the synchronized database, then the Directory Server connector has to be reinstalled.

   If the synchronized database can be restored from a backup, then follow the procedures in either the bidirectional or the unidirectional synchronization sections.