Offline Backup and Restoration Procedures for Exchange

Resumen

Este artículo describe métodos que puede utilizar para omitir las interfaces (API) de programación de aplicaciones de copia de seguridad en línea y manualmente copia de seguridad y restaurar bases de datos de almacén de información de Exchange. Si tiene varios grupos de almacenamiento en un único servidor de Exchange, cada grupo de almacenamiento debe considerarse una unidad independiente, autónoma a efectos de la restauración y de copia de seguridad sin conexión. Para obtener información adicional acerca de las copias de seguridad instantáneas y sin conexión, haga clic en el número de artículo siguiente para verlo en Microsoft Knowledge Base:

296787 XADM: Offline Backup and Restoration Procedures for Exchange Server 4.0, 5.0 y 5.5

Más información

Antes de comenzar

Antes de realizar una copia de seguridad sin conexión, asegúrese de que tiene la siguiente información:
  • Determinar si el registro circular está habilitado para el grupo de almacenamiento. (En Exchange el registro circular está deshabilitado de forma predeterminada). Para determinar si el registro circular está habilitado, abra las propiedades del objeto grupo_almacenamiento en Administrador del sistema de Exchange y, a continuación, ver la página General . Para deshabilitar el registro circular, haga clic para desactivar la casilla de verificación Registro Circular . Cambios en el registro circular no surten efecto hasta que detenga cada base de datos del grupo de almacenamiento.


    No es necesario deshabilitar el registro circular para realizar copias de seguridad sin conexión. Sin embargo, debe deshabilitar el registro circular si desea reproducir los registros de transacciones en las copias de seguridad sin conexión restauradas.
  • Determinar las ubicaciones de ruta de acceso de la base de datos de Exchange, streaming, registro de transacciones y archivos de punto de comprobación y el prefijo de archivo de registro para el grupo de almacenamiento.


    Para encontrar esta información, abra las propiedades del objeto grupo_almacenamiento en Administrador del sistema de Exchange y, a continuación, ver la página General . Registre los valores para los tres cuadros siguientes:
    • Prefijo de archivo de registro (E0n, donde puede ser E0n E00, E01, E02 y E03)
    • Ubicación del registro de transacciones (E0n*.log)
    • Ubicación de ruta de acceso del sistema (E0n.chk)
    Rutas de acceso de base de datos se enumeran en las propiedades de la base de datos de cada objeto database_name . Registre los valores de los dos campos siguientes para cada base de datos del grupo de almacenamiento:
    • Base de datos de Exchange (.edb)
    • Base de datos de secuencias de Exchange (stm)
Si el Administrador del sistema de Exchange no está disponible, puede encontrar toda la información anterior leyendo directamente sin procesar atributos de Active Directory con una herramienta como ADSIEDIT o LDIFDE. Puede utilizar el siguiente comando LDIFDE para generar la información de todos los servidores de Exchange en un bosque de Active Directory.

Nota: el texto de este comando se ha ajustado para mejorar la legibilidad.
LDIFDE -F EXPATHS. TXT -D "CN = CONFIGURATION, DC =configuration_container_domain, DC =top_level_domain" -L MSEXCHESEPARAMLOGFILEPATH, MSEXCHESEPARAMSYSTEMPATH,
MSEXCHESEPARAMBASENAME, MSEXCHESEPARAMCIRCULARLOG, MSEXCHSLVFILE,
MSEXCHEDBFILE -R "(| () MSEXCHESEPARAMLOGFILEPATH=*)(MSEXCHESEPARAMSYSTEMPATH=*)(MSEXCHESEPARAMBASENAME=*)(MSEXCHESEPARAMCIRCULARLOG=*)(MSEXCHEDBFILE=*)(MSEXCHSLVFILE=*))"
El siguiente es un ejemplo de la salida del comando anterior:
D:\Exchsrvr\Mdbdata > ldifde -f con -d "cn = configuration, dc = test, dc = com" -l msexch eseparamlogfilepath msexcheseparamsystempath, msexcheseparambasename, msexchesepar amcircularlog, msexchslvfile, msexchedbfile - r "(| () msExchESEParamLogFilePath = *) (ms excheseparamsystempath=*)(msexcheseparambasename=*)(msexchslvfile=*) (msexchedbfi le=*)(msexcheseparamcircularlog=*))"
Conectar con "dc1.child.test.com"
Inicio de sesión como usuario actual utilizando SSPI
Exportación de directorio a con archivo
Buscando entradas...

< resultado truncado >

.DN: CN = Primer grupo de almacenamiento, CN = AlmacénInformación, CN = Exchange1, CN = Servers, CN = Primer grupo administrativo, CN = Administrative Groups, CN = organización, CN = Microsoft Excha ESN, CN = Servicios, CN = Configuration, DC = Test, DC = com
ChangeType: agregar
msExchESEParamCircularLog: 0
msExchESEParamLogFilePath: D:\exchsrvr\MDBDATA
msExchESEParamSystemPath: D:\exchsrvr\MDBDATA
msExchESEParamBaseName: E00

.DN: CN = Almacén de información pública (EXCHANGE1), CN = Primer grupo de almacenamiento, CN = onStore de ninguna información, CN = Exchange1, CN = Servers, CN = Primer grupo administrativo, CN = Administrative Groups, CN = organización, CN = Microsoft Exchange, CN = Servicios, CN = Configuration, DC = Tes t, DC = com
ChangeType: agregar
msExchEDBFile: D:\exchsrvr\MDBDATA\PUB. EDB
msExchSLVFile: D:\exchsrvr\MDBDATA\PUB.stm

.DN: CN = Almacén de información privada (Exchange1), CN = Primer grupo de almacenamiento, CN = informaci on ionStore, CN = Exchange1, CN = Servers, CN = Primer grupo administrativo, CN = Administrative Groups, CN = organización, CN = Microsoft Exchange, CN = Servicios, CN = Configuration, DC = Te st, DC = com
ChangeType: agregar
msExchEDBFile: D:\exchsrvr\MDBDATA\PRIV. EDB
msExchSLVFile: D:\exchsrvr\MDBDATA\PRIV.stm
Para reproducir correctamente los registros de transacciones, debe restaurar los archivos de base de datos (.edb y .stm) en las mismas ubicaciones de ruta de acceso desde la que se copian los archivos. Por ejemplo, si copia el archivo de base de datos desde la carpeta E:\Mdbdata y el archivo de base de datos de transmisión por secuencias desde la carpeta F:\Mdbdata, debe restaurar los archivos E:\Mdbdata y F:\Mdbdata, respectivamente. Esta limitación se aplica incluso si desea restaurar la base de datos a un servidor totalmente diferente (por ejemplo, en una situación de recuperación de buzón individual).


Si cambia una ruta de acceso de la base de datos después de la última copia de seguridad, sólo parcialmente puede reproducir registros de transacciones y puede lograr una reproducción parcial sólo si cambia la ruta de acceso a la ubicación original. Si volver a la antigua ruta, puede reproducir los logs hasta el punto en el que se cambió la ruta de acceso.


Puede restaurar archivos de registro de transacciones (E0n*.log) en una ruta diferente a la ubicación de copia de seguridad original. Esto es porque los registros de transacciones registran las ubicaciones de las bases de datos vinculados a los registros de transacciones, pero las bases de datos no grabar las ubicaciones de los registros de transacciones. Durante la reproducción, los registros de "Buscar" las bases de datos con información de ruta de acceso almacenada en los encabezados de registro de transacciones. (La API de copia de seguridad en línea se compensa internamente cambios de ruta de acceso de la base de datos y, por lo que esta limitación no se aplica.)


No hacer copia de seguridad o restaurar el archivo de punto de comprobación (E0n.chk), pero debe conocer la ubicación actual del archivo de punto de control porque puede necesitarlo examinarlo o eliminar durante la recuperación.

¿Cómo se relacionan entre sí los archivos de base de datos de Exchange

Los archivos .edb y .stm están los repositorios finales para toda la información de la base de datos. Para la mayoría de los casos, tratar estos dos archivos como si fueran un solo archivo; copia de seguridad y restaurar estos archivos conjuntamente. Estos archivos deben permanecer sincronizados cronológicamente entre sí; un archivo .edb que se copia en un día no coincide con un archivo de secuencias que se copia en otro día.


Un servidor de Exchange 2003 o de Exchange 2000 puede admitir hasta cuatro grupos de almacenamiento y cada grupo de almacenamiento admite hasta cinco bases de datos. Un grupo de almacenamiento es un conjunto de bases de datos que comparten un conjunto común de archivos de registro de transacciones. Microsoft Exchange Server 5.5 puede admitir un máximo de un grupo de almacenamiento, que admite hasta dos bases de datos (almacenes de información privada y pública).


Cuando se realizan cambios en la base de datos, los cambios se escriben primero en el archivo de registro de transacciones actual y, a continuación, en una caché en memoria. Tan pronto como cambios están presentes en la memoria caché, esos cambios se hacen visibles a los usuarios. Páginas de la caché se vacían en el archivo de base de datos cuando es conveniente hacerlo. El punto de control marca el punto en la secuencia de archivos de registro hasta que todas las transacciones se han volcado de físicamente en el archivo de base de datos. Es normal que el punto de control para el intervalo de tres o más archivos de registro detrás del archivo de registro actual.


Para evitar confusión acerca de qué archivos de registro pertenecen a cada grupo de almacenamiento, registros de Exchange que pertenecen a un grupo de almacenamiento determinado se denominan con un prefijo de registro único, que es los tres primeros caracteres del nombre de archivo. Prefijos de registro válida de los cuatro grupos de almacenamiento que se admiten en un servidor de Exchange 2003 o Exchange 2000 son E00, E01, E02 y E03. En este artículo, el prefijo del registro para un grupo de almacenamiento se designa como E0n. El archivo de registro actual para un grupo de almacenamiento es siempre el archivo E0n.log.


Registros de transacciones son un uniforme 5 megabytes (MB) de tamaño. Cuando el archivo de registro actual está lleno, se renombra con un número de secuencia hexadecimal, denominado el número de generación del registro y se genera un nuevo archivo de registro actual. Archivos de registro se numeran como E0n00001.log, E0n00002.log y así sucesivamente. En este artículo, los archivos de registro numerados se designan genéricamente como E0nxxxxx. log.


Si una base de datos se detiene anormalmente, reproducir los registros de archivo (E0n.chk) de punto de comprobación del registro de transacciones desde la que debe comenzar la recuperación para restaurar la base de datos para mejorar la coherencia. Este proceso se denomina "recuperación de software". Recuperación de software se puede contrastar con "recuperación de hardware," que es el proceso por qué registro se reproducen archivos tras la restauración de una copia de seguridad en línea. La diferencia más importante entre rígida y flexibles de recuperación es la interpolación de datos de archivo de revisión en el proceso de reproducción del archivo de registro durante la recuperación de hardware.


Un archivo de base de datos incoherente de Exchange es un archivo que todas las transacciones pendientes no se escribieron para todavía. Durante el funcionamiento normal, los archivos de base de datos de Exchange son incoherentes porque hay información en la caché que todavía no se han físicamente escrita en el archivo. En general, un archivo de base de datos de Exchange puede considerarse coherente sólo después de un apagado normal del servicio de base de datos. Sin embargo, la base de datos, considerado en su conjunto (que se considera como la suma de la información en los registros de transacciones y archivos de base de datos), es siempre coherente a menos que prematuramente se eliminan los archivos de registro necesarios.

La copia de seguridad de una base de datos de Exchange sin conexión

