Recovering an LDAP database

Tags:

If you see errors similar to the ones below in your 389-ds or Red Hat Directory Server error log, never fear, it can be recovered.

[12/Sep/2013:20:51:50 -0400] - 389-Directory/1.2.11.15 B2013.211.1721 starting up
[12/Sep/2013:20:51:50 -0400] - Detected Disorderly Shutdown last time Directory Server was running, recovering database.
[12/Sep/2013:20:51:50 -0400] - libdb: Log sequence error: page LSN 19 2326209; previous LSN 19 2396886
[12/Sep/2013:20:51:50 -0400] - libdb: Recovery function for LSN 19 2398925 failed on forward pass
[12/Sep/2013:20:51:50 -0400] - libdb: PANIC: Invalid argument
[12/Sep/2013:20:51:50 -0400] - libdb: unable to join the environment
[12/Sep/2013:20:51:50 -0400] - Database Recovery Process FAILED. The database is not recoverable. err=-30974: DB_RUNRECOVERY: Fatal error, run database recovery
[12/Sep/2013:20:51:50 -0400] - Please make sure there is enough disk space for dbcache (10000000 bytes) and db region files
[12/Sep/2013:20:51:50 -0400] - start: Failed to init database, err=-30974 DB_RUNRECOVERY: Fatal error, run database recovery
[12/Sep/2013:20:51:50 -0400] - Failed to start database plugin ldbm database

First change to the database directory. By default it is in /var/lib/dirsrv/slapd-/db

Run:

sudo db_recover -c -f -v
  • Parameters
    • -c Perform catastrophic recovery instead of normal recovery.
    • -f Display a message on the standard output showing the percent of recovery completed.
    • -v Run in verbose mode.

Note: The db_recover utility must be run after an unexpected application, Berkeley DB, or system failure to restore the database to a consistent state. All committed transactions are guaranteed to appear after db_recover has run, and all uncommitted transactions will be completely undone.