Como parte de la estrategia de respaldo de información, es importante considerar técnicas que nos permitan asegurar la integridad de los archivos de backup, asi como pruebas de restauración de los mismos. Un error en los archivos de backup puede se fatal ya que nuestros respaldos son los que nos garantizan que, en caso de problemas en el sistema, podamos recuperar nuestra información. SQL Server incluye herramientas que nos permiten reducir el riesgo de que un archivo de backup este dañado al momento de necesitarlo para una recuperación de datos.

Copias de respaldo espejadas (Mirror).- Esta opción solo esta disponible en la edición Enterprise de SQL Server 2008 y permite en una sola sentencia crear dos archivos de backup, la principal y el espejo. Ambas copias son exactamente iguales. teniendo dos copias del mimo backup reducimos la probabilidad de error. Otra ventaja es que una de las copias se puede almacenar en el disco local del servidor de base de datos mientras que la otra se puede almacenar en un servidor remoto a través de carpetas compartidas en la red.

Checksum.- Realiza una suma de comprobación cuando lee un página de datos, cuyos cálculos se almacenan en el archivo de backup. Al momento de hacer la restauración se puede usar la suma de comprobación para verificar si el archivo de backup está dañado. Cuando se utiliza compresión de backup, SQL Server por defecto ejecuta operaciones de checksum.

Ahora vamos a desarrollar unos ejemplos para probar las herramientas mencionadas:

--Backup Mirror (Solo Enterprise Edition)
BACKUP DATABASE AdventureWorks2008R2
TO DISK='D:\BACKUP\AW08Full.bak'
MIRROR TO DISK='\\PERMS16\BACKUP\BD\AW08Full.bak'
WITH FORMAT, CHECKSUM
GO

Al ejecutar la sentencia, el sistema devuelve el siguiente mensaje:
Processed 2320 pages for database 'AdventureWorks2008R2', file 'AdventureWorks2008R2_Data' on file 1.
Processed 36 pages for database 'AdventureWorks2008R2', file 'FileStreamDocuments2008R2' on file 1.
Processed 2 pages for database 'AdventureWorks2008R2', file 'AdventureWorks2008R2_Log' on file 1.
BACKUP DATABASE successfully processed 23237 pages in 5.078 seconds (35.749 MB/sec).

NOTAS:

• Una consideración importante para la ejecución de esta sentencia es que, para poder grabar backups en carpetas compartidas en la red, es necesario que la cuenta del servicio de SQL Server tenga permisos de escritura sobre dicha carpeta. Si se trabaja con cuentas del sistema, como por ejemplo Local System, solo se podrá grabar backups en carpetas locales.
• Tanto el backup con espejo como el checksum recargan el trabajo del backup, por lo que puede haber mayor uso de CPU y mayor demora en la ejecución. Pero esto es algo aceptable considerando los beneficios.

 

Otra forma de validar que las copias de seguridad se encuentran bien es usando el comando RESTORE VERIFYONLY. Este comando lee el archivo de backup de la misma forma que lo haría en un proceso de restauración, pero no llega a restaurar la base de datos. Si la verificación del archivo de backup es correcta, se da por valida la copia de seguridad. Pero si se obtiene un error, ese backup no puede ser considerado para operaciones de recuperación.

RESTORE VERIFYONLY FROM DISK='D:\BACKUP\AW08Full.bak'

Al ejecutar la sentencia, el sistema devuelve el siguiente mensaje:
The backup set on file 1 is valid.

 

Una técnica muy completa para verificar la integridad de los backups es simular la restauración de la base de datos en una ubicación alternativa. El objetivo de esta técnica es verificar la integridad, no solo de los archivos de backup, si no de la base de datos misma luego de restaurada. En resumen los pasos son los siguientes:

1.Verificar cuales son los archivos contenidos en el backup.
2. Restaurar la base da datos de prueba en una ubicación alternativa, en estado de recuperación.
3. Recuperar la base de datos de prueba pero con acceso restringido.
4. Ejecutar una verificación de la base de datos de prueba.
5. Eliminar la base de datos de prueba.

Vamos a detallar cada paso:

PASO 1: Este paso es necesario para ejecutar correctamente el paso 2. Restaurar la base de datos en una ubicación alternativa por lo general implica mover los archivos físicos, ya que no siempre contamos con un servidor para pruebas que tenga la misma estructura de almacenamiento (storage) que el servidor de producción. Con el comando RESTORE FILELISTONLY obtenemos la lista de archivos físicos contenidos en el backup cuya integridad queremos verificar:

