Procedimientos de realización de copias de seguridad y restauración para Exchange

Seleccione idioma Seleccione idioma
Id. de artículo: 296788 - Ver los productos a los que se aplica este artículo
Expandir todo | Contraer todo

En esta página

Resumen

Este artículo describen métodos que puede utilizar para omitir las interfaces (API) de programación de aplicaciones copia de seguridad en línea y manualmente copias de seguridad y restauración las bases de datos del 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, independiente para los fines de copia de seguridad sin conexión y la restauración.Para obtener información adicional acerca de copias de seguridad sin conexión y de instantáneas, haga clic en el número de artículo siguiente para verlo en Microsoft Knowledge Base:
296787XADM: Copia de seguridad sin conexión 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 dispone de la información siguiente:
  • Determinar si o no el registro circular está habilitado para el grupo de almacenamiento. (El registro circular está deshabilitado de forma predeterminada en Exchange.) Para determinar si no está habilitado el registro circular, abra las propiedades del objeto storage_group en el 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 Registro Circular . Los cambios en el registro circular no surte efecto hasta que no se detiene cada base de datos en el 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 restauradas sin conexión.
  • Determinar las ubicaciones de ruta de acceso de su base de datos de Exchange, transmisión, registro de transacciones y archivos punto de control y el prefijo de archivo de registro para el grupo de almacenamiento.

    Para encontrar esta información, abra las propiedades del objeto storage_group en el administrador del sistema de Exchange y, a continuación, ver la página General . Registre los valores para los tres siguientes cuadros:
    • prefijo de archivo de registro (E0n, donde puede ser E0n E00, E01, E02 o E03)
    • ubicación de registro de transacciones (E0n*.log)
    • ubicación de ruta del sistema (E0n.chk)
    Rutas de la base de datos aparecen en las propiedades de base de datos de cada objeto database_name. Registre los valores de los siguientes dos campos para cada base de datos en el grupo de almacenamiento:
    • base de datos de Exchange (.edb)
    • base de datos de secuencias de Exchange (.stm)
Si no está disponible el administrador del sistema de Exchange, encontrará toda la información anterior por leer directamente sin procesar atributos de Active Directory con una herramienta como ADSIEDIT o LDIFDE. Puede utilizar el siguiente comando LDIFDE para generar 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=*))"
Ésta es un ejemplo del resultado del comando anterior:
F D:\Exchsrvr\Mdbdata>LDIFDE 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 a "dc1.child.test.com"
Iniciando sesión como usuario actual utilizando SSPI
Exportando el directorio para el archivo con
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 mbiar, CN = Servicios, CN = Configuration, DC = Test, DC = com
ChangeType: agregar
msExchESEParamCircularLog: 0
msExchESEParamLogFilePath: D:\exchsrvr\MDBDATA
msExchESEParamSystemPath: D:\exchsrvr\MDBDATA
msExchESEParamBaseName: E00

.DN: CN = Public Information Store (EXCHANGE1), CN = Primer grupo de almacenamiento, CN = Informati onStore, CN = Exchange1, CN = Servers, CN = Primer grupo administrativo, CN = Administrative Groups, CN = organización, CN = Microsoft Exchange, CN = Servicios, CN = Configuration, DC = tas 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 = Informat 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 registros de transacciones, debe restaurar los archivos de base de datos (.edb y .stm) en las mismas ubicaciones ruta de acceso desde el que se copiaron los archivos. Por ejemplo, si copia el archivo de base de datos de 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 y E:\Mdbdata F:\Mdbdata, respectivamente. Esta limitación se aplica incluso si desea restaurar la base de datos en un servidor completamente diferente (por ejemplo, en una situación de recuperación de buzón individual).

Si cambia la ruta de acceso de la base de datos tras la última copia de seguridad, sólo parcialmente puede reproducir los 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 registros hasta el punto en que se ha cambiado la ruta de acceso.

