[SOLVED] LDAP / slapd - Database environment corrupt (Issue & Solution)

I have to add, that I can db_recover the oldish backup:

Code:

---

zimbra@zimbra:~$ tar xfj openldap-data-20080830.tbz
zimbra@zimbra:~$ cd openldap-data
zimbra@zimbra:~/openldap-data$ /opt/zimbra/sleepycat/bin/db_recover -c
zimbra@zimbra:~/openldap-data$ /opt/zimbra/sleepycat/bin/db_recover 
zimbra@zimbra:~/openldap-data$ ls logs/
log.0000000228  log.0000000229

---

But after a while the ldap seems to write the next log file (log.0000000191) and chokes on that one afterwards. Maybe because of different versions of the BDB database.

However, I'm lost.

-jsl

Quote:

---

Originally Posted by jsilence

Code:

---

Sep  8 09:06:02 zimbra slapd[4207]: bdb(): Ignoring log file: /opt/zimbra/openldap-data/logs/log.0000000191: magic number 0, not 40988
Sep  8 09:06:02 zimbra slapd[4207]: bdb(): Invalid log file: log.0000000191: Invalid argument
Sep  8 09:06:02 zimbra slapd[4207]: bdb(): First log record not found
Sep  8 09:06:02 zimbra slapd[4207]: bdb(): PANIC: Invalid argument
Sep  8 09:06:02 zimbra slapd[4207]: bdb_db_open: Database cannot be recovered, err -30978. Restore from backup!
Sep  8 09:06:02 zimbra slapd[4207]: bdb(): DB_ENV->lock_id_free interface requires an environment configured for the locking subsystem
Sep  8 09:06:02 zimbra slapd[4207]: bdb(): txn_checkpoint interface requires an environment configured for the transaction subsystem
Sep  8 09:06:02 zimbra slapd[4207]: bdb_db_close: txn_checkpoint failed: Invalid argument (22)
Sep  8 09:06:02 zimbra slapd[4207]: backend_startup_one: bi_db_open failed! (-30978)
Sep  8 09:06:02 zimbra slapd[4207]: bdb_db_close: alock_close failed
Sep  8 09:06:02 zimbra slapd[4207]: slapd stopped.

---

---

Are you using a VM such as Xen instead of real hardware?

And yes, you must use

Code:

---

-b ''

---

as part of your slapadd command.

Yes I am running Zimbra in a VMWare virtual Machine. Ubuntu JeOS on a VMWare Server 1.0.4. So far it was running pretty smooth.

I will try -b '' tonight and report.

Thanks,

-jsl

Up until now, starting from my latest recuing attempt, the system is running smoothly.

After a restore from the oldish backup, including slapadd action with the latest ldif dump, I did a 'db_upgrade' in the openldap-data directory. It came back without any output, but I have the impression, that this did the trick for me.

Keeping my fingers crossed, thanks for helping...

-jsl

I just keep having customers do 'customer' stuff... and then I visit the forums to figure out what they have 'customer'd' up! This was also a power loss. I followed everything and this is what happened..

1. # su - zimbra
2. $ ldap stop
3. $ cd /opt/zimbra/openldap-data
4. $ /opt/zimbra/sleepycat/bin/db_recover
... Still get all the Panic stuff
Then...
1. # su - zimbra
2. $ ldap stop
3. $ exit
4. # mv /opt/zimbra/openldap-data /opt/zimbra/openldap-01-19-2009-crash
5. # mkdir /opt/zimbra/openldap-data
6. # cp /opt/zimbra/openldap-data-01-19-2009-crash/DB_CONFIG /opt/zimbra/openldap-data/DB_CONFIG
7. # chown -R zimbra:zimbra /opt/zimbra/openldap-data
8. # su - zimbra
9. $ ~/openldap/sbin/slapadd -w -q -f ~/conf/slapd.conf -l /opt/zimbra/backup/sessions/incr-20090118.xx.x.x.x.x./ldap.bak
10. $ ~/openldap/sbin/slapindex -f ~/conf/slapd.conf
11. $ ldap start

This still didn't work..

So, now that I know exactly where the backup stuff is (because of step 9) and thinking that I was not far away from having to copy that backup data and wipe this box, I copied the stuff in /opt/zimbra/backup/sessions/incr-20090118.xxx.xxx/ldap/ (file path was a little different from the example.. and I can't remember the version they were on). Basically, I copied the db directory (which was empty) from the crashed copy and I copied the logs dir from the crashed copy.. both went into the newly populated /opt/zimbra/openldap-data directory. I did number 7 again.. then I did the below

1. cd /opt/zimbra/openldap-data
2. e/opt/zimbra/sleepycat/bin/db_recover

Which is exactly what I did to begin with. Then...
zmcontrol start
.. and it worked...

So I basically made sure my old ldap-data directory was out of the way.. used these commands (lines 5-10) to get as much fresh.. get the rest from backups and it worked..

It was a little different than spelled out.. so I thought I would share.

Thanks to everyone that jumps in the forums and writes all this stuff down!

Well done and a special blessing to all those customers (that keep us employed).

Was this a master server rather than a replica? What release?

Release 5.0.5_GA_2201.UBUNTU6 UBUNTU6 NETWORK edition

Just a single server...

Someone knows what to do if db_recover doesn't work.

The problem is that the server configuration cn=mx01.xxxxx.com,cn=servers,cn=zimbra registry is truncated. I tried to modify or delete it using ldapmodify but I'm getting the following error:

deleting entry "cn=mx01.xxxxx.com,cn=servers,cn=zimbra"
ldapmodify: Internal (implementation specific) error (80)
additional info: internal error

The database has corrupted after a power fail. Trying to cat ldap db I'm gettint:

Code:

---

openldap/sbin/slapcat -f /opt/zimbra/conf/slapd.conf

---

entry_header: attribute count was zero

I could cat (not everything) doing

Code:

---

ldapsearch -h localhost -x -D "uid=zimbra,cn=admins,cn=zimbra" -w password

---

I will appreciate any kind of idea.

Dear all,

just read another article about DB recovery from :

http://www.zimbra.com/forums/adminis...-solution.html

and i'm wondering if these steps also work in open source edition, since it use the ldap.bak from NE edition's daily backup?

any advice on this? Thanks.

Code:

---

# su - zimbra
$ ldap stop
$ exit
# mv /opt/zimbra/openldap-data /opt/zimbra/openldap-data-0704-crash
# mkdir /opt/zimbra/openldap-data
# cp /opt/zimbra/openldap-data-0704-crash/DB_CONFIG /opt/zimbra/openldap-data/DB_CONFIG
# chown -R zimbra:zimbra /opt/zimbra/openldap-data
# su - zimbra
$ ~/openldap/sbin/slapadd -w -q -f ~/conf/slapd.conf -l /opt/zimbra/backup/ldap/incr-20070704.080005.554/ldap.bak
$ ~/openldap/sbin/slapindex -f ~/conf/slapd.conf
$ ldap start

---