Zimbra uses OpenLDAP for its directory, and after way too much fiddling with domains, we ended up corrupting our database.  There was a partial “.net” entry in our LDAP that we couldn’t remove.  So, we decided to dump the LDAP contents into a file, edit the file, and re-import it into LDAP.

Using slapcat as described on the Zimbra wiki’s article for replication unfortunately didn’t work because slapcat doesn’t handle bad LDAP entries well.  However, ldapsearch happily dumps the full LDAP directory to a file.  So combining the instructions from the replication article with this Zimbra forum entry on ldap recovery, I ended up with the following steps:

# First dump the running LDAP directory into a file
su — zimbra
ldapsearch ‑x ‑H ‘ldap://MAIL.COMPANY.COM/’ ‑w YOUR_PASSWORD ‑D uid=zimbra,cn=admins,cn=zimbra > /tmp/backup.ldif
ldap stop
exit

# Now backup the data directory and initialize a new directory
mv /opt/zimbra/openldap-data /opt/zimbra/openldap-data-old
mkdir ‑p /opt/zimbra/openldap-data/logs
cp /opt/zimbra/openldap-data-old/DB_CONFIG /opt/zimbra/openldap-data
chown ‑R zimbra:zimbra /opt/zimbra/openldap-data/

# Now edit the entries in /tmp/backup.ldif, and remove
# the last two lines the refer to “search”
vi /tmp/backup.ldif

# Now restore the LDAP from the file, looking for errors
su — zimbra
/opt/zimbra/openldap/sbin/slapadd ‑w ‑q ‑b ” ‑f /opt/zimbra/conf/slapd.conf ‑l /tmp/backup.ldif
ldap start

And if you edited backup.ldif correctly, any bad entries should be gone.  If things get messed up, stop ldap and move the /opt/zimbra/openldap-data-old directory back.