Para realizar una copia de una base de datos de Exchange sin conexión:
  1. Desmontar la base de datos que desea hacer copia de seguridad. No es necesario desmontar todas las bases de datos del grupo de almacenamiento, la base de datos o bases de datos que desea hacer copia de seguridad.
  2. Compruebe que los archivos de base de datos (archivo .edb y .stm) son coherentes y coincidentes entre sí. Para ello, ejecute el comando siguiente en cada archivo:
    archivo de base de datos de Eseutil /mh | Find /i ""Firma DB"
    Nota: Exchange 2000 Service Pack 2 y posterior no informan del estado de la base de datos como "Coherente" o "Incoherente", sino como "Cierre limpio" o "Cierre con errores". El significado de "Cierre limpio" es igual a "Consistente", y el significado de "Cierre con errores" es el mismo que "Incoherente". Para Exchange 2000 Service Pack 2 o posterior, ejecute este comando adicional para determinar el estado de cada base de datos:

    Eseutil /mh database_name | Find /i "Apagado"
    El siguiente es un ejemplo de la salida del comando anterior:

    D:\mdbdata>eseutil /mh priv.edb | find /i "DB Signature"     DB Signature: Create time:04/02/2001 16:59:32 Rand:2746771 Computer:

    D:\mdbdata>eseutil /mh priv.stm | find /i "DB Signature"
    DB Signature: Create time:04/02/2001 16:59:32 Rand:2746771 Computer:

    En el ejemplo anterior, las firmas de DB son idénticos, lo que demuestra que los archivos .edb y .stm pertenecen al mismo conjunto. (Ambas líneas de firma deben coincidir carácter por carácter en su totalidad se considere una coincidencia de firma).


    No sólo deben coincidir las firmas de DB, pero los archivos también deben estar sincronizados entre sí y coherentes. Ejecute el comando siguiente en cada archivo:
    archivo de base de datos de Eseutil /mh | Find /i "coherente"
    El siguiente es un ejemplo de la salida que es el resultado del comando anterior:
    D:\mdbdata>eseutil /mh priv.edb | find /i "consistent"             State: Consistent
    Last Consistent: (0x2CC7,1F14,1F7) 04/04/2001 18:07:14

    D:\mdbdata>eseutil /mh priv.stm | find /i "consistent"
    State: Consistent
    Last Consistent: (0x2CC7,1F14,1F7) 00/00/1900 00:00:00

    En el ejemplo anterior, el informe de ambos archivos "estado: coherente." También deben coincidir con los números hexadecimales entre paréntesis para cada archivo (0x2CC7, 1F14, 1F7). La marca de tiempo pasado coherente no es necesario hacer coincidir. Estos archivos son coherentes y coincidentes entre sí.


    Si el archivo informes "estado: incoherentes" o la última coherente posiciones de registro no están sincronizadas, la base de datos no se ha desmontado correctamente. Montar y, a continuación, vuelva a desmontar la base de datos. Si los archivos todavía no coinciden correctamente o son inconsistentes, póngase en contacto con los servicios de soporte técnico de Microsoft (PSS) para obtener más ayuda.
  3. Copiar cada archivo de base de datos .edb y su archivo de base de datos de transmisión .stm correspondiente a una ubicación de copia de seguridad.
  4. Monte la copia de seguridad de las bases de datos.
  5. Si el registro circular está habilitado, omita este paso. Si el registro circular está deshabilitado y desea "Confirmar" más adelante, debe hacer copia de seguridad de todos los archivos de registro de transacción numerada (los archivos E0nxxxxx. log). No hacer copia de seguridad de los archivos del archivo E0n.log, Res1.log y Res2.log.

    Puede realizar una copia archivos de registro numerados en cualquier momento, incluso inmediatamente después de la creación, porque después de que un archivo de registro ha cambiado desde el archivo E0n.log a E0nxxxxx.log, Exchange no modifica ese archivo otra vez. Sin embargo, purgar una copia los archivos de registro sólo de acuerdo con las instrucciones del paso 6.


    Las copias de seguridad del archivo de registro no tienen una correspondencia uno a uno con las copias de seguridad de la base de datos. Cada copia de seguridad del archivo de registro es un vínculo en una cadena de archivos de registro que pueden ser reproducible contra cualquiera de varias copias de seguridad de la base de datos diferente. Puede restaurar hacia delante a partir de una copia de seguridad de la base de datos concreta siempre y cuando tenga una secuencia ininterrumpida de registros empezando por el registro que aparece en la línea "Última coherente" del encabezado de la base de datos. En este artículo, el último registro coherente se conoce como el "registro de anclaje bajo".


    Si hace referencia al ejemplo anterior, la última entrada coherente es (0x2CC7, 1F14, 1F7). Los tres números designar un archivo de registro, una página de archivo de registro y un desplazamiento de byte en esa página. Cada archivo de registro contiene aproximadamente 10.000 páginas de 512 bytes. El desplazamiento de página le da una idea de cómo cerrar el archivo de registro está completa (el archivo de registro en el ejemplo anterior es aproximadamente 80 por ciento completo, ya que es equivalente a decimal 7956 0x1F14), pero no es relevante para la recuperación. Recuperación siempre comienza al principio de un archivo de registro.


    En este ejemplo, el archivo de registro baja delimitador es E0n02cc7.log.


    No siempre verá el último registro coherente en disco como un registro numerado, porque el último registro coherente aún denominado archivo E0n.log. Puede ver la secuencia de archivo E0n.log número se dará finalmente examinando el encabezado del archivo de registro mientras se detiene la base de datos (acceso denegado a la cabecera del archivo E0n.log mientras se ejecuta la base de datos).


    Para ver el número de generación interno de registro, ejecute el siguiente comando:
    Eseutil /ml [archivo de registro] | Find /i "lGeneration"
    El siguiente es un ejemplo de la salida del comando anterior:
    E:\mdbdata>eseutil /ml E00.log | find /i "lgeneration"      lGeneration: 11463 (0x2CC7)

    En muchos casos, es más importante para asegurarse de que las copias de seguridad del archivo de registro son correctas de lo que es para asegurarse de que cada copia de seguridad es buena. Esto es porque cada copia de seguridad de la base de datos puede proporcionar redundancia para los demás, pero la recuperación completa de cualquier copia de seguridad de base de datos depende de la conservación de cada archivo de registro después de la copia de seguridad.
  6. Omita este paso si está habilitado el registro circular. Examine el encabezado del archivo de punto de control para determinar el archivo de registro numerados más alto que puede quitarse con seguridad. El punto de control realiza un seguimiento más bajo numerada archivo de registro es necesario para la recuperación automática si la base de datos se detiene anormalmente. Para examinar el archivo de control, ejecute el siguiente comando:
    eseutil /mk E0n.chk
    El siguiente es un ejemplo de la salida del comando anterior:
    D:\exchsrvr\mdbdata>eseutil /mk e00.chk | find /i "checkpoint"      Checkpoint file: e00.chk
    LastFullBackupCheckpoint: (0x0,0,0)
    Checkpoint: (0x2CC7,9607,256)

    La tercera línea, la línea de punto de control, contiene la información relevante (LastFullBackupCheckpoint entrada utiliza copia de seguridad en línea y mantiene todos los ceros si nunca se realiza una copia de seguridad en línea frente a la base de datos). El formato de posición del registro de punto de comprobación es el mismo que la última entrada coherente en el encabezado de la base de datos. En este ejemplo, el punto de control está en E0002cc7.log.


    Si el registro circular está deshabilitado, los archivos de registro se acumulan hasta que se manualmente eliminados o quitados automáticamente por el proceso de copia de seguridad en línea. Si el registro circular está habilitada, no especial de administración antiguos archivos de registro se requiere, porque el servicio de base de datos elimina automáticamente los archivos de registro antiguos después de que el punto de control pasa a través de ellos.


    Después de hacer la copia de seguridad de todos los archivos de registro numerados, puede reclamar espacio en disco por quitar todos los archivos de registro numerados hasta, pero sin incluir, el registro de punto de comprobación.

    Importante: No retire el registro de punto de comprobación.

    En este ejemplo, puede quitar todos los registros hasta E0002cc6.log.
  7. Este paso es opcional. Puede utilizar la utilidad Esefile para comprobar la integridad de nivel de página de las bases de datos copiadas.

    El archivo Esefile.exe está disponible en la carpeta Support en el CD-ROM de Exchange Server 5.5 Service Pack 3, en el CD-ROM de instalación de Exchange 2000 Server o el CD-ROM de instalación de Exchange Server 2003. También se puede obtener el archivo Esefile.exe de Microsoft PSS. La utilidad Esefile funciona para los archivos .edb de Exchange Server 5.0 y 5.5, Exchange 2000 y Exchange 2003.


    Actualmente no hay ningún método que no sea una copia de seguridad en línea para comprobar las sumas de comprobación para cada página de un archivo .stm. El archivo .stm contiene los datos sin procesar. Todos los índices y punteros que organizan esos datos están en el archivo .edb. Un problema en el archivo .stm impide que algunos clientes específicos pérdida de datos, pero no comprometen la integridad estructural o lógica de la base de datos como un todo.


    Para comprobar las sumas de comprobación de página para una base de datos de Exchange, ejecute el siguiente comando de la utilidad Esefile:
    Esefile/s database_name
    El siguiente es un ejemplo de la salida del comando anterior:
    E:\mdbdata>esefile /s priv.edb
    Checksumming
    0 10 20 30 40 50 60 70 80 90 100
    |----|----|----|----|----|----|----|----|----|----|
    ...................................................

    23042 pages seen
    0 bad checksums
    241 uninitialized pages
    0 wrong page numbers

    esefile completes successfully after 10 seconds

    Páginas sin inicializar son aceptables, pero en una base de datos sin problemas, hay 0 sumas de comprobación incorrectas y números de página incorrectos 0.


    Si una base de datos no pasa la comprobación de integridad de utilidad Esefile, la mejor opción es restaurar una copia de seguridad anterior que sabe buena y rehacer la base de datos. Si esas copias de seguridad no está disponible, consulte PSS para obtener consejos acerca de cómo reparar o salvar la base de datos.
  8. Este paso es opcional. Puede utilizar el siguiente comando para comprobar la integridad de la copia de seguridad de los archivos de registro:
    Eseutil /ml E0n
    El siguiente es un ejemplo de la salida del comando anterior:
    k:\backups>eseutil /ml E00 
    Debe ejecutar este comando desde una carpeta que contiene la copia de seguridad de los archivos de registro. También puede ejecutar este comando en la carpeta de registro de ejecución actual, pero si Eseutil intenta leer el encabezado del archivo E0n.log mientras se está ejecutando cualquier base de datos del grupo de almacenamiento, recibirá un error -1032 (JET_errFileAccessDenied).


    Este comando detecta los daños en los archivos de registro y también le advierte si un archivo de registro no se encuentra en medio de una secuencia, o si existe una falta de coincidencia entre cualquiera de los archivos de registro.

