Disaster Recovery en Exchange 2010

Hola a tod@s! 

Esta semana os traemos un post sobre escenarios de “disaster recovery” en Exchange 2010. Exchange 2010 ha incluido numerosos cambios de arquitectura que nos ayudaran a minimizar el tiempo que nuestro servicio no está operativo, concretamente vamos a tratar la opción de “Database Portability”, la habilidad de Exchange 2010 de montar una base de datos en un servidor cualquiera de la organización.

Como es habitual, nuestra recomendación pasa por tener un DAG en nuestra organización y así tener alta disponibilidad de las bases de datos en nuestra organización, pero por desgracia esto no siempre es posible.

Vamos a plantear un escenario. En nuestra organización tenemos un servidor de buzones que llamaremos Mbx1. En este servidor tenemos una base de datos con buzones de usuarios llamada Mbx1Db1. Por un problema de hardware, nuestro servidor Mbx1 deja de funcionar y los usuarios pierden el acceso al correo. Algunos de los usuarios siguen teniendo acceso a sus antiguos correos porque trabajan con Outlook en modo cache, pero se han quedado sin la opción de enviar y recibir nuevos correos.

El estado del servidor Mbx1 puede ser grave, y desconocemos el tiempo que puede llevarnos recuperarlo, por lo que más importante ahora es devolver a los usuarios la capacidad de enviar y recibir correos de nuevo. Para ello, vamos a hacer uso de un segundo servidor de buzones de nuestra organización Mbx2.

1. El primer paso es crear una nueva base de datos Mbx2Db1 en Mbx2 donde alojar a los usuarios afectados de Mbx1Db1. Para ello, desde el Exchange Management Shell ejecutaremos:

New-MailboxDatabase -Name "Mbx2Db1" -EdbFilePath D:\DatabaseFiles\Mbx2Db1\Mbx2Db1.edb –LogFilePath E:\LogFiles\Mbx2Db1\

2. Lo siguiente que haremos será indicar a los usuarios de Mbx1Db1 que pasen a utilizar Mbx2Db1. Este proceso lo conocemos como “Rehoming”. Es similar a un movimiento de buzones, excepto que solo afecta a la configuración del buzón en directorio activo

Get-Mailbox -Database Mbx1Db1 | ?{$_.ObjectClass -NotMatch '(SystemAttendantMailbox|ExOleDbSystemMailbox)'} | Set-Mailbox -Database Mbx2Db1

En este punto los usuarios podan pasar a trabajar con un buzón temporal. Es importante saber que al trabajar con un buzón temporal, los ficheros ost donde Outlook guarda los correos son eliminados, por lo que puede ser interesante que los usuarios sigan trabajando con Outlook en modo desconectado y utilizen OWA para recibir y enviar correos

3. En estos momentos nos interesa revisar las colas de nuestros servidores Hub, ya que los correos destinados a Mbx1Db1 pueden encontrarse ahí. Si tras un reinicio del servicio de transporte los correos no se envían a la nueva base de datos, puede sernos de utilidad el post Cómo exportar los correos de las colas en Exchange 2010. Una vez exportados los correos a ficheros .eml podemos dejarlos en la carpeta pickup del servidor para que se envíen.

4. Ahora llega la hora de recuperar los elementos que había en Mbx1Db1. Para ello, haremos uso de una base de datos de recuperación desde la que copiar los distintos elementos a nuestra base de datos Mbx2Db1. Para crearla haremos:

New-MailboxDatabase -Recovery -Name Mbx1Db1RDB -Server MBX2 -EdbFilePath "D:\DatabaseFiles\Mbx1Db1RDB\Mbx1Db1RDB.EDB" -LogFolderPath "E:\LogFiles\Mbx1Db1RDB"

5. Nos aseguramos que esta base de datos esta desmontada y con la opción de
permitir que sea reescrita por un backup. Si está montada, podemos desmontarla
con:

Get-MailboxDatabase Mbx1Db1RDB | Dismount-Database

Para asegurarnos que puede ser reescrita, ejecutamos:

Get-MailboxDatabase Mbx1Db1RDB | Set-MailboxDatabase –AllowFileRestore $true

Si la base de datos estaba montada, habrá ficheros en las carpetas de logs y edb que tendremos que eliminar

6. Nuestra antigua información está localizada en tres puntos distintos, Backup, el fichero edb original del servidor Mbx1 y los ficheros de log de Mbx1. Si queremos tener la absoluta seguridad de no perder nada de información necesitamos los ficheros de log originales. Con un poco de suerte a estas alturas aunque Mbx1 no esté operativo, sí que tengamos acceso a los datos.
Veremos las distintas opciones que hay:

a. Tenemos acceso al fichero edb y los logs originales. Este es el escenario más sencillo. Con el comando eseutil /mh mbx1db1.edb podemos comprobar el estado de la base de datos, Clean Shutdown o Dirty Shutdown. Si el fichero está en Clean Shutdown lo copiamos renombramos a Mbx1Db1RDB.edb y lo copiamos en la ruta indicada en el paso 4 y pasamos al paso 7. Si la base de datos está en Dirty Shutdown, tendremos que aplicar los logs pendientes para llevar la base de datos a un estado consistente. Si hemos copiado los ficheros a la carpeta F:\DatabaseFiles\Mbx1Db1\ y F:\LogFiles\Mbx1Db1 ejecutamos:

Eseutil /r EXX /l F:\LogFiles\Mbx1Db1 /d F:\DatabaseFiles\Mbx1Db1

 
b. Tenemos un backup y los ficheros de log originales. En este caso, utilizaremos nuestra herramienta de backup para recuperar la base de datos Mbx1Db1 en la base de recuperación Mbx1Db1RDB. Es importante en este punto indicar al software de backup que solo recupere los ficheros, pero no intente aplicar los logs. Normalmente esto se consigue desmarcando la opción que indica que este es el último backup y que no intente montar la base de datos. Una vez hecho esto, localizamos el fichero restore.env generado por la herramienta de backup y en esa carpeta localizaremos unos ficheros de logs que empiezan por RXX. Copiamos nuestros ficheros de logs a esa carpeta y desde esa ubicación ejecutamos:

Eseutil /cc

Esto aplicará los logs pendientes que ha traído tanto el backup como aquellos posteriores que hemos copiado nosotros

c. Tenemos un backup, pero no tenemos acceso a los logs originales. Muy similar al punto anterior, solo que en este caso no tendremos ficheros adicionales que suministrar antes de ejecutar Eseutil /cc, por lo que perderemos la información desde el momento de realizar el backup hasta el fallo en Mbx1. Si indicamos a la herramienta de backup que este él es último backup que tenemos a la hora de restaurarlo, esta se encarga de aplicar los logs de tipo RXX por nosotros, haciendo innecesaria la ejecución de Eseutil /cc

 d. Tenemos el fichero edb original, pero no tenemos ni logs ni backup. Cuando el fichero edb original está presente, pero no podemos utilizar los logs originales para llevarla a un estado consistente, podemos utilizar la opción de reparación de eseutil. Esta opción es bastante agresiva y eliminará las páginas inconsistentes hasta dejar la base de datos en Clean Shutdown. Con suerte no perderemos información, pero podemos llegar a perder grandes cantidades de información o incluso quedarnos con una base de datos no usable por Exchange. La ejecución de esta opción impide que más adelante hagamos uso de la recuperación con los logs, por lo que es una buena idea ejecutarlo sobre una copia del fichero edb:

Eseutil /p Mbx1Db1.edb

Tras ejecutar esta reparación es necesario ejecutar una defragmentación offline del fichero, un proceso bastante lento, mediante:

Eseutil /d Mbx1Db1.edb

Una vez finalizado, copiamos este fichero a la ruta del paso 4 con el nombre Mbx1Db1RDB.edb

e. Disponemos únicamente de los ficheros de logs originales. Lo más probable en este escenario tengamos que asumir la pérdida de datos, pero todavía nos queda una posibilidad. Para que esto funcione tenemos que tener la secuencia completa de logs desde que se creó la base de datos, del primero al último. Es decir, que el log EXX00001.log no corresponda a un momento en el se desmontó la base de datos y se comenzó de nuevo la secuencia. De ser este el caso, podemos indicar al servidor que reconstruya el fichero edb original reaplicando todas las operaciones presentes en los logs. Para ello nos situamos en la carpeta donde hemos copiado los logs, eliminamos el fichero de checkpoint (extensión .chk) y ejecutamos

Eseutil /r EXX /d /i

Esto nos generará un fichero Mbx1Db1.edb en la propia carpeta de logs que podremos renombrar y situar en la ruta del paso 4. No es necesario que copiemos los logs.

 7. En este punto vamos a proceder a combinar los datos Mbx2Db1 (que contiene los elementos posteriores al fallo de Mbx1) con Mbx1Db1RDB (que contiene los datos anteriores). Normalmente el fichero edb de Mbx1Db1RDB es mucho mayor que Mbx2Db1, por lo que para acelerar el proceso podemos utilizar un pequeño truco que consiste en desmontar Mbx2Db1 e intercambiar los ficheros edb correspondientes a cada base de datos, ya sea moviendo los ficheros en el disco o las rutas a las que apuntan las bases de datos. Es muy importante no hacer esto si hemos recuperado los datos mediante una reparación (el punto d del paso 6) . Hacer esto solo si tenéis experiencia en este tipo de cambios y escenarios de DialTone o estais trabajando con un ingeniero de soporte de Microsoft.

 
8. Montamos la base de datos Mbx1Db1RDB con:

Get-MailboxDatabase Mbx1Db1RDB | Mount-MailboxDatabase

9. Procedemos a combinar los elementos de las dos bases de datos, moviendo aquellos elementos de Mbx1Db1RDB a Mbx2Db1:

Get-Mailbox -Database Mbx2Db1 | ?{$_.ObjectClass -NotMatch '(SystemAttendantMailbox|ExOleDbSystemMailbox)'} | Restore-Mailbox –RecoveryDatabase Mbx1Db1RDB

Este cmdlet procederá a combinar los elementos de todos los buzones presentes en Mbx2Db1. 

10. Realizamos un backup completo de Mbx2Db1

Con esta guía hemos visto muchas áreas del proceso de recuperación de bases de datos cuando no trabajamos con DAG. En nuestro escenario hemos utilizado dos servidores, Mbx1 y Mbx2, pero la guía también es válida si solo hemos tenido un fallo de discos y realizamos todo el proceso de DialTone sobre el propio Mbx1. También hemos cubierto una sola base de datos, pero podríamos aplicarlas sobre todas las bases de datos de Mbx1 si es un problema en el arranque del servidor.

Espero sinceramente que nunca tengáis que hacer uso de la información de este artículo 

Saludos,

David