Administración de copias de base de datos de buzones

SE APLICA A:2016 2019 Subscription Edition

En Exchange Server, puede usar el Consola de administración de Exchange (EAC) o el Shell de administración de Exchange para agregar copias de base de datos de buzones después de crear, configurar y rellenar un grupo de disponibilidad de base de datos (DAG) con miembros del servidor buzón.

Administración de copias de bases de datos

Una vez creadas varias copias de una base de datos, puede usar el EAC o el Shell de administración de Exchange para realizar las siguientes tareas:

• Supervise el estado y el estado de cada copia.
• Realice otras tareas de administración asociadas a copias de base de datos. Por ejemplo:
  • Suspenda o reanude una copia de base de datos.
  • Inicializar una copia de base de datos.
  • Supervisión de copias de base de datos.
  • Configuración de la copia de base de datos
  • Quite una copia de base de datos.

Suspensión y reanudación de las copias de base de datos

Por diversos motivos, como realizar un mantenimiento planeado, es posible que tenga que suspender y reanudar la actividad de replicación continua para una copia de base de datos. Además, algunas tareas administrativas, como la propagación, requieren que primero suspenda una copia de base de datos. Se recomienda suspender toda la actividad de replicación cuando se cambie la ruta de acceso de la base de datos o sus archivos de registro. Puede suspender y reanudar la actividad de copia de la base de datos mediante el EAC o ejecutando los cmdlets Suspend-MailboxDatabaseCopy y Resume-MailboxDatabaseCopy en el Shell de administración de Exchange. Para obtener instrucciones detalladas acerca de cómo suspender o reanudar la actividad de replicación continua de una copia de base de datos, vea Suspensión o reanudación de una copia de base de datos de buzones.

Inicialización de una copia de base de datos

La propagación, también conocida como actualización, se produce cuando se agrega una base de datos en blanco o una copia de la base de datos de producción a la ubicación de copia de destino de otro servidor de buzones en el mismo DAG que la base de datos activa. Esta base de datos se convierte en la base de datos de línea base para la copia mantenida por ese servidor.

En función de la situación, puede inicializar una base de datos mediante un proceso automático o un proceso manual que inicie. Cuando se agrega una copia de base de datos, la copia se inicializa automáticamente, si el servidor de destino y su almacenamiento están configurados correctamente. Para inicializar manualmente una copia de base de datos y no desea que se produzca la propagación automática al crear la copia, puede usar el parámetro SeedingPostponed en el cmdlet Add-MailboxDatabaseCopy .

Rara vez es necesario volver a sembrar copias de base de datos después de la propagación inicial. Sin embargo, si es necesario volver a sembrar, o para inicializar manualmente una copia de base de datos en lugar de que el sistema inicializa automáticamente la copia, tiene dos opciones:

• Use el Asistente para actualizar copia de base de datos de buzones en el EAC.
• Use el cmdlet Update-MailboxDatabaseCopy en el Shell de administración de Exchange.

Antes de inicializar una copia de base de datos, primero, debe suspender la copia de base de datos de buzones de correo. Para obtener instrucciones detalladas acerca de cómo reinicializar una copia de la base de datos, vea Actualización de una copia de la base de datos de buzones.

Una vez completada una operación de inicialización manual, se reanuda automáticamente la replicación de la copia de base de datos del buzón de correo inicializado. Si no desea que la replicación se reanude automáticamente, puede usar el parámetro ManualResume en el cmdlet Update-MailboxDatabaseCopy .

Selección de elementos para inicializar

Al realizar una operación de inicialización, puede elegir:

• Inicializar la copia de la base de datos del buzón.
• Inicializar el catálogo de índices de contenido para la copia de la base de datos de buzón de correo.
• Inicializa tanto la copia de base de datos como la copia del catálogo de índices de contenido.

El comportamiento predeterminado del Asistente para actualizar copias de bases de datos de buzones de correo y el cmdlet Update-MailboxDatabaseCopy es inicializar la copia de base de datos de buzones de correo y la copia del catálogo del índice de contenido.

Para inicializar solo la copia de base de datos de buzón sin inicializar el catálogo de índices de contenido, use el parámetro DatabaseOnly en el cmdlet Update-MailboxDatabaseCopy .

Para inicializar solo la copia del catálogo de índices de contenido, use el parámetro CatalogOnly en el cmdlet Update-MailboxDatabaseCopy .

Selección del origen de inicialización

Puede usar cualquier copia de base de datos correcta como origen de propagación para otra copia de esa base de datos. Esta opción es especialmente útil cuando tiene un DAG extendido en varias ubicaciones físicas.

Por ejemplo, tenga en cuenta la siguiente implementación de DAG de cuatro miembros:

• MBX1 y MBX2 se encuentran en Portland, Oregón.
• MBX3 y MBX4 se encuentran en Nueva York, Nueva York.
• Una base de datos de buzón denominada DB1 está activa en MBX1.
• Hay copias pasivas de DB1 en MBX2 y MBX3.

