Disaster recovery planning is an essential part of deploying any business-critical system. Each supported DBMS has multiple mechanisms for data backup and restoration. Any of these are appropriate. Identity Manager has no implicit requirements.
Typically, if a database fails, it would only be necessary to restore the repository to the point just before the database failure. However, if business requirements dictate that the repository be restored to any given point in time (through use of the appropriate vendor-specific methods such as ARCHIVELOG mode or Flashback in Oracle or FULL logging mode in SQL Server), this can be done as well. Regardless of the recovery method used, it is necessary to consider some implications of restoring a version of the repository that is not completely up-to-date.
While the state of the repository will be self-consistent after the data restoration, it will not necessarily be consistent (or even compatible) with external objects such as the resources. The following items demonstrate some possible inconsistencies that might arise:
Restored resources might be configured incorrectly, if resource attributes were changed.
Restored users might have pending attribute changes that are no longer desirable, because of more recent changes.
Restored workflows and tasks might be in a state that no longer matches the environment. For instance, formerly completed tasks could attempt to run again, and approvals might re-appear, requesting action from an administrator.
Additionally, resources are themselves the repository of account attributes. Restoring the repository to a specific point in time may not aid in restoring resources to prior states, since the information required to do so may never have been stored in the repository.