Puede restaurar archivos de registro de transacciones (E0n*.log) a 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 los registros de transacciones asociados a, pero las bases de datos no grabar las ubicaciones de los registros de transacciones. Durante la reproducción, los registros "encontrar" las bases de datos utilizando información de ruta de acceso que se almacena en los encabezados de registro de transacciones. (La API de copia de seguridad en línea compensa internamente para cambios de ruta de acceso de base de datos y, por lo tanto, esta limitación no se aplica.)

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

Cómo relacionar con archivos de base de datos de Exchange entre sí

Los archivos .edb y .stm están los repositorios finales para toda la información de base de datos. Con fines la mayoría, tratar estos dos archivos como si fueran un único archivo; copia de seguridad y restaurar estos archivos en tándem. Estos archivos deben permanecer sincronizados cronológicamente entre ellos; un archivo .edb que se copia en un día no coincide con un archivo de transmisión por secuencias que se copia en otro día.

Exchange 2000 o un servidor Exchange 2003 puede admitir hasta cuatro grupos de almacenamiento y cada grupo de almacenamiento puede admitir 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 (los almacenes de información privada y pública).

Cuando se realizan cambios a la base de datos, los cambios se escriben primero en el archivo de registro de transacciones actual y a continuación, para una caché en memoria. Tan pronto como están presentes en la caché de cambios, esos cambios son visibles para los usuarios. Las 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 de la secuencia de archivo de registro hasta que todas las transacciones se hayan vaciado físicamente en el archivo de base de datos. Es normal para el punto de control de posposición de tres o más archivos de registro detrás el 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. Los prefijos de registro válido para 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 de registro para un grupo de almacenamiento se designa como E0n. El archivo de registro actual para un grupo de almacenamiento es siempre E0n.log.

Los registros de transacciones son una 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 de 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 E0n xxxxx . registro.

Si una base de datos se detiene anormalmente, reproducir los registros de archivo (E0n.chk) punto de control el registro de transacciones desde el que debe comenzar la recuperación para restaurar la coherencia de la base de datos. 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 recuperación suave y disco duro es la interpolación de datos de archivo de revisión en el proceso de reproducción de archivos 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 han escrito para todavía. Durante el funcionamiento normal, los archivos de base de datos de Exchange son incoherentes porque no 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, tomado como un todo (considera como la suma de la información de los archivos de base de datos y los registros de transacciones), es siempre coherente a menos que los archivos de registro necesario prematuramente se eliminan.

Copia una base de datos de Exchange sin conexión