Al agregar una copia de DB1 a MBX4, puede usar la copia en MBX3 como origen para la propagación. Esta opción evita la propagación a través del vínculo de red de área extensa (WAN) entre Portland y Nueva York.

Para usar una copia específica como origen para la propagación al agregar una nueva copia de base de datos, puede realizar los pasos siguientes:

• Use el parámetro SeedingPostponed en el cmdlet Add-MailboxDatabaseCopy para agregar la copia de la base de datos. De lo contrario, la copia de base de datos se inicializa explícitamente mediante la copia activa de la base de datos como origen.

• Puede especificar el servidor de origen que se va a usar en el Asistente para actualizar copia de base de datos de buzones en el EAC, o bien puede usar el parámetro SourceServer en el cmdlet Update-MailboxDatabaseCopy para especificar el servidor de origen deseado para la propagación.

  En el ejemplo anterior, especificaría MBX3 como servidor de origen. De lo contrario, la copia de la base de datos se inicializa explícitamente desde la copia activa de la base de datos.

Inicialización y redes

Además de seleccionar un servidor de origen específico para inicializar una copia de base de datos de buzón de correo, también puede usar el Shell de administración de Exchange para especificar qué redes dag usar. Puede invalidar la configuración de compresión y cifrado de la red DAG durante la operación de inicialización.

Puede especificar las redes que se van a usar para la propagación mediante el parámetro Network en el cmdlet Update-MailboxDatabaseCopy y especificar las redes de DAG que desea usar. Si no usa el parámetro Network , el sistema usa el siguiente comportamiento predeterminado para seleccionar una red que se usará para la operación de propagación:

• Si el servidor de origen y el servidor de destino están en la misma subred y se configura una red de replicación que incluye la subred, se usa la red de replicación.

• Si el servidor de origen y el servidor de destino están en subredes diferentes, incluso si se configura una red de replicación que contiene esas subredes, se usa la red de cliente (MAPI) para la propagación.

• Si el servidor de origen y el servidor de destino están en centros de datos diferentes, se usa la red de cliente (MAPI) para la propagación.

En el DAG, las redes del DAG están configuradas para cifrado y compresión. La configuración predeterminada usa el cifrado y la compresión solo para las comunicaciones en subredes diferentes. Si el origen y el destino están en subredes diferentes y el DAG está configurado con los valores predeterminados para NetworkCompression y NetworkEncryption, puede invalidar estos valores mediante los parámetros NetworkCompressionOverride y NetworkEncryptionOverride en el cmdlet Update-MailboxDatabaseCopy .

Proceso de inicialización

Cuando se inicia un proceso de propagación mediante los cmdlets Add-MailboxDatabaseCopy o Update-MailboxDatabaseCopy , se realizan las siguientes tareas:

1. Las propiedades de base de datos de Active Directory se leen para validar la base de datos y los servidores especificados, y para comprobar que los servidores de origen y de destino ejecutan Exchange Server, ambos son miembros del mismo DAG y que la base de datos especificada no es una base de datos de recuperación. Las rutas de acceso al archivo de base de datos también se leen.

2. Los preparativos para las comprobaciones de reinicialización ocurren desde el servicio de replicación de Microsoft Exchange en el servidor de destino.

3. El servicio de replicación de Microsoft Exchange en el servidor de destino comprueba la presencia de archivos de base de datos y de registro de transacciones en los directorios de archivos leídos por las comprobaciones de Active Directory en el paso 1.

4. El servicio de replicación de Microsoft Exchange devuelve la información de estado del servidor de destino a la interfaz administrativa desde donde se ejecutó el cmdlet.

5. Si se superan todas las comprobaciones preliminares, se le pedirá que confirme la operación antes de continuar. Si confirma la operación, el proceso continúa. Si se detecta un error durante las comprobaciones preliminares, el error se informa y la operación falla.

6. La operación de inicialización se inicia desde el servicio de replicación de Microsoft Exchange en el servidor de destino.

7. El servicio de replicación de Microsoft Exchange suspende la replicación de la base de datos para la copia activa de la base de datos.

8. El servicio replicación de Microsoft Exchange actualiza la información de estado de la base de datos para reflejar un estado de propagación.

9. Si el servidor de destino aún no tiene los directorios de la base de datos de destino y los archivos de registro, se crean.

10. Una solicitud TCP para inicializar la base de datos se pasa desde el servicio de replicación de Microsoft Exchange en el servidor de destino al servicio de replicación de Microsoft Exchange en el servidor de origen. Esta solicitud y las comunicaciones posteriores para inicializar la base de datos se producen en una red DAG configurada como una red de replicación.

11. El servicio de replicación de Microsoft Exchange en el servidor de origen inicia una copia de seguridad por secuencias del Motor de almacenamiento extensible (ESE) a través de la interfaz del servicio Almacén de información de Microsoft Exchange.

12. El servicio Almacén de información de Microsoft Exchange transmite los datos de la base de datos al servicio de replicación de Microsoft Exchange.

13. Los datos de la base de datos se mueven del servicio de replicación de Microsoft Exchange del servidor de origen al servicio de replicación de Microsoft Exchange del servidor de destino.

