Realice copias de seguridad diferenciales

Transcripción

1 Realice copias de seguridad diferenciales Una copia de seguridad diferencial es casi idéntica a una copia de seguridad completa. Cuando se toma una copia de seguridad diferencial en los SSMS, sólo es necesario cambiar la el tipo de opción de copia de seguridad. El código TSQL para una copia de seguridad diferencial también es prácticamente idéntico a una copia de seguridad completa. Todo lo que tienes que hacer es agregar el DIFERENCIAL CON declaración en su código. Todas las otras opciones son las mismas. El siguiente ejemplo de código muestra una copia de seguridad diferencial añadida a un archivo multimedia que contiene la copia de seguridad correspondiente base de datos completa. Esta copia de seguridad caduca en siete días: BACKUP DATABASE PEDIDOS TO DISK = 'D:\DataBackups\Ped_Full_TQSL.bak' WITH DIFFERENTIAL, RETAINDAYS = 7, NOINIT;

2 Realice copias de seguridad del registro de transacciones Las copias de seguridad del registro de transacciones permiten que el DBA pueda administrar la transacción, y registrar el tamaño, mientras no se requiera tener que hacer con frecuencia copias de seguridad de la base de datos. Esto es especialmente útil para grandes bases de datos que son sólo moderadamente volátiles. Una vez más, se puede ejecutar este proceso ya sea mediante el uso de SSMS o con el código T-SQL. Antes de que usted sea capaz de tomar una válida Copia de seguridad del registro de transacciones, debe hacer dos cosas: Asegúrese de que el modelo de recuperación no está definido en Simple. Tome una copia de seguridad completa que actuará como el punto inicial en el proceso de recuperación. Las copias de seguridad del registro de transacciones con SSMS La mayoría de las opciones son las mismas que se tienen con una copia de seguridad completa. Sin embargo, hay algunas diferencias. La figura que se mostrara a continuación ilustra la página General del cuadro de diálogo Copia de seguridad de base de datos cuando usted está tomando una copia de seguridad del registro de transacciones. Usted notará las siguientes diferencias en el cuadro de diálogo: El modelo de recuperación se establece en FULL. El componente de copia de seguridad se atenúa a cabo. Esta sección no es relevante para copias de seguridad de registro de transacciones.

3 También hay algunas diferencias en la página Opciones. La siguiente imagen proporciona una ilustración de esta página de una copia de seguridad del registro de transacciones. La principal diferencia en este diálogo es la sección de registro de transacciones. La opción predeterminada es truncar el registro de transacciones. Esta sería la opción deseada para la mayoría de mantenimiento estándar. Sin embargo, no siempre es la opción que debe utilizar. La segunda opción, "Realizar copia de seguridad del final del registro y dejar la base de datos en estado de restauración," es la opción que usted elija para llevar a cabo esta importante tarea. El resto de las opciones son idénticas a la base de datos completa y los comportamientos diferenciales de copia de seguridad, aunque por lo general se les aplica un poco diferente. Por ejemplo, si usted toma una serie de copias de seguridad de registro de transacciones entre copias de seguridad de bases de datos completos, es posible que desee poner a todos en el mismo medio. Esto hará que sean más fáciles de restaurar más tarde. Por lo tanto, debe tener cuidado con el uso de las opciones de sobrescritura para asegurar que las copias de seguridad relacionadas se agrupan en un conjunto de medios comunes y que usted sin querer destruya las copias de seguridad de los medios de comunicación establecidos fuera de secuencia. Las copias de seguridad del registro de transacciones con TSQL La sintaxis de TSQL para hacer copias de un registro de transacciones es muy similar a la base de datos y el código de registro de copia de seguridad diferencial. La sintaxis básica es la siguiente: BACKUP LOG { } TO <backup_device> [,...n ] [ WITH { <general_with_options> <log-specific_optionspec> } [,...n ] ] [;]

