Tim Chapman en Builder Au da una guía para recuperar una base de datos SQL Server mediante el log de transacciones.
Muchos DBA (administradores de bases de datos) le tienen pavor a una cosa. Escuchar que tienen que recuperar la base de datos en un cierto punto en el tiempo, especialmente si la base de datos está en producción. Sin embargo, opina que saber hacerlo, es de suma importancia para un DBA, y debe tenerla en su "lista de habilidades".
El escenario:
Punto 1: Si tienes suerte, tienes un sistema de auditoría de datos que recuperará esos registros de una tabla de auditoría.
Punto 2: Si no estás en el punto 1, tienes que usar el log de transacciones, para "deshacer" las últimas transacciones, hasta el momento en que los datos todavía no fueron eliminados.
El proceso de restauración:
Previos: El modelo de recuperación de la base de datos debe ser FULL o COMPLETO. Sin esto, este manual no tiene razón.
Antes de realizar cualquier proceso, se debe realizar un backup del log de transacciones. Esto es para hacer un backup de las transacciones posteriores a la eliminación accidental, y que estas sean incluidas en el proceso de restauración.
Luego, hay que localizar los archivos de la copia de seguridad, donde sea que estén almacenados en la computadora o la red.
Una buena idea sería copiar esos archivos a otro servidor si la base de datos se va a restaurar en un servidor diferente. En la carpeta de los backups ubicar la última copia de seguridad completa, esa es la que se va a restaurar.
El siguiente script es para una base de datos NewDataBase.
FROM DISK = 'D: \BackupFiles\TestDatabaseFullBackup.bak'
WITH
MOVE 'PreviousDatabase' TO 'D:\DataFiles \TestDatabase.mdf',
MOVE 'PreviousDatabase_log' TO 'D:\DataFiles \TestDatabase_Log.ldf',
NORECOVERY
El código especifica que la localización del archivo de backup completo esta en el disco D del servidor y que se está restaurando el archivo a la base de datos llamada NewDatabase. La sentencia mueve el archivo de datos y el archivo de log desde la copia de seguridad completa a unos nuevos archivos para la base de datos llamada TestDatabase. La ultima sentencia del script, NORECOVERY, es muy importante. El modo NORECOVERY es una de las 3 opciones disponibles, las cuales resumo a continuación:
NORECOVERY
Se utiliza sólo con BACKUP LOG. Realiza una copia de seguridad del final del registro y deja la base de datos en estado de restauración. NORECOVERY resulta útil cuando, en caso de error, se conmuta a una base de datos secundaria y al guardar el final del registro antes de una operación RESTORE.
STANDBY = undo_file_name
Se utiliza sólo con BACKUP LOG. Realiza una copia de seguridad del final del registro y deja la base de datos en modo de sólo lectura y espera. El nombre del archivo para deshacer especifica dónde se almacenarán los cambios que se deben deshacer si se aplican operaciones RESTORE LOG posteriormente. Si el archivo para deshacer con el nombre especificado no existe, SQL Server lo crea. Si el archivo existe, SQL Server lo sobrescribe.
NOREWIND
Especifica que SQL Server mantendrá la cinta abierta después de la operación de copia de seguridad. NOREWIND implica NOUNLOAD. SQL Server mantendrá la propiedad de la unidad de cinta hasta que se utilice un comando BACKUP o RESTORE con WITH REWIND.
Una vez restaurada la copia de seguridad completa usando la opción NORECOVERY, puedes empezar aplicando las copias de seguridad del log de transacciones del backup diferencial.
La copia de seguridad diferencial registra sólo los datos que han cambiado después de la última copia de seguridad de la base de datos. Puede realizar copias de seguridad más frecuentes porque las copias de seguridad diferenciales son más pequeñas y más rápidas que las copias de seguridad de la base de datos.
El registro de transacciones es un registro en serie de todas las transacciones que se han realizado en la base de datos desde que se realizó la última copia de seguridad del registro de transacciones. Con las copias de seguridad del registro de transacciones, puede recuperar la base de datos hasta un momento determinado (por ejemplo, antes de escribir datos no deseados) o hasta el momento del error.
Cuando se usa un plan de mantenimiento de la base de datos para crear las copias de seguridad del log de transacciones, un indicador temporal es típicamente incluido en el nombre del archivo del log de transacciones. El script a continuación aplica 3 copias de seguridad del log de transacciones usando la opción NORECOVERY, y la última sentencia restaura la base de datos la disponibilidad del marco de tiempo (el deseado) al ultimo del archivo del log de transacciones final.
RESTORE LOG NewDatabase
FROM DISK = ''D: \BackupFiles\TestDatabase_TransactionLogBackup1.trn'
WITH NORECOVERY
RESTORE LOG NewDatabase
FROM DISK = ''D: \BackupFiles\ TestDatabase_TransactionLogBackup2.trn'
WITH NORECOVERY
RESTORE LOG NewDatabase
FROM DISK = ''D: \BackupFiles\ TestDatabase_TransactionLogBackup3.trn'
WITH NORECOVERY
RESTORE LOG NewDatabase
FROM DISK = ''D: \BackupFiles\ TestDatabase_TransactionLogBackup4.trn'
WITH RECOVERY
Restaurando un punto en el tiempo
El ejemplo anterior permitió restaurar la base de datos al final del último log de transacciones. Si deseas recuperar en un punto especifico del tiempo, debe utilizarse la opción STOPAT. El script a continuación restaura el cuarto log de transacciones en la secuencia de registro a las 4:01 PM, justo antes del problema.
RESTORE LOG NewDatabase
FROM DISK = ''D: \BackupFiles\ TestDatabase_TransactionLogBackup4.trn'
WITH STOPAT = N'6/28/2007 4:01:45 PM', RECOVERY
Ahora que has restaurado la base de datos al punto que necesitabas, es tiempo de decidir como ayudar a los desarrolladores en ordenar su situación y hacerla mas fácil. La sugerencia es copiar la tabla que los desarrolladores necesitan a una tabla separada sobre el servidor, y con ella el DBA o los desarrolladores debe corregir el problema.
Estar preparado
Restaurar la base de datos a un punto en el tiempo es una de las cosas que nunca deseas tener que hacer, pero necesitarás saber hacerlo si es necesario. Cada empresa tiene una forma distinta de realizar las copias de seguridad, hay que realizar pruebas, y estar practicando posibles casos de pérdida de información.
Comentarios