14. El servicio de replicación de Microsoft Exchange en el servidor de destino escribe la copia de la base de datos en un directorio temporal ubicado en el directorio de base de datos principal denominado temp-seeding.

15. La operación de copia de seguridad por secuencias en el servidor de origen termina cuando se llega al final de la base de datos.

16. Se completa la operación de escritura en el servidor de destino y se mueve la base de datos del directorio temp-seeding a la ubicación final. Se elimina el directorio temp-seeding.

17. En el servidor de destino, el servicio de replicación de Microsoft Exchange envía mediante el proxy una solicitud al servicio de búsqueda de Microsoft Exchange para montar el catálogo del índice de contenido para la copia de la base datos, si existe. Si hay archivos de catálogo existentes no actualizados de una instancia previa de la copia de la base de datos, la operación de montaje falla y genera la necesidad de replicar el catálogo del servidor de origen. Del mismo modo, si el catálogo no existe en una nueva instancia de la copia de la base de datos en el servidor de destino, se requiere una copia del catálogo. El servicio de replicación de Microsoft Exchange indica al servicio de búsqueda de Microsoft Exchange que suspenda la indización de la copia de la base de datos mientras se copia un nuevo catálogo del servidor de origen.

18. El servicio de replicación de Microsoft Exchange en el servidor de destino envía una solicitud de catálogo de inicialización al servicio de replicación de Microsoft Exchange en el servidor de origen.

19. En el servidor de origen, el servicio replicación de Microsoft Exchange solicita la información de directorio del servicio Search de Microsoft Exchange y solicita que se suspenda la indexación.

20. El servicio de búsqueda de Microsoft Exchange en el servidor de origen devuelve la información del directorio del catálogo de búsqueda al servicio de replicación de Microsoft Exchange.

21. El servicio de replicación de Microsoft Exchange en el servidor de origen lee los archivos de catálogo del directorio.

22. El servicio de replicación de Microsoft Exchange en el servidor de origen mueve los datos del catálogo al servicio de replicación de Microsoft Exchange en el servidor de destino mediante una conexión en la red de replicación. Después de que finaliza la lectura, el servicio de replicación de Microsoft Exchange envía una solicitud al servicio de búsqueda de Microsoft Exchange para reanudar la indización de la base de datos del servidor de origen.

23. Si hay archivos de catálogo en el servidor de destino, en el directorio, el servicio de replicación de Microsoft Exchange en el servidor de destino los elimina.

24. El servicio replicación de Microsoft Exchange en el servidor de destino escribe los datos del catálogo en un directorio temporal denominado CiSeed.Temp hasta que los datos se transfieren por completo.

25. El servicio de replicación de Microsoft Exchange mueve todos los datos del catálogo a la ubicación final.

26. El servicio de replicación de Microsoft Exchange en el servidor de destino reanuda la indización de búsqueda en la base de datos de destino.

27. El servicio de replicación de Microsoft Exchange en el servidor de destino devuelve un estado de finalización.

28. El resultado final de esta operación se transmite a la interfaz administrativa desde donde se llamó el cmdlet.

Configuración de las copias de bases de datos

Después de que se cree una copia de base de datos, podrá ver y modificar la configuración cuando sea necesario. Puede ver la información de la configuración si examina la página Propiedades de una copia de base de datos en el EAC. También puede usar los cmdlets Get-MailboxDatabase y Set-MailboxDatabaseCopy en el Shell de administración de Exchange para ver y configurar las opciones de copia de la base de datos. Por ejemplo, tiempo de retardo de reproducción, tiempo de retardo de truncamiento y orden de preferencias de activación. Para obtener instrucciones detalladas acerca de cómo ver y establecer la configuración de copias de bases de datos, vea Configuración de las propiedades de una copia de base de datos de buzones.

Usar las opciones de tiempo de retardo de reproducción y tiempo de retardo de truncamiento

Las copias de base de datos de buzones admiten el uso de un tiempo de retardo de reproducción y un tiempo de retraso de truncamiento, ambos configurados en minutos. La configuración de un tiempo de retardo de reproducción le permite volver a llevar una copia de base de datos a un momento específico. La configuración de un tiempo de retardo de truncamiento le permite usar los registros en una copia de base de datos pasiva para recuperarse de la pérdida de archivos de registro en una copia de base de datos activa. Dado que ambas características dan lugar a la compilación temporal de archivos de registro, el uso de cualquiera de ellas afecta al diseño del almacenamiento.

Tiempo de retardo de reproducción

El tiempo de retardo de reproducción es una propiedad de copia de base de datos de buzón que especifica la cantidad de tiempo, en minutos, para retrasar la reproducción del registro de la copia de la base de datos. El temporizador de retardo de reproducción se inicia cuando un archivo de registro se replica en la copia pasiva y pasa correctamente la inspección. Mediante el retardo de la reproducción de archivos de la copia de base de datos, usted tiene la posibilidad de recuperar la base de datos en un momento específico anterior. Una copia de base de datos de buzón configurada con un tiempo de retardo de reproducción mayor que cero se conoce como copia de base de datos de buzón de correo retrasada, o simplemente, una copia retrasada.