Restaurar una copia de seguridad sin conexión de una base de datos de Exchange

Esta sección describe dos métodos para restaurar una copia de seguridad sin conexión:
  • Restauración "Punto en el tiempo". Ningún archivo de registro se reproduce en la base de datos. Todos los datos creados después de la copia de seguridad se pierde.
  • Restauración de "Puesta al día". Los archivos de registro creados después de la copia de seguridad se reproducen en la base de datos. Si están disponibles todos los archivos de registro, se conservan todos los datos que se crean después de la copia de seguridad. Si el registro circular está habilitado, debe realizar una restauración "punto en el tiempo" de la copia de seguridad sin conexión; no puede elegir una restauración "puesta al día".
El conjunto de archivos que va a restaurar debe cumplir los siguientes criterios mínimos:
  • Punto de restauraciones de tiempo, de todas las bases de datos detenidas en el grupo de almacenamiento deben ser coherentes y debe haber un archivo de punto de comprobación válido. No elimine el archivo de punto de comprobación actual o los archivos de registro existentes.
  • Para las restauraciones rollo hacia delante, todas las bases de datos del grupo de almacenamiento deben ser detenido y coherente y deben existir todos los archivos de registro creados después de la hora en que se tomó la copia de seguridad (incluido el archivo E0n.log actual). El archivo de controles debe eliminarse.
Si el conjunto de archivos no cumple las condiciones anteriores, restauración y reproducción podrían no necesariamente un error, pero es probable que reciba un mensaje de error -1216 (JET_errAttachedDatabaseMismatch) durante la recuperación de software.

Tratar con un Error -1216

Medidas de seguridad adicionales de recuperación de software causa en Exchange 2000 y versiones posteriores el -1216 error cuando Exchange detecta los archivos de datos que han sido manipulados manualmente y determina que ejecuta la recuperación con el conjunto de datos actual daría como resultado la pérdida de previamente los datos existentes.

En versiones anteriores de Exchange, si el conjunto de archivos está incompleto, pero es válido para una reproducción correcta, la recuperación de software se inicia sin más advertencia al administrador. En Exchange 2000 y versiones posteriores, el administrador debe invalidar específicamente el error -1216 mediante Eseutil.