Para realizar una copia de una base de datos de Exchange sin conexión de seguridad:
  1. Desmontar la base de datos que desea realizar una copia de seguridad. No es necesario desmontar todas las bases de en el grupo de almacenamiento, sólo el base de datos o bases de datos que desea realizar una copia de seguridad de datos.
  2. Compruebe que los archivos de base de datos (archivo los .edb y .stm) son coherentes y coincidente entre sí. Para ello, ejecute el comando siguiente en cada archivo:
    archivo de base de datos de eseutil /mh | buscar /i "DB firma"
    Nota : Exchange 2000 Service Pack 2 y posterior no informan el estado de la base de datos como "Coherente" o "Incoherente", pero como "Cierre correcto" o "Cierre con errores". El significado de "Cierre correcto" es el mismo como "Coherente" 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 | buscar /i "Apagar"
    Ésta es un ejemplo del resultado 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 los mismos, que demuestra que los archivos .edb y .stm pertenecen al mismo conjunto. (Ambas líneas de firma deben coincidir con carácter por carácter en su totalidad de considerarse a una coincidencia de firma.)

    No sólo deben coincidir con las firmas de DB, pero también deben ser los archivos sincronizados entre sí y coherente. Ejecute el comando siguiente en cada archivo:
    archivo de base de datos de eseutil /mh | buscar /i "coherente"
    El siguiente es un ejemplo del resultado que proviene el 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, ambos archivos de informe "estado: coherente." También deben coincidir con los números hexadecimales en paréntesis para cada archivo (0x2CC7, 1F14, 1F7). La última coherente marca de hora no es necesario para que coincida con. Estos archivos son coherentes y coincidente entre sí.

    Si el archivo informes "estado: incoherentes" o no se sincronizan las posiciones de registro anterior coherente, la base de datos no se ha desmontado limpiamente. Montar y desmontar de nuevo la base de datos. Si los archivos todavía no coinciden correctamente o no son coherentes, póngase en contacto con soporte técnico de Microsoft (PSS) para más obtener ayuda.
  3. Copiar cada archivo de base de datos .edb y su archivo de base de datos de secuencias de .stm correspondiente a una ubicación de copia de seguridad.
  4. Montar la seguridad seguridad de 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 copia todos archivos de registro transacción numerada (los archivos .log de E0n xxxxx ). No haga copia los archivos E0n.log, Res1.log y Res2.log.

    Pueda respaldar archivos de registro numerados en cualquier momento adecuado, incluso inmediatamente después de creación, porque después de un archivo de registro ha cambiado de nombre desde E0n.log E0n xxxxx . log, Exchange no modifica ese archivo nuevo. Sin embargo, en Purgar se copiaron archivos de registro sólo con las instrucciones del paso 6.

    Las copias de archivo de registro de seguridad no tienen una correspondencia uno a uno con las copias de seguridad de base de datos. Cada copia de seguridad del archivo de registro es un vínculo en una cadena de los archivos de registro que pueden ser reproducible a cualquiera de varias copias de seguridad de base de datos diferente. Puede confirmar una copia de seguridad determinado mientras haya una secuencia ininterrumpida de los registros empezando por el registro aparece en la "Última coherente" línea de encabezado de la base de datos. En este artículo, el último registro coherente se conoce como "registro de anclaje baja".

    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 en ese 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 proporciona una idea buena de cómo cerrar el archivo de registro es para que se completa (el archivo de registro en el ejemplo anterior es aproximadamente 80 por ciento completo, porque es equivalente a decimal 7956 0x1F14), pero es irrelevante 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.

    Puede que no siempre vea del último registro coherente en disco como un registro numerado, porque todavía podría llamarse E0n.log al último registro de coherente. Puede ver la secuencia E0n.log número le ofrecerá finalmente examinando el encabezado del archivo de registro mientras se detiene la base de datos (acceso denegado al encabezado E0n.log mientras se ejecuta la base de datos).

    Para ver el número de generación de registro interno, ejecute el comando siguiente:
    eseutil /ml [archivo de registro] | Buscar /i "lGeneration"
    Ésta es un ejemplo del resultado 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 archivo de registro de seguridad son buenas que asegúrese de que cada copia de seguridad de base de datos es buena. Esto es porque cada copia de seguridad de base de datos puede proporcionar redundancia para los demás, pero la recuperación completa de cualquier base de datos de copia de seguridad depende de la preservación de cada archivo de registro después de que la copia de seguridad.
  6. Omitir este paso si está habilitado el registro circular. Examine el encabezado del archivo punto de control para determinar el mayor archivo de registro numerado que puede quitarse con seguridad. El punto de control realiza un seguimiento el menor numerada archivo de registro es necesario para la recuperación automática si la base de datos se detiene anormalmente. Para examinar el archivo punto de control, ejecute el comando siguiente:
    eseutil /mk E0n.chk
    Ésta es un ejemplo del resultado 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 control, contiene la información relevante (LastFullBackupCheckpoint entrada utiliza copia de seguridad con conexión y permanece todo ceros si nunca se realiza una copia de seguridad en línea en la base de datos). El formato de posición de registro de control es igual a la última entrada coherente en el encabezado de base de datos. En este ejemplo, el punto de control es E0002cc7.log.

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

    Después de realizar una copia de todos los archivos registro numerado de seguridad, puede reclamar espacio en disco por quitar todos los archivos de registro numerado hasta, pero sin incluir el registro punto de control.

    importante : no retire el registro punto de control.

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

    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 puede obtener el archivo Esefile.exe de PSS de Microsoft. La utilidad Esefile funciona para los archivos .edb de Exchange Server 5.0 y 5.5, Exchange 2000 y Exchange 2003.

    No hay ningún método distinto de 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 datos sin procesar. Todos los índices y punteros que organizan los datos están en el archivo .edb. Un problema en el archivo .stm provoca algún cliente específico pérdida de datos, pero hace no comprometer la integridad estructural o lógica de la base de datos como un todo.

    Para comprobar las sumas de comprobación página de una base de datos de Exchange, ejecute el comando de utilidad Esefile siguiente:
    Esefile /s database_name
    Ésta es un ejemplo del resultado 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 erróneo 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 conozca sea correcto y para confirmar la base de datos. Si no está disponible una copia de seguridad, consulte PSS para obtener consejos sobre cómo reparar o recuperación de la base de datos.
  8. Este paso es opcional. Puede utilizar el comando siguiente para comprobar la integridad de archivos de registro de copia de seguridad:
    eseutil /ml E0n
    Ésta es un ejemplo del resultado del comando anterior:
    k:\backups>eseutil /ml E00
    							
    Debe ejecutar este comando desde una carpeta que contiene 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 de E0n.log mientras se está ejecutando cualquier base de datos en el grupo de almacenamiento, recibe un error de-1032 (Jet_errFileAccessDenied).

    Este comando detecta daños en los archivos de registro y también le avisa si falta un archivo de registro en la mitad de una secuencia, o si existe una firma no coincide entre cualquiera de los archivos de registro.

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