Una estrategia que usa copias de base de datos y las características de suspensión por juicio en Exchange Server puede proporcionar protección contra una serie de errores que normalmente provocarían la pérdida de datos. Sin embargo, estas características no pueden proporcionar protección contra la pérdida de datos debido a daños lógicos. Aunque los daños lógicos son poco frecuentes, puede provocar la pérdida de datos. Las copias retrasadas están diseñadas para evitar la pérdida de datos debido a daños lógicos. Generalmente, hay dos tipos de daños de lógica:

• Daños lógicos en la base de datos: la suma de comprobación de las páginas de base de datos coincide, pero los datos de las páginas son incorrectos lógicamente. Esta situación se produce cuando ESE intenta escribir una página de base de datos. Aunque el sistema operativo devuelve un mensaje correcto, los datos nunca se escriben en el disco o se escriben en un lugar incorrecto. Esta condición se conoce como vaciado perdido. Para impedir que los vaciados perdidos pierdan datos, ESE incluye un mecanismo de detección de vaciados perdidos en la base de datos junto con una función de revisión de páginas (restauración de página única).

• Almacenar daños lógicos: los datos se agregan, eliminan o manipulan de una manera que el usuario no espera. Las aplicaciones que no son de Microsoft suelen causar estos casos. Por lo general, se considera daños en el sentido de que el usuario lo ve como daños. El almacén de Exchange considera que la transacción que produce los daños de lógica es una serie de operaciones MAPI válidas. La característica de suspensión por juicio en Exchange Server proporciona protección contra daños lógicos en el almacén (porque impide que un usuario o aplicación elimine permanentemente el contenido). Sin embargo, podría haber escenarios en los que un buzón de usuario se daña tanto que sería más fácil restaurar la base de datos a un momento dado antes de que se produjeran daños y, a continuación, exportar el buzón de usuario para recuperar datos no corregidos.

La combinación de copias de bases de datos, directiva de retención y restauración de página única ESE solo deja lugar para el caso, poco común pero catastrófico, de daños de lógica del almacén. La decisión de usar una copia de base de datos con un retraso de reproducción (una copia retrasada) depende de las aplicaciones que no sean de Microsoft que use y del historial de su organización con daños lógicos en el almacén.

Si decide usar copias retrasadas, tenga en cuenta las siguientes implicaciones para su uso:

• El tiempo de retardo de reproducción es un valor configurado por el administrador. De forma predeterminada, el tiempo de retardo de reproducción está deshabilitado.

• La configuración de tiempo de retardo de reproducción tiene un valor predeterminado de cero días y un valor máximo de 14 días.

• Las copias retrasadas no se consideran copias de alta disponibilidad. En su lugar, están diseñadas para fines de recuperación ante desastres, para protegerse frente a daños lógicos en el almacén.

• Cuanto mayor sea el tiempo de retardo de reproducción, más largo será el proceso de recuperación de base de datos. La recuperación de una base de datos puede tardar varias horas debido a lo siguiente:

  • Número de archivos de registro que se van a reproducir.
  • Velocidad a la que el hardware puede reproducirlos.

• Le recomendamos que determine si las copias retrasadas son cruciales para su estrategia general de recuperación ante desastres. Si su uso es crucial para la estrategia, le recomendamos usar varias copias retrasadas o una matriz redundante de discos independientes (RAID) para proteger una sola copia retrasada, si no tiene varias copias retrasadas. Si pierde un disco o si se producen daños, no pierde su copia retrasada tal como estaba en un momento específico anterior al momento en que se produjeron los daños.

• Las copias retrasadas no se pueden aplicar revisiones con la característica de restauración de página única ese. Si una copia retrasada encuentra daños en la página de la base de datos (por ejemplo, un error -1018), la copia debe volver a inicializarse. La reseeding pierde el aspecto retrasado de la copia.

Si desea que la base de datos reproduzca todos los archivos de registro y haga que la base de datos se copie al día, activar y recuperar una copia de base de datos de buzón de correo retrasada es un proceso sencillo. Si desea reproducir archivos de registro hasta un momento dado, el proceso es más difícil porque tiene que manipular manualmente los archivos de registro y ejecutar Exchange Server Utilidades de base de datos (Eseutil.exe).

Para obtener pasos detallados sobre cómo activar una copia de base de datos de buzón de correo con retraso, consulte Activación de una copia de base de datos de buzón de correo retrasada.

Tiempo de retardo de truncamiento

El tiempo de retraso de truncamiento es la propiedad de una copia de base de datos de buzón de correo que especifica el tiempo en minutos para retrasar la eliminación del registro de la copia de la base de datos después de que el archivo de registro se haya reproducido en la copia de la base de datos. El temporizador de retardo de truncamiento se inicia cuando un archivo de registro se ha replicado en la copia pasiva, ha pasado correctamente la inspección y se ha reproducido correctamente en la copia de la base de datos. Mediante el retardo del truncamiento de los archivos de registro de la copia de base de datos, usted tiene la posibilidad de recuperarse de errores que afectan los archivos de registro para la copia activa de la base de datos.

