Tipos de Backup no SQL Server: Full, Differential e Transaction Log

SQL Server oferece vários tipos de backup, mas três aparecem constantemente na administração do dia a dia: full, differential e transaction-log backups. O mais importante não é decorar o nome de cada um. É compreender o que contém, de que depende e como essas peças são utilizadas durante um restore.

Começa pelo requisito de recuperação

Uma estratégia de backup deve começar com duas perguntas do negócio: quanto dado podemos aceitar perder e quanto tempo podemos demorar a recuperar? Um sistema que pode perder um dia de trabalho tem necessidades diferentes de outro que pode perder apenas alguns minutos. Explore o trabalho de um DBA de SQL Server para aprofundar este ponto.

Frequência, armazenamento, retenção e complexidade de restore devem resultar desses requisitos.

Full backup

Um full database backup contém os dados necessários para representar a base inteira e informação suficiente do transaction log para que o backup possa ficar consistente quando é restaurado. Ele torna-se a base para outras operações de backup.

Em bases pequenas, full backups regulares podem ser simples e práticos. Em bases maiores, fazer apenas full backups pode consumir muito tempo, I/O e armazenamento.

BACKUP DATABASE [Sales]
TO DISK = 'D:\SQLBackups\Sales_full.bak'
WITH CHECKSUM, COMPRESSION;

Differential backup

Um differential backup contém os extents de dados que mudaram desde a differential base, normalmente o último full backup convencional. Cada differential é cumulativo desde essa base; não contém apenas as alterações desde o differential anterior.

Durante restore, normalmente precisas do full que serve de base e do differential mais recente que pretendes usar. Não precisas restaurar todos os differentials intermédios.

BACKUP DATABASE [Sales]
TO DISK = 'D:\SQLBackups\Sales_diff.bak'
WITH DIFFERENTIAL, CHECKSUM, COMPRESSION;

Transaction-log backup

Transaction-log backups capturam registos do log que ainda não foram incluídos na sequência anterior de log backups. São utilizados com bases em full ou bulk-logged recovery model, não em simple.

Log backups frequentes reduzem a exposição a perda de trabalho recente e, quando o recovery model permite, suportam recuperação para um ponto específico no tempo. Também são importantes para a truncation adequada do log. Para uma explicação específica, consulte os modelos de recuperação do SQL Server.

BACKUP LOG [Sales]
TO DISK = 'D:\SQLBackups\Sales_log.trn'
WITH CHECKSUM, COMPRESSION;

Como os três tipos trabalham em conjunto

Imagina um full backup no domingo à noite, differential backups todas as noites e log backups a cada 15 minutos. Se a base falhar na quinta-feira às 14:07, o restore pode começar pelo full de domingo, continuar pelo differential mais recente aplicável e depois pelos log backups necessários até ao ponto desejado.

O differential reduz a quantidade de log backups que precisam ser reproduzidos, enquanto os log backups permitem recuperação muito mais próxima do momento da falha.

Sequência simples de restore

Full e differential são normalmente restaurados com NORECOVERY para manter a base pronta para mais restores. O último passo usa RECOVERY quando a sequência termina.

RESTORE DATABASE [Sales]
FROM DISK = 'D:\SQLBackups\Sales_full.bak'
WITH NORECOVERY;

RESTORE DATABASE [Sales]
FROM DISK = 'D:\SQLBackups\Sales_diff.bak'
WITH NORECOVERY;

RESTORE LOG [Sales]
FROM DISK = 'D:\SQLBackups\Sales_log.trn'
WITH RECOVERY;

E copy-only backups?

Um copy-only full backup é útil quando precisas de um backup full pontual sem alterar a differential base normal. Isso permite criar uma cópia para uma mudança ou necessidade específica sem interferir na estratégia regular.

Por que um job verde não é suficiente

Um job bem-sucedido indica que a operação terminou. Não prova que a organização consegue recuperar. Pode faltar um ficheiro, a retenção pode estar errada, o acesso ao storage pode falhar ou a sequência de restore documentada pode estar incorreta.

Erros comuns

• Fazer backups e nunca fazer restores.
• Usar full recovery sem log backups agendados.
• Pensar que um differential depende do differential anterior.
• Apagar full backups dos quais outros backups ainda dependem.
• Guardar todos os backups no mesmo storage do servidor de produção.
• Definir retenção sem relacioná-la com RPO e RTO.

Com que frequência fazer cada backup?

Não existe um horário universal. Uma estratégia pode combinar full backups periódicos, differentials mais frequentes e log backups muito frequentes. A frequência correta depende de RPO, RTO, tamanho, workload, storage e necessidades operacionais.

A competência real está no restore

Criar um backup é apenas o início. Um DBA deve saber quais ficheiros são necessários para recuperar de determinada falha, em que ordem devem ser restaurados, onde estão guardados, quanto tempo a recuperação demora e como validar a base antes de devolver o serviço aos utilizadores. O artigo complementar sobre o percurso para se tornar DBA de SQL Server desenvolve este tema.

Formação relacionada

O curso de DBA SQL Server inclui desenho de backups, automação, cadeias full/differential/log, point-in-time recovery e exercícios práticos de restore.

Ver o curso de Administração de Bases de Dados SQL Server

Precisa de ajuda para escolher o curso certo?

Se não tiver a certeza por onde começar, contacte a Goalbi Academy e diga-nos qual é o seu nível atual e o que pretende aprender.

Contactar a Goalbi Academy

Referências

Backup overview (SQL Server) - SQL Server

Differential Backups (SQL Server) - SQL Server

Transaction log backups - SQL Server

Back up and Restore of SQL Server Databases - SQL Server