En esta sección se describen dos métodos para restaurar una copia de seguridad sin conexión:
  • Restauración de "Punto de tiempo". No hay archivos de registro se reproducen en la base de datos. Todos los datos creados después de la copia de seguridad se pierde.
  • Restauración "Confirmar". Los archivos de registro que se crearon después de la copia de seguridad se reproducen en la base de datos. Si están disponibles todos los archivos de registro, todos los datos que se crearon después de la copia de seguridad pueden conservarse. Si el registro circular está habilitado, debe realizar una restauración "punto en el tiempo" de la copia de seguridad sin conexión; no se puede elegir una restauración "Confirmar".
El conjunto de archivos que va a restaurar debe cumplir los criterios mínimos siguientes:
  • Punto en las restauraciones de tiempo, todas las detenido bases de datos en el grupo de almacenamiento deben ser coherente y debe haber un archivo punto de control válido. No elimine el archivo punto de control actual o los archivos de registro existentes.
  • Para las restauraciones de reenvío de rollo todos de las bases de datos en el grupo de almacenamiento deben estar detenido y coherente y deben existir todos los archivos de registro que se crearon después de la hora que se realizó la copia de seguridad (incluido el E0n.log actual). Debe eliminar el archivo punto de control.
Si el conjunto de archivos no cumple las condiciones anteriores, restauración y la reproducción no podrían fallar necesariamente, pero es probable que reciba un mensaje de error-1216 (JET_errAttachedDatabaseMismatch) durante la recuperación de software.

Trabajar con un error de-1216

Protecciones de recuperación de software adicionales en Exchange 2000 y posterior causa la-1216 error cuando Exchange detecta los archivos de datos que se han alterado manualmente y determina que ejecutar 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 es incompleto, pero es válido para una correcta reproducción, recuperación de software se inicia sin más advertencia al administrador. En Exchange 2000 y versiones posteriores, el administrador debe específicamente omitir el error-1216 Eseutil.

