Sacar backups de las bases de datos resulta la tarea más importante de todo DBA, y esta tarea se puede poner tediosa cuando lidiamos con ambientes con numerosas bases de datos. También es posible que nuestros jobs de backup o planes de mantenimiento no estén al día con nuevas bases de datos entrando a producción y otras dándose de baja.
Aquí te comparto un script dinámico que te ayudará a sacar backups full de tus bases de datos de usuario usando un cursor, y las guarda en la carpeta ‘D:\Bcksql\’:
DECLARE @name VARCHAR(50) -- Nombre de la BD
DECLARE @path VARCHAR(256) -- Ruta de Backup
DECLARE @fileName VARCHAR(256) -- Nombre de archivo
DECLARE @fileDate VARCHAR(20) -- Fecha para nombre de archivo
SET @path = 'D:\Bcksql\'
SELECT @fileDate = convert(nvarchar,getdate(),112)
DECLARE db_cursor CURSOR FOR
SELECT name
FROM MASTER.dbo.sysdatabases
WHERE name NOT IN ('master','model','msdb','tempdb')
OPEN db_cursor
FETCH NEXT FROM db_cursor INTO @name
WHILE @@FETCH_STATUS = 0
BEGIN
SET @fileName = @path + @name + '_FULL_' + @fileDate + '.bak'
BACKUP DATABASE @name TO DISK = @fileName
WITH NOFORMAT, NOINIT,
NAME = N'Full Database Backup',
SKIP, STATS = 10, CHECKSUM
DECLARE @backupSetId AS INT
SELECT @backupSetId = position
FROM msdb..backupset
WHERE database_name=@name AND backup_set_id=(
SELECT MAX(backup_set_id)
FROM msdb..backupset
WHERE database_name=@name )
IF @backupSetId IS NULL
BEGIN
raiserror(N'Verify failed. Backup information for database'' + @name + ''not found.', 16, 1)
END
RESTORE VERIFYONLY FROM DISK = @fileName WITH FILE = @backupSetId
FETCH NEXT FROM db_cursor INTO @name
END
CLOSE db_cursor
DEALLOCATE db_cursor
Podemos alterar esta query para incluir las bases de datos de sistema incluir sólo estas en un job aparte. Es importante notar también el comando RESTORE VERIFYONLY, el cual realiza una verificación rápida sobre el archivo de backup generado, la cual nos dice si esta puede ser leída y restaurada cuando se le necesite.
Warning: “The created database is dependent on the whole created environment, which means it will get destroyed once the Beanstalk instance gets terminated. If we wish to use this database for future use cases or migrate to other environments, we have the option to perform a snapshot before termination, this way we will have a backup of it available for us.“
Si tienes alguna duda, comentarios o sugerencias, me puedes enviar un correo a bitácoradeundba@gmail.com.