Cadena de backups
Hace poco hablamos sobre los modelos de recuperación y siguiendo la temática de planes de mantenimiento que hemos llevado, me gustaría tomar un tiempo para ver lo que es la cadena de backups, que sino se cuida puede crear grandes problemas en especial si alguien hace un backup de manera no mal intencionada o cambia el modelo de recuperación para liberar el log de transacciones, para truncarlo y liberar espacio siguiendo ciertos consejos de la red.
La cadena de backup es un orden lógico que se tiene sobre como los backups están siendo ordenados respecto a un backup full, sin este orden no podemos restaurarlos debido a que no tienen un origen en el cual basarse.
Realizare un pequeño experimento para demostrar esto con la base de datos que creamos en el ejemplo pasado, el script esta aquí.
1 2 3 4 5 6 7 8 9 10 | --Backup full EXECUTE master.dbo.DatabaseBackup @Databases = 'TEMP', @Directory = 'C:\Backup', @BackupType = 'FULL', @Verify = 'Y', @Compress = 'Y', @CheckSum = 'Y', @CleanupTime = 24, @LogToTable = 'Y' |
Una vez creados haremos una cadena de update con logs de transacciones.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 | --Hacemos 5 updates con su log de transacciones BEGIN TRANSACTION UPDATE dbo.Prueba SET apaterno = CONVERT(varchar(50), NEWID()), nombre = CONVERT(varchar(50), NEWID()), birthday = GETDATE() COMMIT TRANSACTION EXECUTE master.dbo.DatabaseBackup @Databases = 'TEMP', @Directory = 'C:\Backup', @BackupType = 'Log', @Verify = 'Y', @Compress = 'Y', @CheckSum = 'Y', @CleanupTime = 24, @LogToTable = 'Y' GO 5 |
Luego romperemos la cadena de conexión al cambiar el modelo de recuperación y haremos un full backup de la misma.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | --Rompemos la cadena de backups ALTER DATABASE TEMP SET RECOVERY SIMPLE GO --Hacemos un backup full EXECUTE master.dbo.DatabaseBackup @Databases = 'TEMP', @Directory = 'C:\Backup', @BackupType = 'FULL', @Verify = 'Y', @Compress = 'Y', @CheckSum = 'Y', @CleanupTime = 24, @LogToTable = 'Y' GO |
Una vez que tenemos esto revisaremos los resultados que obtenemos en la MSDB la cual almacena el historial de backups.
1 2 3 4 5 6 7 8 9 10 | SELECT [backup_start_date], [type], [first_lsn], [database_backup_lsn] FROM [msdb].[dbo].[backupset] WHERE [database_name] = N'temp'; GO |
Con esto obtenemos la cadena de backups.
1 2 3 4 5 6 7 8 9 | backup_start_date type first_lsn database_backup_lsn
2015-08-23 14:24:58.000 D 52000000033500188 0
2015-08-23 14:25:19.000 L 52000000033500188 52000000033500188
2015-08-23 14:25:22.000 L 58000000043900001 52000000033500188
2015-08-23 14:25:25.000 L 67000000036500001 52000000033500188
2015-08-23 14:25:27.000 L 76000000089400001 52000000033500188
2015-08-23 14:25:28.000 L 82000000047000001 52000000033500188
2015-08-23 14:25:42.000 D 88000000050800075 52000000033500188
2015-08-23 14:26:39.000 D 88000000055300037 88000000050800075
|
Las "D" identifican backups full, mientras las "L" del log de transacciones, si pueden apreciar las primeras 5 del log de transacciones incrementan su LSN (Log sequence number o número de secuencia de registro) pero hacen referencia al first_lsn que es su backup full, ahora vien si vemos el registro de cual cambiamos a modelo de recuperación simple o sea la segunda "D" al siguiente backup ya no tiene referencia al primero, esto quiere decir que inicia una nueva cadena, esto que nos dice, si alguien rompe una cadena, digamos el área de desarrollo para poder tomar una copia de la base, ellos romperían la cadena y ya perdemos el punto de restauración hasta este minuto, con una buena planeación es posible que no haya mayor impacto pero se debe de tener cuidado con esto.
Comentarios
Publicar un comentario