Punto en el tiempo de restauración de una copia de seguridad sin conexión

Para realizar un punto de restauración de tiempo de una copia de seguridad sin conexión:
  1. Si la base de datos que desea restaurar está actualmente montada, desmóntelo. Si las otras bases de datos del grupo de almacenamiento se desmontan, base de datos de las bases de datos y transmisión de archivos (.edb y .stm) deben ser coherentes y coincidentes. (Para comprobar la coherencia y coincidencia, consulte el paso 2 en la sección "Forro de an Exchange base de datos sin conexión" de este artículo).

    Si todas las bases de datos del grupo de almacenamiento se desmontan, todas las bases de datos deben ser coherentes y también debe existir un archivo de punto de comprobación válido. Archivo de control válido es un archivo de punto de comprobación que estaba en uso la última vez que se estaban ejecutando cualquiera de las bases de datos del grupo de almacenamiento, que tiene un encabezado que muestra el archivo E0n.log como el punto de control. Si cualquier base de datos del grupo de almacenamiento sigue estando montada, el archivo de punto de control válido es el archivo de punto de comprobación que utiliza actualmente el sistema. Si está ejecutando cualquier base de datos del grupo de almacenamiento, existe un punto de control válido.

    Para comprobar el archivo de punto de comprobación cuando se detienen todas las bases de datos, ejecute los siguientes comandos:
    eseutil /mk E0n.chk | FIND /i "checkpoint"
    Eseutil /ml archivo E0n.log | FIND /i "lgeneration"
    El siguiente es un ejemplo de la salida de los comandos anteriores:
    D:\mdbdata>eseutil /mk e00.chk | find /i "checkpoint"
    Checkpoint file: e00.chk
    LastFullBackupCheckpoint: (0x0,0,0)
    Checkpoint: (0x2cc7,1B59,1A)

    D:\mdbdata>eseutil /ml e00.log |find /i "lgeneration"
    lGeneration: 11463 (0x2cc7)

    En el ejemplo anterior, el punto de control es en el registro con el lGeneration de 0x2cc7, que es e00.log. Por lo tanto, el punto de comprobación se puede considerar válido.

    Si el punto de comprobación no es válida, puede recibir un mensaje de error -1216 (JET_errAttachedDatabaseMismatch) cuando intenta montar una base de datos del grupo de almacenamiento. Este problema puede producirse incluso si todas las bases de datos del grupo de almacenamiento son coherentes.
  2. Copie la copia de seguridad de archivos .edb y .stm en la base de datos y ubicaciones de archivos de transmisión por secuencias. (Para buscar estas ubicaciones, consulte la sección "Antes de comenzar" de este artículo). Compruebe que los archivos restaurados sean consistentes y coincidentes.


    Nota: si las copias de los archivos de base de datos que desea restaurar ya existen en el servidor, copia estos archivos antes de restaurar la base de datos, incluso si los archivos existentes no son iniciables. Quizás pueda reparar, y es posible que pueda para salvar datos de ellos mediante la utilidad Exmerge.
  3. Montar la base de datos restaurada. La base de datos se adjunta al final del archivo archivo E0n.log. Una vez se ha iniciado correctamente la base de datos, no hay archivos de registro existentes anteriormente nunca pueden reproducirse en la base de datos. Las bases de datos de carpetas públicas que contienen miles de carpetas de la jerarquía pueden tardar mucho tiempo en iniciar. Permitir al menos un minuto por cada 1.000 carpetas en la jerarquía.


    En versiones anteriores de Exchange Server, suele ser necesario para ejecutar el ISINTEG-patch comando después de restaurar una copia de seguridad sin conexión de una base de datos de almacén de información para sincronizar la base de datos de almacén de información con el directorio. Al aplicar revisiones para una base de datos de Exchange es necesario, que revisiones se realiza automáticamente por el sistema, a menos que la base de datos restaurada a un servidor diferente, grupo de almacenamiento, o el objeto de base de datos lógica o el objeto de Active Directory para la base de datos se elimina y vuelve a crear en Active Directory. En estos casos, el mensaje de error siguiente se registra en el registro de sucesos de aplicación.
    Tipo de suceso: Error
    Evento origen: MSExchangeIS Mailbox Store
    Categoría del suceso: General
    Evento ID:1087
    Date:5/4/2001
    Tiempo: 8:33: 42 PM
    User:N/A
    Computer:EXCHANGE1
    Descripción: El almacén de información se restauró desde una copia de seguridad sin conexión. En el Administrador del sistema de Exchange de Microsoft, indicar que la base de datos "primer almacenamiento Group\Private almacén de información" se pueden restaurarse, para que se pueda analizar.
    Para resolver este problema, debe hacer clic para activar la casilla de verificación se puede sobrescribir esta base de datos por una restauración en el Administrador del sistema de Exchange, en las propiedades de la base de datos del objeto de base de datos.

Rollo de restauración directa de una copia de seguridad sin conexión

Para la mejor oportunidad de éxito total reproducir archivos de registro en una base de datos restaurada:
  • Conservar una copia de todos los registros de transacciones creadas después de la hora de la copia de seguridad completa más antiguo.
  • No cambie una ruta de acceso de la base de datos sin realizar inmediatamente después de una nueva copia de seguridad completa.
  • No ejecute ESEUTIL /p o ESEUTIL /d sin realizar inmediatamente después de una nueva copia de seguridad completa.
  • No puede agregar ni quitar una base de datos en un grupo de almacenamiento de información sin realizar inmediatamente una copia de seguridad completa de todas las bases de datos del grupo de almacenamiento.