--Verificación de archivos
RESTORE FILELISTONLY FROM DISK='D:\BACKUP\AW08Full.bak'

Esta es una vista parcial del resultado de la ejecución de la sentencia anterior, donde muestra los archivos incluidos en el backup y su ubicación física. Con esta información procedemos al paso 2.

 

PASO 2: Procedemos a restaurar la base de datos desde el archivo de backup que utilizamos en el paso anterior, utilizando un nombre diferente para resaltar que es una base de datos de prueba. Con la información de los archivos físicos obtenida en el paso anterior y con el argumento MOVE..TO le indicamos a SQL Server donde debe copiar dichos archivos. Nótese que al final de la sentencia se incluye el argumento NORECOVERY, con el objetivo de dejar la base de datos en estado de recuperación para evitar que alguien pueda conectarse.

--Restauramos la base de datos en una ubicación de prueba
--se deja la BD en estado de recuperación
RESTORE DATABASE AdventureWorks2008R2_TEST
FROM DISK='D:\BACKUP\AW08Full.bak'
WITH
MOVE 'AdventureWorks2008R2_Data'
TO 'E:\TestData\AdventureWorks2008R2_Data_Test.tmdf',
MOVE 'AdventureWorks2008R2_Log'
TO 'E:\TestData\AdventureWorks2008R2_Log_Test.tldf',
MOVE 'FileStreamDocuments2008R2'
TO 'E:\TestData\FileStreamDocuments2008R2_Test',
NORECOVERY
GO

Al ejecutar la sentencia, el sistema devuelve el siguiente mensaje:
Processed 2320 pages for database ‘AdventureWorks2008R2_TEST’, file ‘AdventureWorks2008R2_Data’ on file 1.
Processed 2 pages for database ‘AdventureWorks2008R2_TEST’, file ‘AdventureWorks2008R2_Log’ on file 1.
Processed 36 pages for database ‘AdventureWorks2008R2_TEST’, file ‘FileStreamDocuments2008R2’ on file 1.
RESTORE DATABASE successfully processed 23237 pages in 3.285 seconds (55.261 MB/sec).

Si observamos el Explorador de Objetos de Management Studio, la base de datos restaurada no esta disponible para uso, si no que permanece en estado de recuperación. De esa forma ningún usuario puede conectarse:

 

PASO 3: El siguiente paso es recuperar la base de datos, pero siempre para evitar que algún usuario se conecte, se recupera en el modo de usuario restringido (RESTRICTED_USER). En este modo, solo usuario administradores o propietarios de la base de datos se pueden conectar.

--Se recupera la base de datos pero en modo de usuario restringido
RESTORE DATABASE AdventureWorks2008R2_TEST
WITH RECOVERY, RESTRICTED_USER
GO

Al ejecutar la sentencia, el sistema devuelve el siguiente mensaje:
RESTORE DATABASE successfully processed 0 pages in 1.329 seconds (0.000 MB/sec).

PASO 4: Una ves recuperada la base de datos de prueba, procedemos con la verificación utilizando el comando DBCC CHECKDB. El resultado de este comando debe indicar si la base de datos restaurada se encuentra bien o si presenta errores. Si sucede esto último, el backup utilizado no es válido, por lo que no se debe considerar en futuras acciones de recuperación.

--Ejecutamos el comando de verificación de base de datos
DBCC CHECKDB(AdventureWorks2008R2_TEST)
GO

PASO 5: Una vez terminada la prueba, eliminamos la base de datos creada:

--5. Se elimina la base de datos de prueba
DROP DATABASE AdventureWorks2008R2_TEST
GO

 

En conclusión, es muy importante considerar una estrategia de validación de backups, para que, en caso suceda algún evento que requiera poner en marcha el proceso de recuperación de datos, estemos seguros de que nuestros archivos de backup van a servir. Hay que tener en cuenta que en este artículo hemos considerado la validación desde un único backup full. Pero según nuestra estrategia de respaldo de información,  la validación puede incluir backups diferenciales y de log de transacciones.

Artículos relacionados:

Continuidad del negocio

 

Pueden obtener más información en los siguientes enlaces:

Usar conjuntos de medios de copia de seguridad reflejados

BACKUP

RESTORE VERIFYONLY

DBCC CHECKDB