Recover from user error
It is possible to restore accidentally deleted or changed data.
Changes to a replicated DS directory service are similar to those made with the Unix rm command,
but with a twist.
With the rm command, if you make a mistake you can restore your files from backup,
and lose only the work done since the last backup.
If you make a mistake with an update to the directory service, after you restore from backup,
replication efficiently replays your mistake over the data you restored.
There is more than one way to recover from user error. None of the ways are limited to changing DS settings. All involve manually fixing mistakes.
Consider these alternatives:
-
Encourage client applications to provide end users with undo capability.
In this case, client applications take responsibility for maintaining an undo history.
-
Maintain a record of each update to the service, so that you can manually "undo" mistakes.
You can use the external changelog. The external changelog is enabled with replication, and does not use additional space.
For instructions, refer to Changelog for notifications. In particular, refer to Include unchanged attributes on saving what is deleted as well as changed.
DS servers can write to a file-based audit log. The audit log does not help with a general solution in this case. The DS audit log records only changes to the data. When you delete an entry, the audit log does not record the entry before deletion. The following example shows audit log records for changes made to Barbara Jensen’s entry:
# <datestamp>; conn=<number>; op=<number> dn: uid=bjensen,ou=People,dc=example,dc=com changetype: modify replace: description description: This is the description I want. - replace: modifiersName modifiersName: uid=admin - replace: modifyTimestamp modifyTimestamp: <timestamp> # <datestamp>; conn=<number>; op=<number> dn: uid=bjensen,ou=People,dc=example,dc=com changetype: modify replace: description description: I never should have changed this! - replace: modifiersName modifiersName: uid=admin - replace: modifyTimestamp modifyTimestamp: <timestamp> # <datestamp>; conn=<number>; op=<number> dn: uid=bjensen,ou=People,dc=example,dc=com changetype: deleteYou can use these records to fix the mistaken update to the description. However, the audit log lacks the information needed to restore Barbara Jensen’s deleted entry.
-
For administrative errors that involve directory data, use the external changelog if possible.
If not, an alternative technique consists of restoring backup to a new server set up to not replicate. (Replication replays all updates, including mistakes.) Compare data on the separate restored server to the live replicas, and fix the mistakes manually.
A more drastic alternative is to rebuild the entire service from backup, as described in Restore to a known state. This alternative is only recommended in the case of a major error where you have a very fresh backup (taken immediately before the error), and no client applications are affected.
-
For administrative configuration errors that prevent servers from starting, know that DS servers keep snapshots of the main configuration file, including the
opendj/var/config.ldif.startokfile, and the files in theopendj/var/archived-configs/directory.Compare the current configuration with the earlier configurations, stop the server, and repair mistakes manually. Take care to avoid trailing blank space at the end of LDIF lines.