Para comenzar el proceso de restauración:
  1. Si se monta la base de datos que desea restaurar, desmontar y, a continuación, copie los archivos de base de datos que desea restaurar a las rutas apropiadas en el servidor. Si las copias de los archivos de base de datos que desea restaurar ya existen en el servidor, copia estas copias antes de restaurar la base de datos, incluso si los archivos existentes no son iniciables. Los archivos pueden ser reparables, y podrá usar la utilidad Exmerge para salvar datos de ellos.
  2. Desmontar todas las bases de datos del grupo de almacenamiento y, a continuación, ejecute el comando siguiente en cada base de datos en el grupo de almacenamiento de información actual y en cada archivo de base de datos restaurada:
    Eseutil /mh database_file_name | Find /i "coherente"
    Nota: Exchange 2000 Service Pack 2 y posterior no informan del estado de la base de datos como "Coherente" o "Incoherente", sino como "Cierre correcto" o "Cierre con errores". El significado de "Cierre limpio" es igual a "Consistente", y el significado de "Cierre con errores" es el mismo que "Incoherente". Para Exchange 2000 Service Pack 2 o posterior, ejecute este comando adicional para determinar el estado de cada base de datos:

    Eseutil /mh database_name | Find /i "Apagado"
    El siguiente es un ejemplo de la salida del comando anterior:

    D:\mdbdata>eseutil /mh PRIV.EDB   | find /i "consistent"
    State: Consistent
    Last Consistent: (0x2cc7,2692,1ED) 04/12/2001 20:07:46


    I:\mdbdata<eseutil /mh PRIV.stm | find /i "consistent"
    State: Consistent
    Last Consistent: (0x2cc7,2692,1ED) 00/00/1900 00:00:00

    E:\mdbdata>eseutil /mh PRIV2.edb | find /i "consistent"
    State: Consistent
    Last Consistent: (0x2cc7,2685,171) 04/12/2001 20:07:41

    J:\mdbdata>eseutil /mh PRIV2.stm | find /i "consistent"
    State: Consistent
    Last Consistent: (0x2cc7,2685,171) 00/00/1900 00:00:00

    F:\mdbdata>eseutil /mh PRIV3.edb | find /i "consistent"
    State: Consistent
    Last Consistent: (0x2ac8,87,1FC) 04/12/2001 20:05:04

    K:\mdbdata>eseutil /mh PRIV3.stm | find /i "consistent"
    State: Consistent
    Last Consistent: (0x2ac8,87,1FC) 00/00/1900 00:00:00

    G:\mdbdata>eseutil /mh PRIV4.edb | find /i "consistent"
    State: Consistent
    Last Consistent: (0x2cc7,268C,19B) 04/12/2001 20:07:43

    L:\mdbdata>eseutil /mh PRIV4.stm | find /i "consistent"
    State: Consistent
    Last Consistent: (0x2cc7,268C,19B) 00/00/1900 00:00:00

    H:\mdbdata>eseutil /mh PUB.EDB | find /i "consistent"
    State: Consistent
    Last Consistent: (0x2cc7,2699,181) 04/12/2001 20:07:46

    M:\mdbdata>eseutil /mh PUB.stm | find /i "consistent"
    State: Consistent
    Last Consistent: (0x2cc7,2699,181) 00/00/1900 00:00:00

    Este comando tiene tres propósitos:
    • Para comprobar que los archivos de base de datos son coherentes.
    • Para comprobar que los archivos .edb y .stm para cada base de datos son un par coincidente.
    • Para identificar los archivos de registro de anclaje alta y baja, que son los archivos de registro de la primera y la última que se necesitan para recuperar correctamente todos los datos sin generar un error -1216. El último valor coherente más bajo entre todas las bases de datos es el registro bajo delimitador y el último valor coherente más alto es el registro de delimitador alta.
    En el ejemplo anterior, el archivo de registro baja delimitador es E0002ac8.log y el archivo de registro de delimitador alta es E0002cc7.log.
  3. Compruebe que la firma del registro que se graba en cada encabezado de base de datos es la firma del registro bajo delimitador. Ejecute los comandos siguientes:
    Eseutil /mh database_name | Find /i "Firma de registro"
    Eseutil /ml low_anchor_log | Find /i "Firma"
    El siguiente es un ejemplo de la salida del comando anterior:
    D:\mdbdata>eseutil /mh priv.edb | find /i "Log Signature"
    Log Signature: Create time:12/29/2000 21:6:38 Rand:24842 Computer:

    E:\mdbdata>eseutil /mh PRIV2.edb | find /i "consistent"
    Log Signature: Create time:12/29/2000 21:6:38 Rand:24842 Computer:

    F:\mdbdata>eseutil /mh PRIV3.edb | find /i "consistent"
    Log Signature: Create time:12/29/2000 21:6:38 Rand:24842 Computer:

    G:\mdbdata>eseutil /mh PRIV4.edb | find /i "consistent"
    Log Signature: Create time:12/29/2000 21:6:38 Rand:24842 Computer:

    H:\mdbdata>eseutil /mh PUB.EDB | find /i "consistent"
    Log Signature: Create time:12/29/2000 21:6:38 Rand:24842 Computer:


    D:\exchsrvr\mdbdata\save>eseutil /ml e0002ac8.log | find /i "Signature"
    Signature: Create time:12/29/2000 21:6:38 Rand:24842 Computer:
    Signature: Create time:12/29/2000 21:6:40 Rand:67798 Computer:
    Signature: Create time:12/29/2000 21:6:41 Rand:58314 Computer:

    Un archivo de registro puede informar de varias firmas. La primera firma siempre es la firma del archivo de registro; el resto son bases de datos que se estaban ejecutando en el momento en que se creó el archivo de registro. En el ejemplo anterior, las firmas de registro que se graban en los archivos de base de datos coincide con la firma del registro en el registro bajo delimitador.


    Si no puede encontrar el registro bajo delimitador, no puede reproducir los registros hacia delante en esa base de datos. Si no puede encontrar el archivo de registro de anclaje bajo, no podrá reproducir los archivos de registro en las bases de datos. Hay dos métodos que puede utilizar para tratar con un registro bajo delimitador que faltan:
    • Puede quitar todos los archivos de registro. Dado que las bases de datos son todas coherentes, puede iniciar sin la presencia de los archivos de registro, pero perderá cualquier posibilidad de recuperación de datos que ya no está en los archivos de base de datos.
    • Puede quitar las bases de datos con los valores más bajos de coherentes última, hasta que pueda construir una serie de registro ininterrumpida de baja a los anclajes de alta y, a continuación, ejecutar la recuperación de las bases de datos restantes. Cuando las bases de datos eliminados vuelva a poner el grupo de almacenamiento, no podrá reproducir los datos adicionales en ellos.
  4. Compruebe que las ubicaciones de ruta de acceso de base de datos actual son el mismo tal como estaban en el momento en que realizó la copia de seguridad.

    Aunque se puede cambiar la ruta de registro de transacciones o la ruta de trabajo después de realizar una copia de seguridad, sólo puede realizar reproducción del archivo de registro si los archivos de base de datos en los mismos lugares en que se hicieron copias de. Si no está seguro de las ubicaciones originales, ejecute el siguiente comando:
    Eseutil /ml _log "Last_Consistent" | Buscar /i "nombre de base de datos o diseño"
    El siguiente es un ejemplo de la salida del comando anterior:
    N:\mdbdata>eseutil /ml e0002cc7.log |find /i ".edb"
    1 f:\MDBDATA\PRIV3.edb
    2 g:\MDBDATA\PRIV4.edb
    3 d:\MDBDATA\PRIV.EDB
    4 e:\MDBDATA\PRIV2.edb
    5 h:\MDBDATA\PUB.EDB

    d:\mdbdata>eseutil /ml e0002cc7.log |find /i ".stm"
    streaming file: k:\MDBDATA\PRIV3.stm
    streaming file: l:\MDBDATA\PRIV4.stm
    streaming file: i:\MDBDATA\PRIV.stm
    streaming file: j:\MDBDATA\PRIV2.stm
    streaming file: m:\MDBDATA\PUB.stm

    Nota: si el registro bajo delimitador es E0n00001.log, no tendrá información de ruta de acceso en su encabezado, puesto que el encabezado para el primer registro de una serie se genera antes de la primera base de datos nunca se adjunta en el registro. En este caso, debe buscar en el encabezado del registro siguiente para ver la información de ruta de acceso de base de datos. En raras ocasiones, esto puede también ser cierto registros después de que la primera, porque se creó una base de datos o se adjunta a la secuencia de registro después de que se creó el registro.
  5. Recopilar todos los registros, desde lo más adelantados posible en secuencia ininterrumpida, el número de anclaje bajo y copie estos registros en la ruta actual de registros de transacciones. No sobrescribir los registros que ya están instalados en el servidor sin tener que hacer estos registros primero. Para ello, debe restaurar los archivos de registro desde más de un tipo de medio de copia de seguridad.


    En el ejemplo anterior, el anclaje bajo es E0002ac8.log y el delimitador alta es E0002cc7.log. Al examinar los registros disponibles, el mayor registro numerado que puede encontrar puede ser un número menor que el número necesario (por ejemplo, E0002cc6.log, en lugar de 2cc7). Esto suele ocurrir porque el archivo E0n.log aún no se han rellenado y se ha cambiado el nombre a su número de la secuencia. Para determinar si el archivo E0n.log es realmente en el registro de delimitador alta, debe utilizar el siguiente comando para examinar el valor de lGeneration en el encabezado del archivo de registro:
    Eseutil /ml archivo E0n.log | Find /i "lGeneration"
    El siguiente es un ejemplo de la salida del comando anterior:
    N:\mdbdata>eseutil /ml e00.log |find /i "lGeneration"
    lGeneration: 11463 (0x2cc7)

    Nota: para ver el encabezado de un archivo de registro con la utilidad Eseutil, utilice el modificador/ml ; Para ver el encabezado de un archivo de base de datos, utilice el modificador/MH . Si confundir los modificadores, la salida de los comandos es incorrecta.


    Normalmente, el registro de delimitador alta es también el mayor registro disponible, pero esto no es cierto si:
    • Archivos de registro se han destruido en un desastre.


      - o -
    • Va a restaurar todas las bases de datos a la vez en un grupo de almacenamiento.
    En el primer caso, es probable que encuentre errores -1216 durante la recuperación; en el segundo caso, puede reproducir archivos de registro hacia delante, incluso más allá del registro de delimitador alta, siempre que sigan la secuencia lGeneration.
  6. Compruebe que todos los registros de compartan la misma firma de registro y están en secuencia ininterrumpida. Ejecute el siguiente comando:
    Eseutil /ml E0n > nombreDeArchivo.txt
    El siguiente es un ejemplo de la salida del comando anterior:
    d:\mdbdata>eseutil /ml E00 > logverify.txt

    d:\mdbdata>type logverify.txt

    Microsoft(R) Exchange Server(TM) Database Utilities
    Version 6.0
    Copyright (C) Microsoft Corporation 1991-2000. All Rights Reserved.

    Initiating FILE DUMP mode...

    Verifying log files...
    Base name: e00

    Log file: D:\exchsrvr\mdbdata\save1\E0000001.log
    Log file: D:\exchsrvr\mdbdata\save1\E0000002.log
    Log file: D:\exchsrvr\mdbdata\save1\E0000003.log
    Log file: D:\exchsrvr\mdbdata\save1\E0000004.log
    Log file: D:\exchsrvr\mdbdata\save1\E0000005.log
    Log file: D:\exchsrvr\mdbdata\save1\E0000006.log
    Log file: D:\exchsrvr\mdbdata\save1\E0000007.log
    Log file: D:\exchsrvr\mdbdata\save1\E0000008.log
    Log file: D:\exchsrvr\mdbdata\save1\E0000009.log
    Log file: D:\exchsrvr\mdbdata\save1\E000000A.log
    Log file: D:\exchsrvr\mdbdata\save1\E000000B.log
    Log file: D:\exchsrvr\mdbdata\save1\E00.log

    No damaged log files were found.

    Operation completed successfully in 3.305 seconds.

    Este comando Eseutil realiza tres acciones: comprueba cada archivo de registro de daños, informa de cualquier brecha de la secuencia de archivo de registro y detecta errores de coincidencia de firma de registro.


    Todas las firmas de registro deben coincidir entre todos los archivos de registro que son candidatos de reproducción. Debe quitar todos los registros que no tienen coincidencia de firmas antes de que comience la reproducción.


    En este momento, después de quitar los archivos que no hicieron superado las pruebas de comprobación, el registro de transacciones sólo los archivos en la carpeta de registros de transacciones son archivos:
    • Están en secuencia ininterrumpida lGeneration, comenzando por el archivo de registro baja delimitador y continuando hasta al menos el archivo de registro de anclaje alto y más allá de eso, si es posible.
    • Tiene que hacer coincidir las firmas de registro.
  7. Si el registro de delimitador alta ya no se denomina archivo E0n.log, cámbiele el nombre.
  8. Quite el archivo E0n.chk desde la carpeta de la ruta de acceso del sistema.


    En ausencia de un archivo de controles, Exchange Server comienza a reproducir los registros más bajo numerada archivo de registro que está disponible en la carpeta de registros de transacciones: el registro bajo delimitador. Si existe el archivo E0n.chk, Exchange Server comienza la reproducción en el punto de control que se registra en este archivo. Si E0n.chk señala más allá del registro bajo delimitador, reproducción falla completamente para el conjunto de archivos restaurados. En muchos casos, si comete un error con el archivo de punto de comprobación, debe empezar de nuevo restaurar los archivos de base de datos de copia de seguridad.
  9. Como una comprobación final antes de montar el grupo de almacenamiento, compruebe lo siguiente:
    • Todos los archivos de base de datos están presentes en sus rutas de acceso de ejecución.
    • Los únicos archivos de registro en la ruta de registro de transacciones ejecutando son archivos que se inician desde el registro bajo delimitador y continuarán por lo menos en el registro de delimitador alta, con el mayor registro disponible con el nombre de archivo E0n.log.
    • No hay ningún archivo E0n.chk en la carpeta de la ruta de acceso del sistema.
    Ahora podrá montar el grupo de almacenamiento y comenzar a reproducir los registros de transacciones con este conjunto de archivos correctamente. Incluso después de recuperación finalice y se inicia la base de datos, todos los datos de todos los archivos de registro podrían no realmente puedan recuperarse debido a problemas de firma y la ruta de acceso de DB que se producen durante la reproducción. La sección "Trabajar con la base de datos firma y ruta de acceso no coincide" de este artículo proporciona información adicional acerca de estos problemas.
  10. Si el almacén de información no se está ejecutando, inícielo y, a continuación, montar al menos una base de datos del grupo de almacenamiento. Esto hace que la recuperación de software se ejecute en todas las bases de datos del grupo de almacenamiento.


    En versiones anteriores de Exchange Server, normalmente es necesario ejecutar el ISINTEG-patch comando después de restaurar una copia de seguridad sin conexión de una base de datos de almacén de información para sincronizar la base de datos con el directorio. Al aplicar revisiones para una base de datos de Exchange es necesario, que revisiones se realiza automáticamente por el sistema, a menos que la base de datos restaurada a un servidor diferente, grupo de almacenamiento, o el objeto de base de datos lógica o el objeto de Active Directory para la base de datos se elimina y vuelve a crear en Active Directory. En estos casos, el mensaje de error siguiente se registra en el registro de sucesos de aplicación.
    Tipo de suceso: Error
    Evento origen: MSExchangeIS Mailbox Store
    Categoría del suceso: General
    Evento ID:1087
    Date:5/4/2001
    Tiempo: 8:33: 42 PM
    User:N/A
    Computer:EXCHANGE1
    Descripción: El almacén de información se restauró desde una copia de seguridad sin conexión. En el Administrador del sistema de Exchange de Microsoft, indicar que la base de datos "primer almacenamiento Group\Private almacén de información" se pueden restaurarse, para que se pueda analizar.
    Para resolver este problema, debe hacer clic para activar la casilla de verificación se puede sobrescribir esta base de datos por una restauración en el Administrador del sistema de Exchange, en las propiedades de la base de datos del objeto de base de datos.