Copias de base de datos y truncamiento de registros

El truncamiento de registros funciona igual en Exchange 2016 y Exchange 2019 que en Exchange 2010. El comportamiento de truncamiento está determinado por la configuración del tiempo de retardo de reproducción y del tiempo de retardo de truncamiento para la copia.

Para que un archivo de registro de una copia de base de datos se trunque cuando la configuración de retardo se deja en los valores predeterminados de 0 (deshabilitado), es necesario que se cumplan los siguientes criterios:

• Se realiza una copia de seguridad correcta del archivo de registro o se habilita el registro circular.
• El archivo de registro debe estar por debajo del punto de control (el archivo de registro mínimo necesario para la recuperación) para la base de datos.
• Todas las demás copias retrasadas inspeccionaron el archivo de registro.
• Todas las demás copias (excepto las copias retrasadas) reproducieron el archivo de registro.

Para que se produzca el truncamiento de una copia retrasada de base de datos es necesario que se cumplan los siguientes criterios:

• El archivo de registro debe estar por debajo del punto de control para la base de datos.
• El archivo de registro debe ser anterior a ReplayLagTime + TruncationLagTime.
• El archivo de registro se trunca en la copia activa.

En Exchange Server, el truncamiento del registro no se produce en una copia de base de datos de buzón de correo activa cuando se suspenden una o varias copias pasivas. Si las actividades de mantenimiento planeadas van a tardar un período de tiempo prolongado (por ejemplo, varios días), es posible que tenga una compilación considerable de archivos de registro. Para evitar que la unidad del registro se llene con registros de transacciones, puede quitar la copia de base de datos pasiva afectada en lugar de suspenderla. Cuando finaliza el mantenimiento planeado, puede volver a agregar la copia de base de datos pasiva.

Exchange Server ahora tiene una característica denominada truncamiento flexible que está deshabilitada de forma predeterminada. Durante las operaciones normales, cada copia de base de datos mantiene los registros que deben enviarse a otras copias de base de datos hasta que todas las copias de una base de datos confirmen lo siguiente:

• Reproduciron los archivos de registro (copias pasivas).
• Recibieron los archivos de registro (copias retrasadas).

Este comportamiento es el comportamiento predeterminado de truncamiento del registro. Si una copia de la base de datos se desconecta por algún motivo, los archivos de registro comienzan a acumularse en los discos usados por las otras copias de la base de datos. Si la copia de la base de datos permanece sin conexión durante un período prolongado, esto puede causar que las otras copias de la base de datos se queden sin espacio en disco.

El comportamiento de truncamiento es diferente cuando se habilitan el truncamiento flexible y el registro circular. Cada copia de la base de datos realiza un seguimiento de su propio espacio libre en disco y aplica el comportamiento de truncamiento suelto si queda poco espacio libre.

• Para la copia activa, se pasa por alto la copia atrasada más antigua (la copia pasiva de base de datos que se encuentra más atrás en la reproducción del registro) y el truncamiento respeta las copias pasivas más antiguas restantes. La copia de base de datos activa es donde se calcula el truncamiento global.

• En el caso de una copia pasiva, si el espacio es bajo, trunca de forma independiente sus archivos de registro mediante los parámetros configurados que se describen más adelante en la tabla Valor del Registro. Las copias pasivas intentan respetar la decisión de truncamiento tomada en la copia activa. A pesar de la implicación del nombre MinCopiesToProtect, Exchange solo omite el rezagado más antiguo conocido en el momento en que se ejecuta el truncamiento.

Cuando la base de datos sin conexión se vuelve a poner en línea, los archivos de registro que faltan se eliminan de las otras copias en buen estado y su estado de copia de la base de datos es FailedAndSuspended. En este caso, si se configura Autoreseed, la copia afectada se vuelve a seizar automáticamente. Si Autoreseed no está configurado, un administrador debe inicializar manualmente la copia de la base de datos.

Si el registro circular está deshabilitado, el truncamiento flexible respeta las copias de seguridad realizadas. El truncamiento flexible no quita los archivos de registro de los que no se ha hecho una copia de seguridad.

El truncamiento es una característica recomendada para la arquitectura preferida donde no se usan las copias de seguridad y el registro circular está habilitado.

El número necesario de copias en buen estado, el umbral de espacio disponible en disco y el número de registros que se mantienen son parámetros que se pueden configurar. De forma predeterminada, el umbral de espacio libre en disco es de 204.800 MB (200 GB), y el número de registros para guardar es de 100.000 (100 GB) para las copias pasivas, y de 10.000 (10 GB) para las copias activas.

Para habilitar el truncamiento suelto y configurar sus parámetros, es necesario editar el Registro de Windows en cada miembro del DAG. Hay tres valores del Registro que se pueden configurar y que se almacenan en HKLM\Software\Microsoft\ExchangeServer\v15\BackupInformation. La clave BackupInformation de los siguientes valores DWORD no existe de forma predeterminada y se debe crear manualmente. Los valores DWORD del Registro en BackupInformation se describen en la tabla siguiente:

