Estratégias diferenciais de backup do MS SQL

Question

Recentemente, tivemos uma falha em um de nossos servidores. O servidor não estava acessível e pudemos obter dados dele. Nós tínhamos um plano de backup que fazia um backup completo a cada segundo dia e depois um backup do diff a cada 6 horas ou algo assim.

Eu uso o Jungle Disk para obter os dados do servidor para um armazenamento externo e foi isso que falhou conosco desta vez. Sempre haverá um atraso entre o backup diferencial ser finalizado e o Jungle Disk tiver copiado o arquivo para a nuvem. E neste caso nosso último backup de diff foi feito 1 hora antes e, portanto, tornou inúteis todos os nossos backups de diff anteriores.

Existe alguma maneira de configurar um backup diff para que eu nem sempre tenha que ter a última versão do backup diff e apenas restaurar o backup com tantos backups diff que eu tenho acesso?

    

Answer 1

Discussão antiga, eu sei, mas eu passei por isso enquanto pesquisava um problema diferente com o JungleDisk.

O problema que o OP tinha era que cada diferencial que era tomado era o mesmo nome do último, e o JungleDisk substitui o antigo backup baseado em nuvem pelo novo arquivo. Não é um problema, a menos que o último backup para a nuvem falhou ... o que aconteceu no caso dele.

Mas a resposta à pergunta do OP é sim, em seu plano de manutenção, renomeie cada backup diferencial com um carimbo de data e hora. Por exemplo, aqui está o plano que cria um nome de arquivo como:

MyDatabaseName_Diff_2012-08-20T01-35-01.BAK

DECLARE @name VARCHAR(50) -- database name  
DECLARE @path VARCHAR(256) -- path for backup files  
DECLARE @fileName VARCHAR(256) -- filename for backup  
DECLARE @fileDate VARCHAR(20) -- used for file name 
DECLARE @fileNameNoExt VARCHAR(256) -- Used to name the backup from the NAME parameter
DECLARE @subDir VARCHAR(256) -- Used to create the subdirectory for the backup
DECLARE @backupSetId as int
DECLARE @noBackupErrorMessage VARCHAR(256)

SET @path = 'C:\Path\To\Your\Backups\'

SELECT @fileDate = REPLACE(REPLACE(CONVERT(VARCHAR(20),GETDATE(),126), ':', '-'), '.', '')

-- Exclude the system databases, as well as any others you don't want to back up.
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 + '\' + @name + '_Diff_' + @fileDate + '.BAK'  
       SET @fileNameNoExt = @name + '\' + @name + '_Diff_' + @fileDate 
       SET @subDir = @path + @name

       EXECUTE master.dbo.xp_create_subdir @subdir

       BACKUP DATABASE @name TO DISK = @fileName WITH DIFFERENTIAL, NOFORMAT, NOINIT,  NAME = @fileNameNoExt, SKIP, NOREWIND, NOUNLOAD,  STATS = 10

       -- Now verify the backup       
       SET @noBackupErrorMessage = N'Verify failed. Backup information for database ' + @name + ' not found.'
       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(@noBackupErrorMessage, 16, 1) end
       RESTORE VERIFYONLY FROM  DISK = @fileName WITH  FILE = @backupSetId,  NOUNLOAD,  NOREWIND


       FETCH NEXT FROM db_cursor INTO @name   
END   

CLOSE db_cursor   
DEALLOCATE db_cursor 

MAS, se você estiver usando o JungleDisk, poderá descobrir que a cadeia de backup está quebrada e não pode fazer backups diferenciais!

    

Answer 2

A proteção dos dados do seu SQL Server começa com os discos - você coloca seus arquivos de dados em unidades RAID dedicadas (idealmente RAID10), coloca seus arquivos de log de transações em outra unidade RAID10 e TEMPDB em outro local. Isto é por razões de desempenho, mas também é para recuperação - se uma das unidades falhar, você tem uma chance. O RAID deve permitir recriações, mas também se sua unidade de dados falhar, você poderá obter as transações mais recentes fora do log de transações.

Em seguida, vêm os backups do SQL Server - eles devem ir para um disco separado e, em seguida, ser retirados do servidor para fita ou para outro servidor externo. Dependendo do tamanho dos bancos de dados e das janelas de manutenção, um backup diário completo pode ser apropriado - ou um backup completo semanalmente. Além disso, faça backups freqüentes do log de transações (talvez por hora) e talvez diferenciais, dependendo do tamanho dos bancos de dados.

A parte final está verificando. Verifique frequentemente suas restaurações, fazendo a restauração em outro lugar. Verifique se os backups estão saindo de alguma forma. Teste de teste de teste