Punto de restauración de la hora 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á montada actualmente, se desmontar. Si otras bases de datos en el grupo de almacenamiento se desmontan, esas bases de datos base de datos y transmisión de archivos (.edb y .stm) deben ser coherente y coincidentes. (Para comprobar la coherencia y coincidentes, vea el paso 2 en la sección "Seguridad de un Exchange Database Offline" de este artículo).

    Si todas las bases de datos del grupo de almacenamiento se desmontan, todas las bases de datos deben ser coherente y también debe existir un archivo punto de control válido. Un archivo punto de control válido es un archivo punto de control que estaba en uso la última vez que se estaban ejecutando cualquiera de las bases de datos en el grupo de almacenamiento, que tiene un encabezado listas E0n.log como el punto de control. Si aún está montado cualquier base de datos en el grupo de almacenamiento, el archivo de punto de control válido es el archivo de punto de control siendo utilizado por el sistema. Si se está ejecutando cualquier base de datos en el grupo de almacenamiento, existe un punto de control válido.

    Para comprobar el archivo punto de control cuando se detienen todas las bases de datos, ejecute los comandos siguientes:
    eseutil /mk E0n.chk | FIND /i "punto de control"
    eseutil /ml E0n.log | FIND /i "lgeneration"
    Ésta 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 lGeneration de 0x2cc7, e00.log. Por lo tanto, el punto de control puede considerarse válido.

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

    Nota : realizar una si copias de los archivos de base de datos que desea restaurar ya existen en el servidor, estos archivos de copia de seguridad antes de restaurar la base de datos, incluso si los archivos existentes no son de inicio. Pueden ser reparar, y es posible que se podrá para salvar datos de ellos mediante la utilidad ExMerge.
  3. Montar la base de datos restaurada. La base de datos adjunta al final del archivo E0n.log. Una vez iniciado correctamente la base de datos, nunca se pueden reproducir los archivos de registro existentes anteriormente no en la base de datos. Bases de datos carpetas públicas que contienen miles de carpetas en la jerarquía pueden tardar mucho para iniciar. Permitir al menos un minuto por cada 1.000 carpetas en la jerarquía.

    En versiones anteriores de Exchange Server, normalmente necesarios para ejecutar el ISINTEG - revisión comandos 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 del almacén de información con el directorio. Cuando las revisiones para una base de datos de Exchange es necesario que las revisiones se realiza automáticamente por el sistema, a menos que la base de datos restaurado en un servidor diferente, grupo de almacenamiento, o lógico de base de datos objeto o el objeto de Active Directory para la base de datos ha ha eliminado y vuelve a crear en Active Directory. En estos casos, la siguiente mensaje de error se registra en el registro de sucesos de aplicación.
    Tipo de suceso: error
    Origen del suceso: Almacén de buzón MSExchangeIS
    Categoría del suceso: general
    ID. de suceso: 1087
    Fecha: 4/5/2001
    Tiempo: 8:33:42 P.M.
    Usuario: N/d
    Equipo: Exchange1
    Descripción: El almacén de información se restauró a partir una copia de seguridad sin conexión. En el administrador del sistema de Microsoft Exchange, indique que el base de datos "First Storage Group\Private almacén de información" se permite restaurarse, para que puede modificarse.
    Para resolver este problema, debe hacer clic en 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 base de datos del objeto de base de datos.

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