Cuando se usa el valor del Registro LooseTruncation_MinLogsToProtect, el comportamiento es diferente para las copias de base de datos activas y pasivas.

• Activo: el número de registros adicionales que se conservan antes de los registros requeridos por las copias pasivas protegidas y el intervalo necesario de la copia activa.
• Pasivo: el número de registros mantenidos desde el registro disponible más reciente. Una décima parte de este número también se usa para mantener los registros antes del intervalo necesario de esta copia pasiva.

Los dos límites están establecidos para asegurarse de que las copias de base de datos retrasadas no ocupan demasiado espacio, ya que su intervalo necesario suele ser muy grande.

Directiva de activación de base de datos

Hay escenarios en los que es posible que desee crear una copia de base de datos de buzón de correo e impedir que el sistema active automáticamente esa copia. Por ejemplo, después de un error:

• Implemente una o varias copias de base de datos de buzones de correo en un centro de datos alternativo o en espera.
• Configure una copia de base de datos retrasada con fines de recuperación.
• Está realizando un mantenimiento o una actualización del servidor.

En cada una de las situaciones anteriores, usted tiene copias de base de datos que no desea que el sistema active automáticamente. Para impedir que el sistema active automáticamente una copia de base de datos de buzones de correo, puede configurar la copia para que quede bloqueada (suspendida) para activarse.

Esta configuración permite al sistema mantener la moneda de la base de datos mediante el trasvase de registros y la reproducción, pero impide que el sistema se active y use automáticamente la copia. Un administrador debe activar manualmente las copias bloqueadas para la activación.

Puede establecer el parámetro DatabaseCopyAutoActivationPolicy en Bloqueado para:

• Un servidor completo mediante el cmdlet Set-MailboxServer .
• Copia de una base de datos individual mediante el cmdlet Set-MailboxDatabaseCopy .

Para obtener más información acerca de cómo configurar la directiva de activación de base de datos, vea Configurar la directiva de activación para una copia de base de datos de buzones.

Efecto de movimientos del buzón de correo sobre la replicación continua

En una base de datos de buzones de correo muy ocupada, con un índice de generación de registros muy alto, hay más probabilidades de pérdida de datos si la replicación en las copias pasivas de la base de datos no puede mantener el nivel de la generación de registros. Una situación que puede provocar un índice de generación de registros muy alto es el movimiento del buzón de correo. Exchange Server incluye una API de garantía de datos que usan servicios como el servicio de replicación de buzones de Exchange (MRS) para comprobar el estado de la arquitectura de copia de base de datos en función del valor del parámetro DataMoveReplicationConstraint establecido por el sistema o un administrador. Específicamente, la API de garantía de datos puede utilizarse para:

• Comprobar el estado de la replicación: confirma que el número de requisitos previos de copias de base de datos está disponible.

• Comprobar vaciado de replicación: confirma que los archivos de registro necesarios se reproducen según el número de requisitos previos de copias de base de datos.

Al ejecutarla, la API regresa la siguiente información de estado a la aplicación de llamada:

• Reintento: indica que hay errores transitorios que impiden que se compruebe una condición en la base de datos.

• Satisfecho: significa que la base de datos cumple las condiciones necesarias o que la base de datos no se replica.

• NotSatisfied: significa que la base de datos no cumple las condiciones necesarias. Además, se brinda información a la aplicación de llamada con respecto al motivo por el cual se suministró la respuesta No cumplido.

El valor del parámetro DataMoveReplicationConstraint de la base de datos de buzón determina cuántas copias de base de datos se deben evaluar como parte de la solicitud. El parámetro DataMoveReplicationConstraint tiene los siguientes valores posibles:

• None: al crear una base de datos de buzón de correo, este valor se establece de forma predeterminada. Cuando se configura este valor, se omiten las condiciones de la API de garantía de datos. Esta opción debe usarse sólo para bases de datos de buzones de correo que no se replican.

• SecondCopy: este es el valor predeterminado al agregar la segunda copia de una base de datos de buzón de correo. Cuando se configura este valor, al menos una copia pasiva de la base de datos debe cumplir las condiciones de la API de garantía de datos.

• SecondDatacenter: cuando se establece este valor, al menos una copia de base de datos pasiva en otro sitio de Active Directory debe cumplir las condiciones de la API de garantía de datos.

• AllDatacenters: cuando se establece este valor, al menos una copia de base de datos pasiva en cada sitio de Active Directory debe cumplir las condiciones de la API de garantía de datos.

• AllCopies: cuando se establece este valor, todas las copias de la base de datos de buzón deben cumplir las condiciones de la API de garantía de datos.

Verificar el estado de la replicación

Cuando la API de garantía de datos se ejecuta para evaluar el estado de la infraestructura de la copia de la base de datos, se evalúan varios elementos.

En todos los escenarios, la copia pasiva de la base de datos debe cumplir las condiciones siguientes:

• Funcionar correctamente.

• Tener una cola de reproducción antes de que transcurran 10 minutos del tiempo de retardo de reproducción.

• Tener una longitud de la cola de copia de menos de 10 registros.

