SQL Server

Descripción de copias de seguridad SQL Server

Paul S. Randal

Un vistazo:

• Copias de seguridad completas
• Copias de seguridad del registro de transacciones
• Copias de seguridad diferenciales
• Planear la estrategia de copia de seguridad e integridad de copia de seguridad

Contenido

Copias de seguridad completas
Copias de seguridad diferenciales
Copias de seguridad de registro de transacciones
Diseño de estrategia de copia de seguridad
Integridad de copia de seguridad
Resumen

¿Realmente necesita realizar copias de seguridad de SQL Server? Sí. A menos que no tiene interés sobre los datos o no le importa tener completamente volver a crear la base de datos en el caso de un desastre, necesita alguna manera de restaurar la base de datos a un punto utilizable. Algunas personas argumentar que tener una copia redundante de la base de datos en otro lugar elimina la necesidad de tener copias de seguridad, pero ¿qué sucede si en la que copiar dañado o inaccesible? Las copias de seguridad siguen siendo necesarios para asegurarse de que siempre puede recuperar.

Pero, ¿qué tipo de copias de seguridad debe tomar? ¿Debe frecuencia tomar ellos? ¿Qué efecto tendrá en la base de datos y la carga de trabajo ¿Y cómo está seguro que son válidos?

Poner en marcha una estrategia de copia de seguridad es realmente más fácil puede pensar, incluso aunque los comandos BACKUP y RESTORE tienen un número inimaginable de opciones. Y podrá ayudarle figura de todo fuera.

Éste es el primer artículo en una serie de tres partes. Aquí en la parte 1, trataré las copias de seguridad. En la parte 2 (septiembre de 2009 problema), hablaré de recuperarse de un desastre utilizando copias de seguridad. Y en la parte 3 (noviembre de 2009 problema), le mire recuperarse de un desastre sin copias de seguridad. Voy a ir un poco más allá de lo habitual en estos artículos pero debe poder seguir junto con la Ayuda del material de fondo.

