Restoring a backup - slapd error

[Sharpey]

I am attempting to write a script to prove my backups are good & that I understand the process properly for when I have to do it for real.

I have a VM template with the same operating system & zimbra version of the install on the production server. The script then rsync's the most recent backup over /opt/zimbra.
It then edits some (possibly not all) of the configuration files and replaces the production server IP/Hostname with its own.

I worked through a few issues including using the well documented permissions problem, but I am now stuck at the following:

Output from running the command 'zmcontrol start'

zimbra@zimbratestvm ~]$ zmcontrol start
Host zimbratestvm.testdomain.com
Starting ldap...Done.
Failed.
Failed to start slapd. Attempting debug start to determine error.
backend_startup_one (type=hdb, suffix=""): bi_db_open failed! (-1)

Output from '/var/log/zimbra.log'

Jul 26 14:35:57 zimbratestvm slapd[26246]: hdb_db_open: database "": alock package is unstable.
Jul 26 14:35:57 zimbratestvm slapd[26246]: backend_startup_one (type=hdb, suffix=""): bi_db_open failed! (-1)
Jul 26 14:35:57 zimbratestvm slapd[26246]: slapd stopped.

Any suggestions appreciated,

I plan on releasing the script should anyone ever want to do anything similar in the future,

Cheers,
Sharpey

[uxbod]

Before starting up Zimbra try running as root

/opt/zimbra/libexec/zmfixperms --extended

[Sharpey]

Hi uxbod,

Cheers for the reply - unfortunately I had tried this and it hadn't worked.

Thanks,
Sharpey

[Houston]

i'm executing a migration of zimbra binary from a file system to another, with the TAR utility.
ldap doesn't start with the same error
Any idea??


I've try execute the command
#/opt/zimbra/libexec/zmfixperms -verbose -extended
no fix

I've try to set all file permission to 777 for test
# chmod -R 777 /opt/zimbra
no fix

FROM CONSOLLE
Host zldap01.sia.local
Starting ldap...Done.
Failed.
Started slapd: pid 7388
Error: Unable to check that slapd is listening to connections

FROM LOG
/var/log/zimbra.log
Jul 28 16:53:15 zldap01 slapd[7387]: @(#) $OpenLDAP: slapd 2.4.22 (Jun 10 2010 14:02:07) $ build@build11.lab.zimbra.com:/home/build/p4/main/ThirdParty/openldap/openldap-2.4.22.3z/servers/slapd
Jul 28 16:53:45 zldap01 slapd[7388]: hdb_db_open: database "": alock package is unstable.
Jul 28 16:53:45 zldap01 slapd[7388]: backend_startup_one (type=hdb, suffix=""): bi_db_open failed! (-1)
Jul 28 16:53:45 zldap01 slapd[7388]: slapd stopped.



Thank's in advantage

Dario

[phoenix]

Originally Posted by Houston

i'm executing a migration of zimbra binary from a file system to another, with the TAR utility.
ldap doesn't start with the same error
Any idea??

Which Migration article did you follow? Do you have valid DNS A & MX records and a valid and correct /etc/hosts file on your new server?

[Houston]

file hosts is ok and the DNS also
the system has worked ok until i've added a secondary nic for mounting a new NFS file system on SAN-NetApp on a dedicated VLAN.

in a server that worked ok i've made a tar of /opt/zimbra, changed the mount point to go over SAN and exploded the TAR

file hosts and DNS record not changed

Thanks

[Houston]

SOLVED

The problem was the file .snapshot created by NetApp in the file system. This file blocked the "/opt/zimbra/libexec/zmfixperms -verbose -extended" command.

Now the system works fine.

Many Thanks

[Sharpey]

Thanks for posting your solution Houston,

Unfortunately hasn't fixed it for me. I ran the "/opt/zimbra/libexec/zmfixperms -verbose -extended" succesfully, it reported that it fixed the permissions of various files.

[zimbra@clonesvr01 ~]$ zmcontrol start
Host clonesvr01.test.com
Starting ldap...Done.
Failed.
Failed to start slapd. Attempting debug start to determine error.
backend_startup_one (type=hdb, suffix=""): bi_db_open failed! (-1)


Anymore help appreciated,

Cheers,
Sharpey

[Houston]

if you have changed the server, make sure the file hosts contain the old reference with the new ip

ip_new old_fqdn old_host

[Sharpey]

I have added my test machine to DNS - its now all resolvable and the hosts file is filled out correctly.

Still no joy with the same error,

Cheers,
Sharpey