Para la mejor posibilidad de éxito completo 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 la 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 agrega o quita una base de datos de un grupo de almacenamiento sin realizar inmediatamente una copia de seguridad completa de todas las bases de datos en el grupo de almacenamiento.
Para comenzar el proceso de restauración:
  1. Si la base de datos que desea restaurar está montada, desmontar y copie los archivos de base de datos que desee restaurar a las rutas adecuadas en el servidor. Realizar una si copias de los archivos de base de datos que desea restaurar ya existen en el servidor, copia estas copias de seguridad antes de restaurar la base de datos, incluso si los archivos existentes no son de inicio. Los archivos pueden ser reparar, y puede emplear la utilidad ExMerge para salvar datos de ellos.
  2. Desmontar todas las bases de en el grupo de almacenamiento de datos y ejecute el comando siguiente en cada base de datos en el grupo de almacenamiento actual y con cada archivo de base de datos restaurada:
    eseutil /mh database_file_name | buscar /i "coherente"
    Nota : Exchange 2000 Service Pack 2 y posterior no informan el estado de la base de datos como "Coherente" o "Incoherente" sino como "Cierre correcto" o "Cierre con errores". El significado de "Cierre correcto" es el mismo como "Coherente" 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 | buscar /i "Apagar"
    Ésta es un ejemplo del resultado 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 cada coherente.
    • Para comprobar que los archivos .edb y .stm de cada base de datos son un par coincidente.
    • Identificar los archivos de registro delimitador bajo y alto, que son los archivos de primer y último registro que son necesarios para recuperar correctamente todos los datos sin generar un error de-1216. El menor valor último coherente en 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 de registro que se graba en cada encabezado de la base de datos es la firma del Registro bajo delimitador. Ejecute los comandos siguientes:
    eseutil /mh database_name | buscar /i "Firma de registro"
    eseutil /ml low_anchor_log | buscar /i "Firma"
    Ésta es un ejemplo del resultado 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 al tiempo que se creó el archivo de registro. En el ejemplo anterior, las firmas de registro que se registran en los archivos de base de datos coinciden la firma de registro en el registro bajo delimitador.

    Si no encuentra el registro bajo anclaje, no puede reproducir los registros hacia delante en esa base de datos. Si no encuentra el archivo de registro de anclaje bajo, no puede reproducir cualquier archivos de registro en las bases de datos. Hay dos métodos que puede utilizar para tratar con un registro que faltan de delimitador bajo:
    • Puede quitar todos los archivos de registro. Como las bases de datos son todas coherentes, puede iniciar sin la presencia de los archivos de registro, pero perderá cualquier oportunidad en recuperar datos que no está ya en los archivos de base de datos.
    • Puede quitar las bases de datos con los valores últimos más bajos coherentes, hasta crear una serie de registro ininterrumpida de baja a altas delimitadores y, a continuación, ejecute recuperación en las restantes bases de datos. Al poner las bases de datos eliminados volver en el grupo de almacenamiento, no puede reproducir datos adicionales en ellos.
  4. Compruebe que las ubicaciones de ruta de acceso de base de datos actual son el mismo tal como estaban al tiempo que realizó la copia de seguridad.

    Aunque 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 la reproducción del archivo de registro si los archivos de base de datos están en los mismos lugares que se copia desde. Si no está seguro de las ubicaciones originales, ejecute el comando siguiente:
    eseutil /ml "Last_Consistent"_log | buscar /i "database name or pattern"
    Ésta es un ejemplo del resultado 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 en una serie se genera antes de la primera base de datos nunca está conectada al registro. En este caso, debe buscar en encabezado del Registro siguiente para ver información de ruta de acceso de base de datos. En raras ocasiones, también puede ser true para registros posterior a la primera, porque se ha creado una base de datos o se adjunta a la secuencia de registro después de haber creado el registro.
  5. Recopilar todos los registros, de lo hacia delante como sea posible en estado interrumpido, el número de delimitador baja y copie estos registros en la ruta de los registros de transacciones actual. No sobrescribir los registros que ya están colocados en el servidor sin tener que hacer esos registros primero. Para ello, deberá restaurar archivos de registro de más de un tipo de medios de copia de seguridad.

    En el ejemplo anterior, el delimitador de bajo es E0002ac8.log y el delimitador de alto es E0002cc7.log. Cuando examine 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 E0n.log aún no se ha rellenado y cambia a su número en la secuencia. Para determinar si E0n.log es realmente el registro de delimitador alta, debe utilizar el comando siguiente para examinar el valor de lGeneration en el encabezado del archivo de registro:
    eseutil /ml E0n.log | buscar /i "lGeneration"
    Ésta es un ejemplo del resultado 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 un encabezado de archivo de base de datos, utilice el modificador /mh . Si confundir los modificadores, el resultado de los comandos es incorrecto.

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

      -o bien -
    • Va a restaurar todas las bases de datos a la vez de un grupo de almacenamiento.
    En el primer caso, está probablemente encontrará-1216 errores durante la recuperación; el segundo caso, puede reproducir registro reenvían los archivos, incluso más allá del registro de delimitador alta, mientras continúan la secuencia lGeneration.
  6. Compruebe que todos los registros de compartan la misma firma de registro y están en secuencia ininterrumpida. Ejecute el comando siguiente:
    eseutil /ml E0n > nombreDeArchivo.txt
    Ésta es un ejemplo del resultado 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 hace tres cosas: comprueba cada archivo de registro está dañado, informa de cualquier intervalo en la secuencia de archivo de registro y detecta las diferencias 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 los registros que no tienen coincidencia firmas antes de comenzar la reproducción.

    En este momento, después de quitar los archivos que no pasa las pruebas de comprobación, el registro de transacciones sólo los archivos de la carpeta de registros de transacciones son archivos que:
    • ¿En secuencia ininterrumpida lGeneration, empezando con el archivo de registro baja delimitador y continuando hasta al menos el archivo de registro de delimitador alta y más allá de eso, si es posible.
    • Tiene que coinciden con las firmas de registro.
  7. Si el registro de delimitador alta ya no se denomina E0n.log, cambiarlo.
  8. Quitar el archivo E0n.chk de la carpeta de sistema Path.

    En ausencia de un archivo punto de control, Exchange Server comienza a reproducir los registros del 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, servidor de Exchange comienza a reproducción en el punto de control que se registra en este archivo. Si E0n.chk puntos más allá del Registro bajo delimitador, reproducción falla completamente para el conjunto de archivos restaurado. En muchos casos, si comete un error con el archivo punto de control, debe iniciar a través de restaurar archivos de base de datos desde la copia de seguridad.
  9. Como una comprobación final antes de montar el grupo de almacenamiento, compruebe que:
    • Todos los archivos de base de datos están presentes en sus rutas de ejecución.
    • Los archivos de registro sólo en la ruta de registro de transacciones de ejecución son archivos que iniciar desde el registro bajo delimitador y continúan el registro de delimitador alta, con el mayor registro disponible denominado E0n.log mínimo.
    • Hay ningún archivo de E0n.chk en la carpeta de sistema Path.
    Ahora podrá montar el grupo de almacenamiento y empezar a reproducir los registros de transacciones con este conjunto de archivos correctamente. Incluso después de recuperación finalice y se inicia el base de datos, todos los datos en todos los archivos de registro podrían no realmente recuperarse debido a problemas DB de firma y la ruta de acceso que surgen durante la reproducción de. La sección "no tratar con base de datos de firma y ruta de acceso coincide" de este artículo proporciona información adicional acerca de estos problemas.
  10. Si el almacén de información ya no se está ejecutando, inícielo y, a continuación, montar al menos una base de datos en el grupo de almacenamiento. Esto hace que se ejecutará todas las de las bases de datos en el grupo de almacenamiento de recuperación de software.

    En versiones anteriores de Exchange Server, normalmente deberá ejecutar el ISINTEG - revisión comandos 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. Cuando las revisiones para una base de datos de Exchange es necesario que las revisiones se realiza automáticamente por el sistema, a menos que la base de datos restaurado en un servidor diferente, grupo de almacenamiento, o lógico de base de datos objeto o el objeto de Active Directory para la base de datos ha ha eliminado y vuelve a crear en Active Directory. En estos casos, la siguiente mensaje de error se registra en el registro de sucesos de aplicación.
    Tipo de suceso: error
    Origen del suceso: Almacén de buzón MSExchangeIS
    Categoría del suceso: general
    ID. de suceso: 1087
    Fecha: 4/5/2001
    Tiempo: 8:33:42 P.M.
    Usuario: N/d
    Equipo: Exchange1
    Descripción: El almacén de información se restauró a partir una copia de seguridad sin conexión. En el administrador del sistema de Microsoft Exchange, indique que el base de datos "First Storage Group\Private almacén de información" se permite restaurarse, para que puede modificarse.
    Para resolver este problema, debe hacer clic en 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 base de datos del objeto de base de datos.
