Tim Chapman en Builder Au da una guía para recuperar una base de datos SQL Server mediante el log de transacciones.
Aquí una traducción de los puntos más importantes: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:
Un compañero de trabajo te avisa que ha eliminado accidentalmente datos importantes de la base de datos en producción. Y esos datos deben ser recuperados.
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.
RESTORE DATABASE 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.
6 comentarios:
Gracias me sirvió mucho la información.
Hola, bastante interesante...aunque me gustaria saber, de un programa de contabilidad el cual originalmente tenia BD en access, fue migrado a SQL(archivos c0000000, c0010000...c1000000), como puedo hacer para restaurar como 500 archivos (como esos nombres)de un solo log a SQL Express...., de antemano gracias
Hola Christina, en tu caso, seria necesario que construyas o programes un script que recorra esos 500 archivos, utilizando sentencias DMA.
Saludos,
claro, tienes algo como similar ..mira no conosco eso de sentencias DMA.
Christian
hola he creado dos backups diferenciales y me salen estos errores:
1.- backup set begins at LSN 33000000017100135
earlier log backup that includes LSN 32000000022100001
2.- backup set begins at LSN 33000000023600027
earlier log backup that includes LSN 32000000022100001
que puede ser ?
Puedes tratar de ver si las copias de seguridad del registro están en secuencia ejecutando el comando: RESTORE HEADERONLY FROM 'backup_device_of_log' y consultando las columnas primer LSN y último LSN. El último LSN de la copia de seguridad número 4 debería ser el mismo que el primer LSN de la copia de seguridad número 5. si no es así, hay una copia de seguridad de registro que falta en la secuencia o las dos copias de seguridad del registro no son de la misma imagen de la base de datos (por ejemplo, si cambiaste a modo de recuperación simple entre ambas copias, podría ser eso), pero más probable es que falte una copia de seguridad en la secuencia.
Publicar un comentario