¿Cómo volver a cargar después de que la copia de la base de datos del buzón falle y se suspenda?

En un Exchange Server independiente, no basta con garantizar la continuidad del negocio. Para los requisitos de conmutación por error y continuidad empresarial, puede utilizar los grupos de disponibilidad de bases de datos (DAG) de Microsoft para garantizar que su Exchange Server siga funcionando si falla una instancia. Para que esto funcione, necesitaría dos o más servidores para conseguir un DAG, con Microsoft Exchange Server Standard o Enterprise edition. La decisión de elegir la edición Standard o Enterprise depende totalmente del diseño y el volumen de los buzones de correo.

Si no necesita más de cinco bases de datos de buzones, puede optar por la edición Standard. En cuanto a las licencias, debe adquirir Exchange Server Standard/Enterprise para cada servidor. En cuanto a las licencias de acceso de usuario (CAL), sólo tendrá que adquirirlas una vez.

A continuación se ilustra un Grupo de Disponibilidad de Base de Datos (DAG) típico, con dos Servidores Exchange y un servidor File Share Witness, con quórum y mayoría de votos.

Cuando se crean Grupos de Disponibilidad de Bases de Datos (DAG), se tiene una copia de una base de datos en un servidor y una copia pasiva en otro servidor. Así, la copia activa es siempre a la que se accede y la otra base de datos se replica a partir de ella.

En la siguiente ilustración, puede ver que hay dos bases de datos donde la copia activa de DB1 está en el Servidor EX01 y la copia pasiva está en el Servidor EX02. Y la copia activa de DB2 está en el Servidor EX02 y la copia pasiva está en el Servidor EX01. Y la copia activa de DB2 está en el Servidor EX02 y la copia pasiva está en el Servidor EX01.

Cuando añada una nueva base de datos de buzones a un grupo de disponibilidad de bases de datos (DAG), primero deberá realizar una copia en el segundo servidor (en el caso de nuestra ilustración, se trata de EX02). Una vez finalizada la copia completa, que se denomina primera semilla, el grupo de disponibilidad de bases de datos (DAG) seguirá replicando los cambios. También puede hacerlo tomando una copia de la base de datos y copiándola en el servidor secundario. Todo depende del tamaño y la velocidad de la red entre los dos nodos.

A veces, debido a problemas de hardware o software, es necesario volver a sembrar la base de datos. Esto puede deberse a que la información de la copia de la base de datos esté dañada o a que se haya producido un error en la base de datos que haya hecho que la copia no pueda ser utilizada por el grupo de disponibilidad de bases de datos (DAG).

Durante la siembra, podría encontrar un problema con la base de datos pasiva y la siembra se detiene con el error “Mailbox Database Copy Failed or Suspended”. Tras la investigación, encontrará el siguiente mensaje en el visor de sucesos.

MSExchangeRepl ID de evento: 4113

Fallo en la comprobación de la redundancia de la base de datos. Copia de base de datos: DB01 Recuento de redundancia:1

Error: La copia pasiva ‘DB01\EX02’ no está en buen estado. Estado: FailedAndSuspended

Para iniciar la solución de problemas, primero debe obtener el estado de la copia desde Exchange Management Shell (EMS) mediante el cmdlet de PowerShell – Get-MailboxDatabaseCopyStatus.

Para comprender la causa raíz del problema, puede utilizar el Analizador de mejores prácticas de Exchange contra los servidores. Desde Exchange Management Shell (EMS), ejecute Test-ServiceHealth y Test-ReplicationHealth. Esto le dará la información de que todos los servicios necesarios se están ejecutando. Por supuesto, también puede ejecutar una autocomprobación en los servidores Exchange.

Intentemos reparar la base de datos suspendiendo la copia entre la base de datos activa y la pasiva. Esto se puede hacer utilizando el comando Suspend-MailboxDatabaseCopy.

Suspender-CopiaBaseDatosBuzón -Identidad “DB01\EX01”

Aquí es donde puede investigar el asunto. Es necesario volver a sembrar la base de datos. Para empezar, necesita limpiar cualquier copia de la base de datos. Puede utilizar el cmdlet de PowerShell Update-MailboxDatabaseCopy con la opción -DeleteExistingFiles para limpiar la configuración y eliminar las copias. A continuación se muestra un ejemplo del comando:

Update-MailboxDatabaseCopy -Identity “DB01\EX01” -DeleteExistingFiles

De este modo, la base de datos volverá de la copia activa a la pasiva.

Algunas cosas a tener en cuenta antes de ejecutar el proceso de resiembra:

• Dependiendo del tamaño de la base de datos, el rendimiento de los servidores y la velocidad de la red entre los nodos, el proceso puede llevar un tiempo considerable.
• Si tiene más de dos servidores, el comando PowerShell tomará la copia activa de la base de datos. No se puede elegir desde dónde se vuelve a sembrar la copia.
• Habrá una diferencia de tamaño entre la copia activa y la pasiva, ya que la copia tendrá el tamaño de la base de datos junto con el archivo adicional de registro de transacciones y el índice de contenido.

Como alternativa, puede volver a sembrar la base de datos mediante el Centro de administración de Exchange (EAC).

Por esto,

• Haga clic en la sección Servidor y en el nodo Base de datos.
• Seleccione la base de datos que desea actualizar y haga clic en el botón Actualizar para iniciar el proceso de resiembra.
• Seleccione el origen de la base de datos activa y el destino.

Conclusión

El proceso anterior puede ayudarle a eliminar el error “Error y suspensión de la copia de la base de datos del buzón”. Pero, ¿qué hacer si el problema se repite? ¿Qué ocurre si la copia activa está dañada y necesitas recuperar los datos de la copia? ¿O qué ocurre si tanto la copia activa como la pasiva están dañadas?

Puede confiar en una herramienta de recuperación de bases de datos de Exchange de terceros que pueda sacarle de estas situaciones difíciles. Stellar Repair for Exchange es una de esas aplicaciones que puede abrir cualquier tipo de base de datos de Exchange esté sana o no, recuperar los datos a PST y otros formatos. También puede exportar directamente a una nueva base de datos de buzones de Exchange o a un inquilino de Office 365.

Was this article helpful?

YES0

NO

Sobre el autor

Himanshu Shakya

Himanshu is a Tech Enthusiast and Blogger at Stellar, with expertise in data recovery solutions and a keen interest in emerging technologies. Fluent in Japanese, he brings a diverse skill set to his role, contributing to global tech conversations. Outside of work, Himanshu enjoys playing chess, sharpening his strategic thinking and problem-solving skills in his spare time.