Menu

Error JET_errBadLogSignature luego de recuperar un servidor Exchange 2000 mediante Disaster Recovery

25/07/2007 - Troubleshooting

Introducción

Preparando una replica de una implementación en producción para armar un laboratorio (y de paso actualizar documentáción de Disaster Recovery) me tope con un problema a la hora de recuperar un backup de un Mailbox Storage de Exchange.

El esquema era simple. Un solo Controlador de Dominio y un Servidor Miembro con Exchange 2000 Instalado.

Pasos Previos

Luego de recuperar el Controlador de dominio en una Virtual Machine (el siguiente artículo me ayudo mucho – How to move a Windows installation to different hardware – http://support.microsoft.com/kb/249694) realice una instalación de Exchange 2000 mediante el parámetro Disaster Recovery.

Ejecutar “setup.exe /disasterrecovery” permite realizar una nueva instalación de Exchange 2000 en un nuevo servidor (con el mismo Nombre Netbios), copiar todos los binarios y las entradas del registro, sin reescribir la información almacenada en Active Directory.

Una vez finalizado el setup con el parámetro /disasterrecovery se solicita recuperar un backup para levantar finalmente el servidor.

El servidor queda finalmente instalado. Todos los servicios quedan iniciados (incluyendo el Information Store), y, si las carpetas en donde se almacenaban los System Files (los exx.log, el exx.chk, los resx.log, etc…) existen al momento de iniciar el servicio Information Store, nuevos system files se crean. Dado que la información de ubicación y configuración de las bases de datos son almacenados en Active Directory, la misma configuración de Storage Groups, Mailbox Storages y Public Folder Storage aparecerá configurada en el servidor instalado con Disaster Recovery. La diferencia es que todas las bases aparecen con el Flag “Do not mount the store at start-up” (como se indica en http://support.microsoft.com/kb/285169) por ende no levantan al iniciar el Information Store.

Recuperando un backup del Servidor Exchange

Ya que el Information Store se encuentra corriendo, es posible recuperar un backup Online realizado con NTBackup o con alguna herramienta que realice el backup de los EDB y STM en caliente.

En mi caso el backup había sido realizado con la herramienta NTBackup de Windows 2000 Server por lo que se inició la recuperación de datos con esa herramienta. Cuando se realiza un Restore de una base de datos Exchange con NTBackup se deben especificar dos cosas

1. Si es o no es el último set de backup (es decir que, en el caso de tener un backup Full y varios Incrementales, se podría recuperar el backup, y luego los incrementales hasta el último archivo)
Cuando se marca el checkbox Last Backup Set, se procede a realizar un hard recovery de la base de datos. Esto es, hacer un replay de todos los transaction logs existentes en el folder donde existen los system files para el storage group que alberga la o las bases que se están recuperando (http://support.microsoft.com/kb/232938)

2. Indicar una carpeta en donde generará un archivo llamado restore.env con información de la recuperación (que bases fueron recuperadas, desde que Log se tiene que iniciar el hard recovery, etc)

El Problema

En mi caso estaba recuperando un Full Backup así que simplemente marqué Last Backup Set y definí una carpeta para recuperar ese archivo. Cuando terminó de recuperar, aparecieron inmediatamente errores -530 de ESE en el EventViewer indicando JET_errBadLogSignature.

Traté de ejecutar el comando “eseutil /cc x:path_indicado_en_ntbackup” con el mismo problema… JET_errBadLogSignature!

Solo para verificar algún problema de corrupción de logs corrí un “eseutil /ml exx” (donde exx indica el prefijo del storage group, por ej. E01 – http://support.microsoft.com/kb/248122) y nuevamente, cuando llegaba al último log … otra vez JET_errBadLogSignature!

¡Lo que no debe hacerse!

Ya que necesitaba (y bastante urgente, por cierto) realizar unas pruebas en el laboratorio, decidí correr un “eseutil /p x:pathtobasedatos.edb“. El problema de Eseutil /p es que realiza ya no un hard recovery, si no un hard repair. Dependiendo de la inconsistencia de la base de datos puede llegar a eliminar información (http://technet.microsoft.com/en-us/library/aa996773.aspx) y luego habría que correr un “eseutil /d x:pathtobasedatos.edb” además de un “isinteg -s servername -fix -test alltests” para asegurar que la base de datos es consistente tanto física como lógicamente (aunque MS Recomienda que esa base no debería ser más utilizada y se deberían mover las mailbox a otra base nueva, fresca y nunca reparada – con el método que sea – Exmerge, Move Mailbox, etc – pero debería ser desafectada)
Obviamente, estos dos últimos pasos no los realice por la celeridad del tema en cuestión.

Lo que tendría que haber hecho (¡que finalmente testee!)

La solución apareción en mi cabeza despues de restaurar en otro servidor, en otro entorno, una base de datos nueva y un replay de logs que se debió realizar por un E00.log corrupto!. La cuestión se debía a que los System Files generados por el inicio del Information Store (al no encontrar dichos archivos, IS los genera) tenían una firma diferente a los logs que se estaban recuperando desde el backup (por más que el backup sea full siempre te caen 1 o 2 logs dentro del respaldo)

Por ende se hizo lo siguiente.
1. Recuperé el servidor tal cual se indicó previamente. Al restaurar la base de datos, no marqué “Last Backup Set”.
2. Una vez finalizado paré el servicio de Information Store y moví el archivo exx.log, el archivo exx.chk, y algún que otro log exxffffff.log que estaba creado luego de la instalación de disasterrecovery. Estos archivos se encuentran en la ubicación que se puede determinar viendo las propiedades del Storage Group en el System Manager.
3. Si hubiesen logs adicionales correlativos a los logs recuperados y depositados en la carpeta temporal en donde reside el restore.env podría copiarlos a la carpeta de donde moví los archivos exx.log y exx.chk, etc.
4. en mi caso no había logs adicionales así que simplmenete corrí “eseutil /cc x:path_indicado_en_ntbackup” generando el restore que necesitaba. Con Eseutil /mh verifiqué que dicha base de datos ya se encontraba en modo Clean Shutdown (http://technet.microsoft.com/en-us/library/aa997795.aspx). Luego lo que restó fue subir el Information store lo que generó nuevos archivos exx.log y exx.chk evitando el problema de JET_errBadLogSignature.

Leave a Reply

Your email address will not be published. Required fields are marked *