Compruebe el registro de sucesos de aplicación en el Visor de sucesos de Microsoft Windows NT de ningún error o anomalía que pueda producirse al inicia la base de datos. Se muestra un suceso 301 para cada archivo de registro reproducido. Busque con atención errores y advertencias durante el proceso de recuperación.


Tratar con firma de base de datos y ruta de acceso no coincide

Bases de datos, como archivos de registro, tienen sus propias firmas. Pero aunque no cambiar las firmas de registro después de la hora en que se crea el archivo E0n000001.log, las firmas de la base de datos cambian cada vez que se altera la topología física de la base de datos, sin los cambios que está realizando un seguimiento a través de los archivos de registro. La desfragmentación sin conexión o la reparación de una base de datos con Eseutil cambia la firma de DB. Después de un evento así, la base de datos puede adjuntarse a la misma secuencia de registro que antes, pero la base de datos no acepta la reproducción de las transacciones que se realizaron mientras la base de datos tenía su firma anterior. Una copia anterior de la base de datos no acepta la reproducción de cualquier transacción que se realizó después de cambia la firma de la base de datos.


Porque de esta manera, se restablecen las firmas de la base de datos, es muy recomendable realizar copias de seguridad de base de datos completa de inmediato después de la desfragmentación sin conexión o reparación de una base de datos. Si restaura una copia de la base de datos con la firma anterior más adelante, reproducción tiene éxito hasta que el cambio de la firma, pero perderá todos los cambios realizados después de ese punto.


Si se cambian las rutas de base de datos en medio de una secuencia de registro, el efecto es similar a la del cambio de firmas: se interrumpe la reproducción en el momento del cambio. (La API de copia de seguridad en línea proporciona una utilidad para volver a asignar rutas de acceso durante la recuperación, por lo tanto, la API de copia de seguridad en línea puede reproducir registros completamente, incluso si una ruta de acceso ha cambiado desde que se realizó la copia de seguridad).


Como la firma de DB o DB se encuentran problemas de ruta de acceso durante la reproducción, esos DB firma o ruta de acceso de DB que se información de problemas en el registro de sucesos de aplicación en línea con los eventos 301 reproducción para cada archivo de registro. Los archivos de registro que están más allá del punto del problema parece reproducir correctamente, pero sólo no porque se anota repetidamente la misma advertencia de error de coincidencia. Como norma general, se trunca la reproducción en una base de datos concreta desde el punto en el que se encuentra el primer DB firma o la ruta de acceso error hacer referencia a esa base de datos.


Propiedades

Id. de artículo: 296788 - Última revisión: 22 ene. 2017 - Revisión: 1

Comentarios