Restaurando un Servidor de correos Zimbra

Me he encontrado con diversos problemas a la hora de montar un servidor de backup del zimbra... Lo primero era salvar el directorio /opt/zimbra/, ¿pero quien se queda tranquilo solo con salvar ese directorio?,Hay que hacer pruebas de que en el momento necesario sabremos restaurarlo ....

Se me ocurrió preparar otra maquina cargar la copia de seguridad y comprobar que somos capaces de levantarla. Empiezo montando una maquina nueva con la misma versión del sistema operativo y la misma versión de zimbra, haciendo unas pequeñas modificaciones conseguí tener una maquina con el mismo nombre pero distinta ip y con un bind dns local resolviendo localmente las consultas dns mx todo de maravillas.

Ahora restauro el /opt/zimbra/ en su lugar y a disfrutar de un trabajo bien hecho :)
Pero no fue el caso ni de lejos, uno tras otro los intentos no salían y la frustración era mayor cuantas más veces lo hacia y todo el mundo en Internet decía que eso funcionaba, uf menos mal que esto no era un momento critico y la maquina de producción estaba operativa pero ... ???? y si mañana me cae el servidor de correo...

Pues al lío y a levantar el servidor de correo. El error que yo tenia y me costo mucho resolver....

Starting ldap...Done.
Failed.
Failed to start slapd.  Attempting debug start to determine error.
hdb_db_open: database "": db_open(/opt/zimbra/data/ldap/hdb/db/id2entry.bdb) failed: Invalid argument (22).
backend_startup_one: bi_db_open failed! (22)
bdb_db_close: database "": alock_close failed

En /var/log/zimbra.log este error muchas veces una tras otra

Aug 22 09:42:58 zimbra zimbramon[27757]: 27757:info: zmmtaconfig: Skipping Global system configuration update. 
Aug 22 09:42:58 zimbra zimbramon[27757]: 27757:info: zmmtaconfig: gacf ERROR: service.FAILURE (system failure: ZimbraLdapContext) (cause: javax.naming.CommunicationException zimbra.midominio.com:389)  
Aug 22 09:42:59 zimbra slapd[31709]: @(#) $OpenLDAP: slapd 2.4.17 (Aug  2 2009 16:12:41) $     build@build11.lab.zimbra.com:/home/build/p4/main/ThirdParty/openldap/openldap-2.4.17.8z/servers/slapd 
Aug 22 09:43:00 zimbra slapd[31734]: bdb(): file id2entry.bdb has LSN 3/8231503, past end of log at 3/8158347 
Aug 22 09:43:00 zimbra slapd[31734]: bdb(): Commonly caused by moving a database from one database environment 
Aug 22 09:43:00 zimbra slapd[31734]: bdb(): to another without clearing the database LSNs, or by removing all of 
Aug 22 09:43:00 zimbra slapd[31734]: bdb(): the log files from a database environment 
Aug 22 09:43:00 zimbra slapd[31734]: bdb(): /opt/zimbra/data/ldap/hdb/db/id2entry.bdb: unexpected file type or format 
Aug 22 09:43:00 zimbra slapd[31734]: hdb_db_open: database "": db_open(/opt/zimbra/data/ldap/hdb/db/id2entry.bdb) failed: Invalid argument (22). 
Aug 22 09:43:00 zimbra slapd[31734]: backend_startup_one: bi_db_open failed! (22) 
Aug 22 09:43:00 zimbra slapd[31734]: bdb_db_close: database "": alock_close failed 
Aug 22 09:43:00 zimbra slapd[31734]: slapd stopped.

Para resolver este problema mi solución restaurar el ldap de la copia.

# cp /opt/zimbra/data/ldap/ldap.bak /tmp/.
# cp /opt/zimbra/data/ldap/ldap-config.bak /tmp/.
# /opt/zimbra/openldap/sbin/slapadd -q -b "" -F /opt/zimbra/data/ldap/config -cv -l /tmp/ldap.bak
# /opt/zimbra/openldap/sbin/slapadd -q -n 0 -F /opt/zimbra/data/ldap/config -cv -l /tmp/ldap-config.bak
# chown zimbra:zimbra -R /opt/zimbra/data/ldap/hdb/ 

Como aun tenia el servidor de producción genere el ldap.bak  y ldap-config.bak lo más actualizado posible y copiarlos al nuevo servidor.

Para generar la copia de seguridad del ldap y copia de la configuración.

# su zimbra
$ /opt/zimbra/libexec/zmslapcat /opt/zimbra/data/ldap/
$ /opt/zimbra/libexec/zmslapcat -c /opt/zimbra/data/ldap/ 

Ahora esta orden esta diaria antes del respaldo rsync de /opt/zimbra/ en producción