• Tener una longitud de cola de copia promedio de menos de 10 registros. La longitud media de la cola de copia se calcula en función del número de veces que la aplicación ha consultado el estado de la base de datos.

Verificar el vaciado de la replicación

La API de garantía de datos también puede utilizarse para validar que la cantidad de copias de la base de datos que era un requisito previo haya reproducido los registros de transacciones requeridos. Esto se comprueba comparando la última marca de tiempo reproducida del registro con la de la marca de tiempo de confirmación del servicio de llamada (en la mayoría de los casos, esta es la marca de tiempo del último archivo de registro que contiene los datos necesarios) más cinco segundos adicionales (para tratar con los desfases o asimetrías del reloj del sistema). Si la marca de tiempo de reproducción es mayor que la marca de tiempo de confirmación, se cumple el parámetro DataMoveReplicationConstraint . Si la marca de tiempo de reproducción es menor que la marca de tiempo de confirmación, dataMoveReplicationConstraint no se satisface.

Antes de mover un gran número de buzones hacia o desde bases de datos de replicación dentro de un DAG, se recomienda configurar el parámetro DataMoveReplicationConstraint en cada base de datos de buzones de correo de acuerdo con la tabla siguiente:

Equilibrio de las copias de bases de datos

Debido a la naturaleza inherente de los DAG, como resultado de los cambios y conmutaciones por error de la base de datos, la base de datos de buzones de correo activa copia los hosts de cambio varias veces a lo largo de la duración de un DAG. Como resultado, los DAG pueden quedar desequilibrados en cuanto a la distribución de las copias de bases de datos de buzones de correo activas. En la tabla siguiente se muestra el ejemplo de un DAG que tiene cuatro bases de datos con cuatro copias para cada base de datos (formando un total de 16 bases de datos en cada servidor) que presenta una distribución desigual de copias de bases de datos activas.

En el ejemplo anterior, hay cuatro copias de cada base de datos y, por lo tanto, sólo cuatro valores posibles de preferencia de activación (1, 2, 3 ó 4). La columna Lista de conteo de preferencia muestra el conteo de la cantidad de bases de datos con cada uno de esos valores. Por ejemplo, en EX3 hay 13 copias de bases de datos con una preferencia de activación de 1, dos copias con una preferencia de activación de 2, una copia con una preferencia de activación de 3 y ninguna copia con una preferencia de activación de 4.

Como puede ver, este DAG no está equilibrado en cuanto a la cantidad de bases de datos activas alojadas por cada miembro del DAG, a la cantidad de bases de datos pasivas alojadas por cada miembro del DAG ni al conteo de preferencia de activación de las bases de datos alojadas.

Puede usar el script RedistributeActiveDatabases.ps1 para almacenar las copias activas de las bases de datos del buzón en todo el DAG. Este script traslada las bases de datos entre sus copias, intentando obtener una cantidad igual de bases de datos montadas en cada servidor del DAG. Si es necesario, el script también intenta equilibrar las bases de datos activas entre sitios.

El script proporciona dos opciones para equilibrar copias de bases de datos activas dentro de un DAG:

• BalanceDbsByActivationPreference: cuando se especifica esta opción, el script intenta mover las bases de datos a su copia más preferida (en función de las preferencias de activación) sin tener en cuenta el sitio de Active Directory.

• BalanceDbsBySiteAndActivationPreference: cuando se especifica esta opción, el script intenta mover las bases de datos activas a su copia más preferida, al tiempo que intenta equilibrar las bases de datos activas dentro de cada sitio de Active Directory.

Después de ejecutar el script con la primera opción, el DAG que estaba desequilibrado se equilibra, tal como se muestra en la tabla siguiente.

Como se muestra en la tabla anterior, este DAG está equilibrado en cuanto a la cantidad de bases de datos activas y pasivas que hay en cada servidor y en la preferencia de activación de todos los servidores.

La siguiente tabla muestra los parámetros disponibles para el script RedistributeActiveDatabases.ps1.

Ejemplos con RedistributeActiveDatabases.ps1

En este ejemplo se muestra la distribución actual de las bases de datos de un DAG, incluida la lista de conteo de preferencia.

RedistributeActiveDatabases.ps1 -DagName DAG1 -ShowDatabaseDistributionByServer | Format-Table

En este ejemplo se redistribuyen y equilibran las copias activas de las bases de datos del buzón de correo de un DAG mediante el uso de la preferencia de activación sin solicitar entrada.

RedistributeActiveDatabases.ps1 -DagName DAG1 -BalanceDbsByActivationPreference -Confirm:$False

En este ejemplo se redistribuyen y equilibran las copias de las bases de datos de buzones de correo activas de un DAG, mediante la preferencia de activación, y se genera un resumen de la distribución.

RedistributeActiveDatabases.ps1 -DagName DAG1 -BalanceDbsByActivationPreference -ShowFinalDatabaseDistribution

Supervisión de copias de base de datos

