Estrategias de recuperación de bases de datos

  • Artículo

 

Última modificación del tema: 2006-06-12

En esta sección se explica la estructura de una base de datos y se tratan las distintas estrategias de recuperación de bases de datos.

Descripción de la estructura de una base de datos

Para entender la forma en que una base de datos se estructura, debe poseer conocimientos sobre niveles de página, niveles de tabla del Motor de almacenamiento extensible (ESE) y niveles de aplicación de una base de datos. A continuación se ofrece una breve descripción de cada uno de estos niveles:

Nivel de página: El archivo contiene una serie ordenada de páginas (por lo general, 4 kilobytes o un múltiplo de 4 kilobytes), donde cada página comparte una estructura organizativa común. Todas las páginas tienen información de encabezado de página y datos de página. Esta información de encabezado incluye las sumas de comprobación de la página con las que Exchange puede comprobar la integridad de los datos y, asimismo, corregir los errores de un solo bit en la página en cuestión.

Nivel de tabla de ESE: Los grupos de páginas forman parte de las tablas que el motor de base de datos ESE administra. Una base de datos de Exchange típica contiene miles de tablas individuales.

Nivel de aplicación: ESE es una base de datos de uso general que pueden utilizar diferentes aplicaciones; así, tanto Exchange como el servicio de directorio Active Directory usan ESE. El motor de base de datos ESE almacena la información en tablas de la forma en que una aplicación concreta lo indique. ESE en sí no entiende las relaciones entre tablas que las aplicaciones definen o el significado de los datos almacenados en cada una de las tablas.

Descripción de las estrategias de recuperación de bases de datos

La estrategia más elemental para la recuperación desde un archivo de base de datos dañado consiste en restaurar una copia conocida de la base de datos a partir de la copia de seguridad y desplazar dicha base de datos usando archivos de registro de transacciones generados posteriormente. Para usar esta estrategia, se dan por hecho las tres siguientes suposiciones:

  • Existe una copia de seguridad de la base de datos en buenas condiciones.
  • Todos los archivos de registro de transacciones generados a partir de la copia de seguridad están disponibles y no dañados.
  • El problema de la base de datos no tiene su origen en un daño lógico o una eliminación no deseada. Por ejemplo, si un antivirus ha tenido que dañar o eliminar mensajes, estos daños y eliminaciones formarán parte del registro de transacciones y se reproducirán en la base de datos tras la restauración a partir de la copia de seguridad.

A continuación se describen otras estrategias de recuperación de bases de datos.

Mover buzones

Cuando un buzón de Exchange se mueve a una base de datos distinta, el Almacén de información de Exchange procesa el contenido del buzón de igual modo a cuando dicho contenido se creó. Los elementos dañados se pasarán por alto, con lo cual mover todos los buzones a una base de datos nueva resulta ser una excelente estrategia para eliminar los elementos dañados y, al mismo tiempo, maximizar la cantidad de contenido de usuario recuperado.

Tras mover un buzón, los perfiles de los clientes de Outlook se actualizarán automáticamente para señalar a los clientes a la nueva base de datos o nuevo servidor. Para que esto suceda, el servidor anterior debe permanecer en línea con el servicio de almacén de información en funcionamiento hasta que todos los clientes hayan iniciado sesión una vez y se les haya redireccionado. En caso de que el servidor anterior no permanezca en línea, los perfiles de los clientes de Outlook deberán actualizarse manualmente o mediante secuencias de comandos.

Tras haber movido un buzón, los archivos sin conexión o en modo caché anteriores seguirán funcionando y, además, se conservará la funcionalidad de reglas del cliente.

Mover un buzón afecta al servidor de destino del mismo modo que si se volvieran a enviar todos los elementos del buzón a la vez, de manera que, si mueve una gran cantidad de buzones, lo más conveniente es hacerlo en momentos de poca actividad e informar antes a los clientes acerca de cuándo se va a proceder a ello y de cómo obtener ayuda en caso de que surjan problemas al iniciar sesión una vez acabado el movimiento.

Del mismo modo, mover una gran cantidad de buzones hará que se genere un mayor número de archivos de registro de transacciones de la base de datos de destino. En consecuencia, durante una operación de movimiento masivo de buzones se deberá supervisar rigurosamente el espacio en disco para los registros de transacciones. En caso de que quede poco espacio en disco para los registros de transacciones, puede realizar una copia de seguridad completa o incremental en línea con el fin de borrar los archivos de registro o habilitar el registro circular antes del movimiento y deshabilitarlo inmediatamente después.

Si mueve todos los buzones a una base de datos nueva y desecha la anterior base de datos, se maximizará la conservación del contenido de usuario recuperable, al tiempo que se reducirá la inactividad de la base de datos.

Para obtener información sobre el modo de mover una base de datos de Exchange a otro servidor o grupo de almacenamiento, consulte Movimiento de una base de datos de buzones de Exchange a otro servidor o grupo de almacenamiento.

Reparación de una base de datos

Normalmente, una base de datos se debe reparar sólo cuando no es viable restaurarla y desplazarla. La reparación de una base de datos requiere con frecuencia más tiempo que restaurarla a partir de la copia de seguridad.

Nota   En caso de que la base de datos esté muy dañada, la reparación tardará más tiempo en ejecutarse y la posibilidad de que se lleve a cabo correctamente será menor. Por el contrario, si lleva a cabo una reparación en una base de datos no dañada o poco dañada usando un hardware de tipo servidor de clase empresarial típico, el proceso durará generalmente una hora por cada 5 GB de datos. Si quiere calcular las duraciones de las reparaciones como parte de la elaboración de acuerdos de nivel de servicio (SLA), deberá realizar su propia prueba comparativa en una base de datos normal ejecutando un hardware parecido al que se usa para Exchange en su organización. En caso de que una base de datos esté muy dañada, la duración de la reparación puede aumentar diez veces o más.

Para obtener más información sobre el modo de usar Eseutil para reparar una base de datos, consulte Modo de reparación de Eseutil /P.

Restauración, reparación y combinación

Con frecuencia, la restauración, reparación y combinación de una base de datos se denomina estrategia híbrida. Esta estrategia es útil cuando existe una copia de seguridad de la base de datos en buenas condiciones pero no se han creado todos los registros de transacciones después de la copia de seguridad.

En tal caso, puede restaurar la copia de seguridad y, al mismo tiempo, reparar la copia de la base de datos dañada en un grupo de almacenamiento de recuperación en el mismo servidor o en un servidor de laboratorio. Así, puede usar la función de grupo de almacenamiento de recuperación para montar ambas copias de la base de datos de forma independiente y combinar los datos de la base de datos reparada en la base de datos restaurada.

Dando por hecho que la reparación se ha llevado a cabo correctamente, esta estrategia presenta la posibilidad de recuperar casi la misma cantidad de datos que si se hubiera dispuesto de los registros de transacciones. Para obtener más información sobre las distintas estrategias híbridas usando grupos de almacenamiento de recuperación, consulte la guía en Uso de grupos de almacenamiento de recuperación de Exchange Server 2003 (https://go.microsoft.com/fwlink/?LinkId=47589).

Información adicional

Para obtener más información, consulte los siguientes temas de la Guía de utilidades de bases de datos de Exchange Server: