Quote:
Originally Posted by greenrenault  Detailed below is both the issue and solution when the LDAP database becomes corrupt. Posting here to help others as I had to raise this with Zimbra support for an answer, which worked!
-------------------- Our Issue --------------------
Our Zimbra server lost power recently and as a result performed an unexpected halt. When Zimbra restarted the slapd database was corrupt and LDAP server would not start at all. Investigation revealed that the LDAP log file had become corrupt. So the log file was moved to a temporary directory and Zimbra restarted. Zimbra started up OK however now the following errors were consistently displayed in the Zimbra log. |
The instructions here are wrong, and what you did was incorrect. As a result, you forced yourself into a situation requiring you to restore from backup.
What you should have done was made sure slapd wasn't running (which of course it likely wasn't), and then
Code:
cd /opt/zimbra/openldap-data
/opt/zimbra/sleepycat/bin/db_recover
This will *recover* the database and checkpoint out the logs. If at that point, they still remain corrupt, then yes you would have to take the steps in your post, but that should only be done as a last resort.
Also, if it is a master, the accesslog database will also need to be recovered:
Code:
cd /opt/zimbra/openldap-data/accesslog/db
/opt/zimbra/sleepycat/bin/db_recover
in that case.
If you are trying to restore from a backup on a master, you'll need to make sure the accesslog directory structure exists first (see the zmldapenablereplica script), and you'll need to make sure you select the correct database when doing slapadd (The -b '' flag).
Just moving aside the log files and starting slapd will forever destroy the database when it may otherwise have been recoverable without resorting to backups.
--Quanah