Puede ver una variedad de información, incluida la longitud de la cola de copia, la longitud de la cola de reproducción, la información sobre la categoría y el estado del índice de contenido examinando los detalles de una copia de base de datos en el EAC. También puede usar el cmdlet Get-MailboxDatabaseCopyStatus en el Shell de administración de Exchange para ver una variedad de información de estado de una copia de base de datos.

Para obtener más información sobre la supervisión de copias de base de datos, consulte Supervisión de grupos de disponibilidad de bases de datos.

Eliminación de una copia de base de datos

Una copia de base de datos se puede quitar en cualquier momento mediante el EAC o mediante el cmdlet Remove-MailboxDatabaseCopy en el Shell de administración de Exchange. Después de quitar una copia de base de datos, debe eliminar del servidor del cual se está quitando la copia cualquier archivo de base de datos y archivo de registro de forma manual. Para obtener instrucciones detalladas acerca de cómo eliminar la copia de una base de datos, vea Eliminación de una copia de base de datos de buzones.

Cambios de base de datos

El servidor de buzones de correo que hospeda la copia activa de una base de datos se conoce como el patrón de base de datos de buzones de correo. El proceso de activación de una copia de base de datos pasiva cambia el patrón de base de datos de buzones de correo de la base de datos y convierte a la copia pasiva en la nueva copia activa. Este proceso se denomina cambio de base de datos. En un cambio de base de datos, la copia activa de una base de datos se desmonta en un servidor de buzones de correo, y una copia pasiva de esa base de datos se monta como la nueva base de datos de buzones de correo activa en otro servidor de buzones de correo. Cuando se realiza un cambio, tiene la opción de anular la configuración del marcado de montaje de base de datos en el nuevo patrón de base de datos de buzones de correo.

Si revisa la columna de la derecha de la ficha Copia de la base de datos en la EAC, puede identificar rápidamente qué servidor de buzones de correo es el patrón de la base de datos de buzones de correo actual. Puede realizar una conmutación mediante el vínculo Activar del EAC o mediante el cmdlet Move-ActiveMailboxDatabase en el Shell de administración de Exchange.

Hay varias comprobaciones internas realizadas antes de activar una copia pasiva. En algunos casos, el cambio de base de datos se bloquea o cancela. En otros casos, puede usar cmdlets para mover o omitir algunas comprobaciones.

• Se comprueba el estado de la copia de base de datos. Si la copia de base de datos está en estado de error, se bloquea el cambio. Puede invalidar este comportamiento y omitir la comprobación de estado mediante el parámetro SkipHealthChecks del cmdlet Move-ActiveMailboxDatabase . Este parámetro le permite mover la copia activa a una copia de base de datos en un estado de error.

• La copia activa de la base de datos se verifica para comprobar si es actualmente un origen de inicialización para copias pasivas de la base de datos. Si la copia activa actualmente se está usando como origen de inicialización, el cambio se bloquea. Puede invalidar este comportamiento y omitir la comprobación de origen de propagación mediante el parámetro SkipActiveCopyChecks del cmdlet Move-ActiveMailboxDatabase . Este parámetro le permite mover la copia activa que se está usando como origen de inicialización. El uso de este parámetro hace que la operación de propagación se cancele y se considere errónea.

• Las longitudes de la cola de copia y de la cola de reproducción de la copia de base de datos se comprueban para garantizar que sus valores estén dentro de los criterios configurados. Además, la copia de base de datos se comprueba para garantizar que no esté en uso en ese momento como origen de inicialización. Si los valores para las longitudes de cola están fuera de los criterios configurados, o si la base de datos está en uso como origen de inicialización, se bloquea el cambio. Puede invalidar este comportamiento y omitir estas comprobaciones mediante el parámetro SkipLagChecks del cmdlet Move-ActiveMailboxDatabase . Este parámetro permite que se active una copia que tiene las colas de reproducción y copia fuera de los criterios configurados.

• Se comprueba el estado del catálogo de búsqueda (índice de contenido) de la copia de base de datos. Si el catálogo de búsqueda no está actualizado, se encuentra en un estado incorrecto o está dañado, se bloquea el cambio. Puede invalidar este comportamiento y omitir la comprobación del catálogo de búsqueda mediante el parámetro SkipClientExperienceChecks del cmdlet Move-ActiveMailboxDatabase . Este parámetro hace que esta búsqueda omita la comprobación del estado del catálogo. Si el catálogo de búsqueda de la copia de base de datos que está activando está en un estado incorrecto o inutilizable y usa este parámetro para omitir la comprobación de estado del catálogo y activar la copia de la base de datos, debe rastrear o inicializar de nuevo el catálogo de búsqueda.

Al realizar una conmutación de base de datos, también tiene la opción de invalidar la configuración de marcado de montaje configurada para el servidor que hospeda la copia pasiva de la base de datos que se está activando. El uso del parámetro MountDialOverride del cmdlet Move-ActiveMailboxDatabase indica al servidor de destino que invalide su propia configuración de marcado de montaje y use la configuración especificada por el parámetro MountDialOverride .

Para obtener instrucciones detalladas acerca de cómo realizar un cambio de una copia de base de datos, vea Activación de una copia de base de datos de buzones.