4 Las opciones son básicamente las mismas, salvo que se tienen estas opciones, así: { NORECOVERY STANDBY = undo_file_name } NO_TRUNCATE El comportamiento predeterminado de una copia de seguridad del registro de transacciones es para truncar el registro. El uso de estas opciones va a cambiar ese comportamiento. En concreto, estas opciones tienen el siguiente impacto: NORECOVERY Esta opción permite al DBA capturar un registro final antes de una restauración. Cuando se utiliza esta opción, el sistema no trunca el registro de transacciones. Después de la copia de seguridad de registro, la base de datos se establece en un estado de recuperación de restaurar la espera de los medios de copia de seguridad. STANDBY Esta opción permite al DBA crear un servidor en espera. Cuando usted toma una copia de seguridad del registro de transacciones utilizando esta opción, a la parte final del registro de transacciones se le realiza una copia de seguridad y la base de datos queda en un estado de sólo lectura. El archivo de deshacer contiene los fragmentos de registro necesarios para aplicar transacciones adicionales. NO_TRUNCATE Se trata de una opción de copia de sólo para el registro que respalda todo el registro de transacciones, pero que no lo trunca. Si la base de datos está dañada, debe utilizar esta opción para capturar el registro. Si usted está tratando de capturar un registro transacciones huérfano después de un fallo en el dispositivo de base de datos, utilice esta opción junto con la opción NORECOVERY. A modo de ejemplo, el código siguiente copia de seguridad del registro de transacciones e inicializar los medios de comunicación. SQL Server truncara el registro de transacciones como parte del proceso de copia de seguridad: TO DISK = 'D:\DataBackups\Ped_LOG_TQSL.bak' WITH INIT; Si usted quisiera tener una copia de seguridad posterior del registro de transacciones y añadirla a los medios de comunicación existentes, la declaración sería el siguiente: TO DISK = 'D:\DataBackups\Ped_LOG_TQSL.bak' WITH NOINIT; En este punto, si la base de datos se daña debido a una corrupción o pérdida de datos, se podría capturar el registro de transacciones huérfano con el siguiente código de ejemplo. Tenga en cuenta, no ejecute esta declaración, a menos que usted tenga todas las copias de

5 seguridad necesarias para restaurar la base de datos. Esta declaración hará la base de datos accesible hasta que se restablezca: TO DISK = 'D:\DataBackups\AW_LOG_TQSL.bak' WITH NOINIT, NO_TRUNCATE, NORECOVERY; Realice copias de seguridad (backup) parciales de bases de datos Hay algunos casos en los cuales cuando se realiza una copia de seguridad completa podría ser un desperdicio. Por ejemplo, suponga que tiene una gran base de datos que almacena muchas tablas de búsqueda estáticas. O tal vez la base de datos contiene un amplio conjunto de datos que se importa de otra base de datos o de otra fuente de datos. En este caso, quizás sólo una pequeña porción de la base de datos es siempre el objetivo de las transacciones de los usuarios. Sería un desperdicio realizar un backup continuamente a toda la base de datos cuando sólo un subconjunto de los datos es realmente necesario para el usuario afectado. Es el escenario perfecto para una copia de seguridad (backup) parcial. Esta es una característica nueva de SQL Server Para que este enfoque funcione, hay que planificar el método mediante la adopción de los siguientes pasos: 1. Crear la base de datos con varios archivos de datos en grupos de archivos 2. Separe los datos no volátiles de los datos de los usuarios afectados mediante la colocación de ellos en grupos de archivos diferentes. 3. Marque los grupos de archivos que contienen los datos no volátiles como de sólo lectura. Ahora ya está listo para realizar una copia de seguridad parcial. Esta opción no está con el apoyo de los SSMS, así que si quieres utilizar este método, usted debe hacerlo a través del código TSQL. En la secuencia de comandos de copia de seguridad, incluya READ_WRITE_FILEGROUPS para indicar a SQL Server que realizara copias de seguridad sólo del grupo de archivos principal y cualquier otro grupo de archivos que está marcado como de lectura / escritura. SQL Server no va a respaldar los grupos de archivos que están marcados como de sólo lectura. Aparte de este comportamiento, la copia de seguridad resultante es idéntica a una copia de seguridad de base de datos estándar. El siguiente código muestra un ejemplo: BACKUP DATABASE PEDIDOS READ_WRITE_FILEGROUPS TO DISK = 'D:\DataBackups\Pedidos_Partial_TQSL.bak' WITH INIT;