Compruebe el registro de sucesos aplicación en el Visor de sucesos de Windows NT Microsoft para cualquier errores o anomalías que pueden producirse cuando se inicia la base de datos. Un evento 301 se muestra para cada archivo de registro reproducido. Inspección cuidadosamente de errores y advertencias durante el proceso de recuperación.

Trabajar con la firma de la base de datos y ruta no coincide

Bases de datos, como los archivos de registro, tienen sus propios firmas. Pero aunque las firmas de registro no cambian después de la hora que se creó el archivo E0n000001.log, las firmas de la base de datos cambian siempre que se modifica la topología física de la base de datos, sin los cambios que realiza un seguimiento a través de los archivos de registro. Desfragmentación sin conexión o reparación de una base de datos con Eseutil cambia la firma de DB. Después de un evento, 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 realizadas 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 se restablecen las firmas de la base de datos de esta manera, le recomendamos realizar copias de seguridad inmediata base de datos completa tras la desfragmentación sin conexión o reparación de una base de datos. Si Restaurar una copia de la base de datos con la firma anterior más adelante, reproducción tiene éxito hasta para el punto de cambiar la firma, pero perderá todos los cambios más allá de ese punto.

Si se cambian las rutas de base de datos en la mitad de una secuencia de registro, el efecto es similar a la de cambiar las firmas: se interrumpe la reproducción en el momento del cambio. (La API de copia de seguridad en línea proporciona una herramienta para reasignar las 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 problemas de la ruta de acceso se encuentran durante la reproducción, esos DB firma o la ruta de acceso de DB problemas se incluyen en el registro en línea con los eventos de 301 reproducción para cada archivo de registro de sucesos de aplicación. Los archivos de registro más allá del punto del problema pueden parecer que reproducir correctamente, pero esto es sólo porque no se registra repetidamente la misma advertencia no coinciden. Como regla general, se trunca reproducción en una base de datos concreta desde el punto en el que primero DB firma o la ruta de acceso encontró el error hacer referencia a esa base de datos es.

Propiedades

Id. de artículo: 296788 - Última revisión: lunes, 03 de diciembre de 2007 - Versión: 4.8
La información de este artículo se refiere a:
  • Microsoft Exchange Server 2003 Enterprise Edition
  • Microsoft Exchange Server 2003 Standard Edition
  • Microsoft Exchange 2000 Server Standard Edition
  • Microsoft Windows Small Business Server 2003 Premium Edition
  • Microsoft Windows Small Business Server 2003 Standard Edition
Palabras clave: 
kbmt kbproductlink kberrmsg kbhowto KB296788 KbMtes
Traducción automática
IMPORTANTE: Este artículo ha sido traducido por un software de traducción automática de Microsoft (http://support.microsoft.com/gp/mtdetails) en lugar de un traductor humano. Microsoft le ofrece artículos traducidos por un traductor humano y artículos traducidos automáticamente para que tenga acceso en su propio idioma a todos los artículos de nuestra base de conocimientos (Knowledge Base). Sin embargo, los artículos traducidos automáticamente pueden contener errores en el vocabulario, la sintaxis o la gramática, como los que un extranjero podría cometer al hablar el idioma. Microsoft no se hace responsable de cualquier imprecisión, error o daño ocasionado por una mala traducción del contenido o como consecuencia de su utilización por nuestros clientes. Microsoft suele actualizar el software de traducción frecuentemente.
Haga clic aquí para ver el artículo original (en inglés): 296788

Enviar comentarios

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com