En el artículo de este mes, explicaré los conceptos básicos sobre cómo los distintos tipos de trabajo de copia de seguridad y cómo es posible que desea utilizar en una estrategia de copia de seguridad. Le ayudará si tiene algún conocimiento de cómo el registro de transacciones funciona (consulte mi artículo" Registro de descripción y recuperación en SQL Server." No es ningún punto de tener copias de seguridad si resulta para estar dañado al intentar utilizarlas, por lo que también explicaré cómo agregar comprueba algunos integridad. El camino se va debunk algunas de las creencias erróneas comunes y proporcionan vínculos a información adicional.

Una cosa que no voy a hacer es explicar cómo funciona la sintaxis BACKUP y cómo realizar los distintos tipos de copia de seguridad. ¿Libros en pantalla de SQL Server tienen excelentes secciones que cubren este por qué lo desperdicia espacio duplicarlo aquí? Consulte el tema" Copia de seguridad (Transact-SQL)"para obtener más información, especialmente la sección de ejemplos al final. El tema" Copia de seguridad y restauración temas de procedimientos (SQL Server Management Studio)"se explica cómo utilizar las herramientas para realizar copias de seguridad. Es mejor revisar los procedimientos después de leer este artículo, como aquí voy a explicar el y el motivo.

La implementación de la estrategia de copia de seguridad es la parte relativamente fácil. Diseñar una estrategia eficaz es importante, aunque se suele pasar por alto parte.

Copias de seguridad completas

El tipo más sencillo de copia de seguridad es una copia de seguridad completa de la base de datos. También es posible hacer una copia de seguridad completa de un único archivo de datos o el grupo de archivos. Sin embargo, no se utilizan con frecuencia y medida todos los principios descritos se aplican a ellos, demasiado, voy a centrarse en copias de seguridad de nivel de base de datos. Pero como de SQL Server 2005, cada uno de los tipos de copia de seguridad más granulares funciona exactamente el mismo (Esto no ocurría así en SQL Server 2000). El mismo se aplica a las copias de seguridad diferenciales, pueden realizarse en el archivo, el grupo de archivos o el nivel de base de datos, pero estos todo el trabajo en la misma forma, así como, independientemente del componente que se copia de seguridad.

Una copia de seguridad completa de la base de datos, proporciona una copia completa de la base de datos y proporciona un único punto a tiempo a la que se puede restaurar la base de datos. Aunque puede tardar muchas horas para que ejecute el proceso de copia de seguridad, todavía sólo puede restaurar la copia de seguridad a un punto único (eficazmente al final de la copia de seguridad, pero explicaré exactamente lo que el punto es más adelante en este artículo). Copia de seguridad completa no permite recuperar hasta cualquier punto en tiempo mientras se estaba ejecutando la copia de seguridad. También es el mismo para las copias de seguridad diferenciales.

Hay un concepto erróneo sobre esto, sin embargo, fuelled por el hecho de que puede utilizar el WITH STOPAT = < un número secuencia de tiempo o registro > opción en una restauración de copias de seguridad completas y diferenciales. Aunque la sintaxis le permite, la opción no tiene ningún efecto y está ahí sólo por comodidad.

Otro concepto erróneo sobre copias de seguridad completas es que sólo contienen datos. Las copias de seguridad completas y diferenciales también contienen algunos registros de transacciones para que el componente restaurado (base de datos, archivo o grupo de archivos) se puede realizar transaccionalmente coherente.

Considere la posibilidad de una transacción de ejemplo se inserta un registro en una tabla con un único índice no agrupado. Las páginas de la tabla y el índice se propagan a través del archivo de datos. La transacción se divide internamente en dos partes: una inserción de registro en una página de datos en la tabla y, a continuación, la inserción del registro necesaria en una página de índice en el índice no agrupado. Si el proceso de copia de seguridad sólo sucede a leer la página de índice no agrupado antes de la inserción de registro, pero lee la página de datos de la tabla después de la inserción de registro, la base de datos representado por sólo los datos de la copia de seguridad es transaccionalmente incoherente.

Aquí es donde el registro de transacciones entra en juego. Si también incluye algunos registros de transacciones en la copia de seguridad, recuperación puede ejecutarse en la copia restaurada de la base de datos, lo que transaccionalmente coherente. Para esta transacción de ejemplo, dependiendo de cuando confirma, la parte de recuperación de restauración puede confirmarlo (lo que significa que aparecerá como confirmada en la copia restaurada de la base de datos) o deshacerlo nuevo (lo que significa no aparecerá en absoluto en la copia restaurada de la base de datos). En cualquier caso, se mantiene la coherencia transaccional, que es crucial.

Copia de seguridad completa hace lo siguiente:

1. Forzar un punto de control de base de datos y tome nota del número de secuencia de registro en este momento. Esto vacía todas las páginas actualizado en la memoria en el disco antes de lee la copia de seguridad para reducir la cantidad de trabajo en que la parte de recuperación de restauración tiene que hacer nada.
2. Iniciar la lectura desde los archivos de datos de la base de datos.
3. Dejar de leer los archivos de datos y hacer que una nota del número de secuencia de registro de inicio de la transacción activa más antigua en ese momento (consulte mi artículo "Descripción registro y recuperación en SQL Server" para obtener una explicación de estas condiciones).
4. Leer tanta registro de transacciones cuando sea necesario.

Explicar el registro de transacciones es necesario se realiza mejor con la ayuda visual en la figura 1 . Los números de color rojos en la escala de tiempo se explican en esta lista:

1. Punto de comprobación y empezar a leer la base de datos.
2. La operación de lectura lee página X.
3. Inicia una transacción.
4. Transacción A realiza un cambio a X de la página. La copia en la copia de seguridad está ahora actualizada. Tenga en cuenta que la copia de seguridad no leerá página X de nuevo, ya pasa ese punto en la base de datos.
5. Inicia la transacción B. No se completa antes de que los datos lean la operación finaliza.
6. Confirma una transacción. Esto confirma los cambios para página X.
7. Los datos de copia de seguridad leen completa de la operación y se inicia el registro de transacciones de lectura.

Figura 1 ejemplo de escala de tiempo de cambios durante una copia completa

Copia de seguridad suficiente el registro de transacciones es necesario para que recuperación pueda ejecutar correctamente durante la restauración y para que todas las páginas de la base de datos estén en el mismo punto en el tiempo, la hora a la que los datos que leer parte de la operación de copia de seguridad completado (7 punto). El registro de transacciones desde el principio de la transacción activo (o no confirmado) más antigua (5 puntos, transacciones B) el final de la copia de seguridad (7 punto), es necesario para permitir la recuperación ejecutar. El registro de transacciones desde la copia de seguridad punto de control (Point 1) al final de la copia de seguridad (7 punto) es necesario para que todas las páginas se ponen en el mismo punto en el tiempo.

Si sólo se incluyen el registro de transacciones de principio de la transacción activa más antigua (punto 5), la copia de la página X que se restauró a partir de la copia de seguridad que se lea en punto 2 podría no actualizarse con los cambios de la transacción A, que se ha producido en 4 puntos. Esto significa que podría no ser transaccionalmente coherente con el resto de la base de datos la vez que la operación de lectura de datos completa (punto 7).

Por lo tanto, el número de secuencia de registro mínimo (LSN) del registro de transacciones que se incluye en la copia de seguridad completa es MIN (LSN de copia de seguridad punto de control, LSN de la transacción activa más antigua) y podría ser para una transacción comienza incluso antes de comienzo de la copia de seguridad. Esto garantiza que la copia restaurada de la base de datos (o restaura, página, archivo, grupo de archivos, base de datos) es totalmente coherente.

Este mecanismo significa que las transacciones no están pausadas de ninguna manera por operaciones de copia de seguridad, aunque la carga de trabajo adicional de E/s en la base de datos de ellos puede ralentizar de algo. La desventaja de este mecanismo es que el registro de transacciones no puede desactivarse para que la duración de la copia de seguridad completa porque es necesario. Si hay mucha actividad de actualización y la copia de seguridad completa tarda mucho tiempo en completarse, esto podría provocar crecimiento del registro de transacciones, un problema que ya he tratado en varios artículos anteriores y en la columna de preguntas y respuestas sobre SQL.

Los datos contenidos en una copia de seguridad completa no están necesariamente todo el contenido de todos los archivos de datos. La copia de seguridad sólo contendrá las páginas asignadas desde los archivos de datos. Por ejemplo, una base de datos un único archivo puede ser de 100 GB, pero sólo contiene 15 GB de datos asignados. En ese caso, la copia de seguridad completa sólo contendrá los 15 GB de datos asignados más el registro de transacciones necesarios. (Sin embargo, la base de datos restaurada será siempre el mismo tamaño que el original, en este caso, 100 GB.)

Otro concepto erróneo es que el proceso de copia de seguridad examina o cambia los datos es copias. Esto es falsas, excepto en un caso único cuando se habilitan las sumas de comprobación de copia de seguridad, que explicaré en breve.

Copias de seguridad diferenciales

El otro tipo de copia de seguridad de los datos es una copia de seguridad diferencial. Una copia de seguridad diferencial realiza las mismas operaciones que copia de seguridad completa, pero sólo contiene todos los datos que ha cambiado o ha agregado desde la anterior copia de seguridad completa. Frecuente aquí es que las copias de seguridad diferenciales son incrementales. Son realmente acumulativas y sucesivos diferenciales después de una copia de seguridad completa y se aumentan de tamaño cuando se cambia o agrega más datos.

En cada 4 GB sección (denominado un intervalo de GAM) de cada archivo de datos existe es una página de base de datos especial denominada un mapa de bits diferencial que realiza el seguimiento de las partes (denominadas extensiones) de esa sección de 4 GB han cambiado desde la copia de seguridad completa última, que indica datos que ha cambiado o ha agregado a la base de datos. (Hay varios otros mapas de bits asignación, demasiado y puede encontrar más información acerca de estos en mi artículo blog" En el motor de almacenamiento: GAM, SGAM, PFS y otros mapas de asignación").

Una copia de seguridad diferencial examina estos mapas de bits y realiza una sólo copia de seguridad los datos de las extensiones de archivo que están marcadas como modificados. La siguiente copia de seguridad completa, restablezca los mapas de bits para que pueda ver, como los cambios de base de datos, más de los se marcarán en los mapas de bits diferencial y diferenciales sucesivas será mayor y más grandes y más. Finalmente, si ha cambiado la mayoría de la base de datos, una copia de seguridad diferencial puede quedar tan grande como la copia de seguridad completa. Puede averiguar cómo gran la siguiente copia de seguridad diferencial va a utilizar una secuencia de comandos escribí que está disponible en mi artículo blog" Nueva secuencia de comandos: ¿cuánto de la base de datos ha cambiado desde la copia de seguridad completa último?." Por cierto, esta secuencia de comandos puede utilizarse también para hacerse una idea de la tasa de renovación de una base de datos, por ejemplo, en una base de datos de contenido de SharePoint.

Como una nota al margen, si desea realizar una copia de seguridad completa de ad-hoc y no restableció a mapas de bits diferencial, debe utilizar la opción WITH COPY_ONLY en la instrucción BACKUP. Esto es muy útil, como en caso contrario los diferenciales siguiente sería se según el ad-hoc copia de seguridad completa realizada, en lugar de en la copia regular de seguridad completa (probablemente programada). Esto podría conducir a problemas grandes cuando intenta restaurar en una situación de desastre.

¿Por qué son copias de seguridad diferenciales útil? Tal como explicaré en la sección de estrategia de copia de seguridad, copias de seguridad diferenciales pueden realmente acelerar las operaciones de restauración permitiendo muchas copias de seguridad de registro de transacciones para omitirse en el proceso de restauración. Es mucho más rápido para avanzar esencialmente en tiempo mediante una copia de seguridad diferencial que al reproducir gran cantidad de registros de transacciones para obtener el mismo punto en el tiempo.

Copias de seguridad de registro de transacciones

Las copias de seguridad del registro de transacciones son posibles sólo en los modelos de recuperación FULL o BULK_LOGGED, mientras que copias de seguridad completas y diferenciales también son posibles en el modelo recuperación SIMPLE.

Una copia de seguridad del registro de transacciones contiene todos los registros de transacciones generados desde la última copia de seguridad del registro (o copia de seguridad completa que inicia una cadena de copia de seguridad del registro) y se utiliza para permitir que la base de datos pueda recuperarse a un punto específico en el tiempo (normalmente el tiempo que derecho antes de que produce un desastre). Esto significa que son incrementales, a diferencia de las copias diferenciales, que son acumulativas. Puesto que estos son incrementales, si desea restaurar la base de datos a un punto determinado en tiempo, necesitará tener todas las transacciones entradas del Registro necesarias para reproducir los cambios en la base de datos hasta que apuntan en tiempo. Estos se incluyen en la cadena de copia de seguridad del registro.

Una cadena de copia de seguridad del registro es una serie continua de copias de seguridad del registro que contienen todos los registros de registro de transacción necesarios para recuperar una base de datos a un punto en el tiempo. Una cadena comienza con una copia de seguridad completa de la base de datos y continúa hasta que algo interrumpe la cadena, evitando más registro copias se hasta que se toma otra copia de seguridad completa (o diferencial).

Las operaciones que romper la cadena de copia de seguridad del registro incluyen cambiar al modelo recuperación SIMPLE, revertir desde una instantánea de base de datos y borrar forzosamente el registro utilizando las opciones WITH NO_LOG o TRUNCATE_ONLY (que no están disponibles en SQL Server 2008). Es recomendable para romper la cadena de copia de seguridad del registro, ya que obliga a otra copia (potencialmente grande) completa en realizarse.

Aunque una cadena de copia de seguridad del registro se expande a una copia de seguridad completa, no es necesario restaurar todas las copias de seguridad registro durante la recuperación. Si ha realizado copia de seguridad, por ejemplo, el domingo por la noche y por la noche el miércoles, con copias de seguridad registro cada media hora desde el domingo por la noche, un completo, a continuación, restaurar la base de datos tras un desastre el viernes podría utilizar copia de seguridad completa del miércoles más todas las copias de seguridad del registro desde el miércoles por la noche en lugar de tener que ir al volver al copia de seguridad completa del domingo por la noche. (El segundo artículo de nuestra serie entrará más profundo en este tema.)

Las copias de seguridad del registro también son necesarios para ayudar a administrar el tamaño del registro de transacciones. En los modelos de recuperación FULL o BULK_LOGGED, el registro no se borrará hasta una copia de seguridad del registro (consulte el artículo de febrero para obtener información detallada de lo que significa traspaso de saldos de registro), por lo que deben realizarse copias de seguridad regulares del registro para evitar que el archivo de registro crezca fuera del control. Si no se puede borrar el registro, el registro crecerá hasta que queda sin espacio. Como tal, si no desea punto-in-time recuperación mediante copias de seguridad del registro, la opción más fácil es cambiar al modelo recuperación SIMPLE y no utilizar los modelos de recuperación FULL o BULK_LOGGED. Trataré esto con más detalle en la entrada de blog" Importancia de la correcta administración de transacciones registro tamaño."

No hay un caso especial en el registro que mejora el rendimiento permitiendo algunas operaciones para ejecutarse como operaciones registradas al mínimo, donde las asignaciones de página iniciadas, no la inserción real de datos. Esto puede mejorar el rendimiento de operaciones, como cargas masivas y reconstruye el índice. En estos casos, no todo sobre la operación se registra, por lo tanto, la copia de seguridad registro registros no contienen suficiente información para reproducir completamente la operación. ¿En ese caso, cómo pueden restauración y recuperación posiblemente funcionan si no hay suficiente información?

La respuesta es que la copia de seguridad primer del Registro siguiente una operación iniciado como mínimo también contendrá algunos datos. Igual que los mapas de bits diferencial he mencionado anteriormente, hay otro mapa de bits denominada el mapa de bits iniciado como mínimo (a veces denominado el mapa cambiado masiva). Este mapa de bits realiza un seguimiento qué extensiones de un archivo de datos han cambiado debido de una operación iniciado como mínimo.

La copia de seguridad registro sigue una operación iniciado como mínimo se examine en estos mapas de bits y también una copia de seguridad esas extensiones de datos que están marcadas como modificado. Los mapas de bits se borran después de que se está digitalizando. Esto significa que la copia de seguridad del registro tiene información suficiente para reproducir completamente los efectos de la operación iniciado como mínimo en la base de datos, cuando se restaura la copia de seguridad del registro. Hay una novedad aunque: es nada en esa copia de seguridad registro que indica cuando ha cambiado cualquier extensión de datos concreto. Para una copia de seguridad registro que también contiene datos de una operación registrada al mínimo no puede restaurarse a cualquier punto de tiempo excepto el final de la hora de período cubierto (o beyond, si la copia de seguridad del registro es parte de una cadena de copia de seguridad del registro que va a restaurar). Por lo tanto, mientras que puede obtener mejoras de rendimiento al cambiar al modelo de recuperación BULK_LOGGED, debe considerar cambiar como una operación temporal, sólo para mejorar el proceso por lotes y una vez finalizado el proceso por lotes, debe volver a FULL y realizar una copia de seguridad de registro tan pronto como sea posible.

También hay una copia de seguridad registro de caso especial para permitir el registro crear una copia de seguridad tras un desastre que daña los archivos de datos. Esto se denomina una copia del registro cola (o registro de cola), donde los archivos de datos pueden ser dañados o destruidos, pero todo el registro de transacción lleva hasta el punto de desastres puede hacerse copia de seguridad. Esto permite la pérdida de trabajo mínima (denominado recuperación actualizada) cuando posteriormente se restaura la base de datos; sin embargo, se admite sólo cuando la base de datos se ejecuta en el modelo de recuperación FULL. Pueden encontrar más información sobre ellos y restricciones con operaciones registradas en el tema de libros en pantalla" Copias de seguridad registro de cola." La primera pantalla me demostrar copias de seguridad del registro cola muestra de conversión que acompaña a este artículo.

En las versiones de SQL Server anteriores a SQL Server 2005, no se podrían realizar copias de seguridad del registro de transacciones simultáneamente con la base de datos completa o copias de seguridad diferenciales de la base de datos, se bloquearán hasta que la copia de seguridad nivel de base de datos completado. Archivos y copias de seguridad de grupo de archivos no causaba copias de seguridad del registro bloquear. Mientras esto complica el proceso de recuperación para archivos y copias de seguridad, había ofrecido ellos una ventaja bloqueando no copias de seguridad del registro. En SQL Server 2005, copias de seguridad todos los de completas y diferenciales (independientemente de componente) funcionan de la misma manera. El comportamiento es ahora que la copia de seguridad registro de transacciones simultáneas finalice, pero no se borra el registro de transacciones hasta la completa o diferencial (que requiere el registro) también finaliza.

Diseño de estrategia de copia de seguridad

Ahora que sabe acerca de los tres tipos de copias de seguridad y cómo funcionan, mostraré cómo puede colocar ellos juntos en una estrategia de copia de seguridad.

Una pregunta común que se obtiene es cómo empezar a pensar una estrategia de copia de seguridad. Siempre gusta decir que no debería diseñe una estrategia de copia de seguridad. Debe diseñar una estrategia de restauración, que le permite restaurar poco posible en el caso de desastre por lo que el tiempo de inactividad es tan pequeño como sea posible conservando aún los datos. Después de que ha trabajado fuera, a continuación, trabajar qué copias de seguridad que necesita, lo que puede realizar las restauraciones que necesita. En otras palabras, la estrategia de copia de seguridad debe permitirle cumplir su objetivo de tiempo de recuperación (RTO) y el objetivo de punto de recuperación (RPO).

Con una estrategia que sólo incluye las copias de seguridad completas algo está limitado en qué puede hacer con restauraciones. Básicamente, sólo puede restaurar a la hora de cada copia de seguridad completa, como en la figura 2 . Si se produce un desastre en 23: 59 sábado, justo antes de la siguiente copia de seguridad completa está programada, a continuación, todo el trabajo desde la última copia de seguridad completa podría perderse. Por este motivo, si es necesario evitarse pérdida de datos y no puede volver a crear los datos, copias de seguridad del registro también se incluyen, como en la figura 3 .

Figura 2 estrategia de copia de seguridad con copias de seguridad sólo completas

Figura 3 la estrategia de copia de seguridad completa y copias de seguridad del registro

Imagine que las copias de seguridad del registro se va a traer cada 30 minutos. Siempre que estén disponibles todas las copias de seguridad, esto significa que se puede restaurar la base de datos en cualquier punto en el tiempo. Sin embargo, esto todavía puede no ser la mejor estrategia. ¿Qué ocurre si produce desastre en 23: 59 sábado con esta estrategia en su lugar? Lo primero que sería realizar un registro de cola de-la-copia de seguridad y, a continuación, iniciar la restauración.

Para restaurar la base de datos hasta el punto de producirse el desastre significaría restaurar copia de seguridad completa del último domingo y, a continuación, de las copias de seguridad de registro 336 (que es seis días de la copia de seguridad del registro cola más de 48 copias de seguridad registro por día, más 47 sábado). Dependiendo de cuánto renovación produjo en la base de datos a través de la semana que podría ser una gran cantidad de registro de transacciones se tardan mucho en reproducir. Claramente no es una estrategia óptima de restauración, pero es una estrategia común aparece en el campo. Si tiene una estrategia de esto, asegúrese de que haya practicado realizando una restauración para saber si puede cumplir el RTO en el caso de desastre.

Para mitigar este problema, algunas estrategias utilice copias de seguridad completas más frecuentes, pero estos podrían ser un proceso terriblemente grandes para realizar cada día, por ejemplo. La alternativa es utilizar copias de seguridad diferenciales, que sólo contienen los datos que han cambiado desde la copia de seguridad completa anterior. Continuando con nuestro ejemplo, esa estrategia se muestra en figura 4 .

estrategia de copia de seguridad con completo, registro y copias de seguridad diferenciales de la figura 4

Con esta estrategia, la recuperación de un desastre en 23: 59 sábado es mucho más rápido. Recuerde que una copia de seguridad diferencial es acumulativa, por lo que la estrategia de restauración es la copia de seguridad completa de domingo, copia de seguridad diferencial de 00: 00 sábado, además de todas las copias de seguridad registro de sábado. Disponer de la copia de seguridad diferencial desde las 00: 00 el sábado significa que todas las copias de las seguridad del registro antes de se pueden omitir, como la copia de seguridad diferencial contiene copias de seguridad igual a la red de resultados de restauración de todos los del registro.

Se trataba de un ejemplo bastante simple y artificioso, pero muestra claramente las ventajas de cada tipo de copia de seguridad. Una vez ha diseñado la estrategia de copia de seguridad, asegúrese de que probarlo para asegurarse de que permite realizar las restauraciones que desee.

Éste es un ejemplo que aparece una imagen de cliente unos años atrás. Un cliente tenía una base de datos dañada y desea recuperar con cero pérdida de datos. Que se han reacios a utilizar sus copias de seguridad y ha intentado ejecutar una reparación en una copia de la base de datos, pero tenía que eliminar datos, forzar en utilizando sus copias de seguridad. Resultó que tenían una copia de seguridad completa de enero más de una copia de seguridad del registro cada media hora hasta abril, copias de seguridad a través de 5.000 en total y todo en cinta! Estoy seguro de que está sucesiva los ojos y pensando "Seguro no funciona," pero de hecho lo hacía; sin embargo, necesitó tres días para hacerlo! El cliente pensaba que tenían una estrategia de copia de seguridad excelente, copias de seguridad modelo además el registro de recuperación FULL, pero su estrategia de copia de seguridad no permite realizar las restauraciones que deseaban.

Integridad de copia de seguridad

No es ningún punto de tener copias de seguridad si encuentra que está dañados al intentar restaurar desde ellos. Por supuesto, la mejor comprobar la validez de las copias de seguridad es restaurar en otro servidor, pero en SQL Server 2005 se introdujo una nueva característica que permite algunas integridad de la copia de seguridad comprueba realizarse sin tener que restaurarlos realmente. Puede utilizar la opción WITH CHECKSUM cuando toma una copia de seguridad (de cualquier diversos).

Esto crea una suma de comprobación a través de la secuencia de copia de seguridad completa, que se almacena en la copia de seguridad. Si la copia de seguridad es una completa o diferencial, y la base de datos tiene página sumas de comprobación habilitada, esta opción también causará las sumas de todas existente página comprobación para probarse como el proceso de copia de seguridad lee las páginas. Si se encuentra una suma de comprobación incorrecta de la página, la operación de copia de seguridad producirá un error. Esto ofrece gran protección contra copia accidentalmente una base de datos que ya esté dañado de alguna manera. (Encontrará más información acerca de las sumas de comprobación de página en el artículo "Sugerencias de arriba para efectiva mantenimiento Database" de agosto de 2008.)

Una vez finalizada la copia de seguridad, puede comprobarse mediante un comando similar al siguiente:

RESTORE VERIFYONLY FROM <backup device(s)> WITH CHECKSUM

Se va a volver a calcular la suma de comprobación a través de la secuencia de copia de seguridad completa y comparar se almacena en la copia de seguridad. Copias de seguridad completas y diferenciales, también probará las sumas de comprobación páginas en las páginas en la copia de seguridad. Si se encuentran problemas, sabrá que la copia de seguridad se ha dañado de alguna manera.

Naturalmente, hay excepciones a la regla, donde puede que desee hacer copias de seguridad una base de datos dañada (si es la única copia de la base de datos que tienen y va a tener para ejecutar Reparar, por ejemplo). En ese caso, puede forzar la copia de seguridad completa con la opción WITH CONTINUE_AFTER_ERROR.

Encontrará más información acerca de la copia de seguridad de la validación en información sobre la validación de copia de seguridad en mi blogy observe también me muestran algunos aspectos de validación de copia de seguridad en la segunda pantalla convierte que acompaña a este artículo.

Resumen

Como ocurre con cualquier tema complejo, hay muchas áreas de copias de seguridad que no disponía de espacio para cubrir pero, ahora que se tratan los aspectos básicos, puede profundizar en algunos de los libros en pantalla y blog vínculos para obtener información más profunda. El mejor lugar para iniciar en los libros en pantalla es el tema" Introducción a copia de seguridad (SQL Server)." En mi blog, puede iniciar con el Categoría de copia de seguridad y restauración.

Un área que puede pensar es evidente en su ausencia es la compresión de copia de seguridad. Esto es deliberado, como va ser cubrirla más adelante en el año de un artículo en todas las tecnologías de compresión nueva en SQL Server 2008. En mientras tanto, puede desproteger el tema de libros en pantalla" Compresión de copia de seguridad (SQL Server)"y también en mi blog.

Si tuviera sumar este artículo en tres puntos de viñeta, serían:

• Asegúrese de que las copias de seguridad.
• Asegúrese de que las copias de seguridad válidas.
• Asegúrese de que las copias de seguridad derecha.

En otras palabras, las copias de seguridad tienen si desea poder restaurar la base de datos siga algo para saber las copias de seguridad funcionarán cuando se necesite para y asegúrese de que puede restaurar desde las copias de seguridad y cumplir el RTO y orden de producción LANZADA.

En el siguiente artículo, explicaré todo acerca de restaurar desde las copias de seguridad, incluidos los distintos tipos de operaciones de restauración y cómo funcionan, restaurar desde varias copias de seguridad y disponibilidad parcial de la base de datos.

Mientras tanto y como siempre, si tiene comentarios o preguntas, colocar me una línea en Paul@SQLskills.com.

Paul S. Randal es el director general de SQLskills.com, un MVP de SQL Server y el director regional de Microsoft. Trabajó en el equipo de motor de almacenamiento de SQL Server de Microsoft de 1999 a 2007. Paul escribió DBCC CHECKDB/reparación para SQL Server 2005 y fue responsable del motor de almacenamiento del núcleo durante el desarrollo de SQL Server 2008. Paul es un experto en recuperación de desastres, alta disponibilidad y mantenimiento de la base de datos y es un regular moderador en congresos todo el mundo. Blogs en SQLskills.com/blogs/paul.