.png)
Fala pessoal, o assunto de hoje é um tema muito importante para o dia a dia de um DBA e para toda e qualquer empresa que lida com dados em um banco SQL Server, política de backup.
Para entender melhor sobre backup no SQL Server, devemos conhecer os tipos primeiramente.
O Backup FULL (Backup completo) é a cópia completa dos dados de um banco, pode ser gerado em qualquer recovery model¹ e seu tamanho é sempre o mesmo que o tamanho ocupado pelos dados no banco. Só depende dele para ser restaurado e é o responsável por iniciar a sequência de arquivos em um plano de restauração.
BACKUP DATABASE AdventureWorks TO DISK = N'D:\BACKUP\AdventureWorks.bak'
O Backup DIFF (backup diferencial) se trata de uma cópia das alterações realizadas entre o ultimo backup full gerado antes dele até o momento da sua geração, pode ser gerado em qualquer recovery model e seu tamanho será crescente de acordo com o volume de alterações realizadas na base, só voltará a diminuir quando um novo backup full for gerado, reiniciando a sequência de arquivos. Para restauração depende do ultimo arquivo full antes dele apenas.
BACKUP DATABASE AdventureWorks TO DISK = N'D:\BACKUP\AdventureWorks_diff.bak' WITH DIFFERENTIAL
O Backup de LOG transacional (backup log) registra todas as transações executadas no banco desde o último backup gerado (independente do tipo) até a sua geração, para ser criado a base precisa estar no recovery model full e já ter um backup full ao menos criado anteriormente nesse estado. O seu tamanho pode variar de acordo com o volume de transações executadas e da janela entre um backup e outro. Permite também o restore "point in time", ou seja, restaurar as transações até um horário específico. Em um plano de restauração os backups de log dependem diretamente do ultimo backup full e de todos os backups anterior a ele, montando uma sequência que será reiniciada apenas na execução do próximo backup do tipo full.
BACKUP LOG AdventureWorks TO DISK = N'D:\BACKUP\AdventureWorks.trn'
Cada tipo de backup tem a sua função, cabe aos DBAs montar estratégias de acordo com cada negócio e necessidade do cliente. A combinação dos tipos de backup devem formar uma política que elimina o risco de perda de informação de maneira que o banco possa ser restaurado o mais próximo da data atual possível.
Toda política de backup requer um plano de restauração eficaz de forma que toda a estrategia possa ser aplicada de forma simples e rápida. Planejar o restore é parte essencial para o bom funcionamento da política de backup.
Vejamos alguns cenários de exemplo
1) A empresa Sole Escritura mantem um banco de dados que recebe informações importadas de outro sistema de hora em hora(6h00, 7h00...), recebe um pacote de arquivos que serão importados pelo sistema e irão gerar dados dentro do banco. A base de dados esta atualmente com 150GB de tamanho. O Diretor da empresa pede que a política de backup garanta que não percam dados por mais de uma hora.
a) Gerar um backup Full nos dias impares, um backup DIFF a cada 12 horas a contar do FULL, um backup LOG a cada 1 hora todos os dias exceto nos horário que já temos outros backups
Ex: Dia 1 --> Full 0h30, Diff 12h30 e Log 1h30, 2h30, 3h30...11h30, 13h30...
Dia 2 --> Diff 0h30, 12h30 e Log 1h30, 2h00, 3h30...11h00, 13h30...
Dia 3 --> inicia a sequência novamente
b) Gerar um backup Full aos domingos, um backup Diff por dia (exceto aos domingos), um backup LOG a cada 1 hora todos os dias exceto nos horário que ja temos outros backups
Ex: Domingo Full 0h30, Segunda a sabado Diff 0h30 e Log todos os dias 1h30, 2h30, 3h30...22h30 e 23h30...
2) A empresa Soli Deo é responsável por um sistema de folha de pagamento, a aplicação usa um banco SQL Server e recebe informações durante todo o horário comercial. A base de dados atualmente esta em 4GB de tamanho.
O Diretor da empresa pede que a política de backup garanta que não percam dados por mais de 10 minutos.
a) Gerar um backup Full diariamente as 0h00, um backup Diff a cada 6 horas, um backup de log a cada 10 minutos exceto nos horário que já temos outros backups
Ex: Diariamente 1 Full 0h00, Diff 6h00, 12h00, 18h00 e Log 0h10, 0h20, 0h30 ...5h50, 6h10 ...
b) Gerar um backup Full aos domingos as 0h00, um backup Diff a cada 4 horas, um backup de log a cada 10 minutos exceto nos horário que já temos outros backups
Ex: Domingo 1 Full 0h00, Domingo Diff 4h00, 8h00, 12h00, 16h00 e 20h00 (segunda a sábado acrescenta as 0h00) e Log 0h10, 0h20, 0h30 ...3h50, 4h10 ...
Uma boa política de backup contém validações dos arquivos gerados, algumas opções como CHECKSUM¹ e RESTORE VERIFYONLY² garantem a integridade dos arquivos. Realizada a validação dos backups deve-se armazena-los em um ambiente diferente de onde temos o banco de dados, seja em fita, HD externo ou em nuvem. Testes de restore periódicos também são indicados (ao menos a cada 15 dias), garantindo que os arquivos armazenados fora estão funcionais.
Os dados de uma empresa são o que ela tem de mais valioso, o backup das informações é de extrema importância. Uma boa estrategia de backup garante a continuidade do negócio e segurança. Inúmeras são as possibilidades, deve-se observar caso a caso e desenvolver o que melhor atende a demanda.
Algumas informações complementares
Os backups criados por uma versão mais recente do SQL Server não podem ser restaurados em versões anteriores do SQL Server.
Planeje espaço em disco para geração dos arquivos
Backup particionado (link)
¹ Recovery Model
Simple | Sem backups de log
As operações que exigem backups de log de transações não têm suporte no modelo de recuperação simples
As alterações desde o backup mais recente estão desprotegidas. No caso de um desastre, essas alterações devem ser refeitas.
Full | Requer backups de log
Nenhum trabalho é perdido devido a um arquivo de dados perdido ou danificado.
Pode executar uma recuperação pontual (por exemplo, antes de um erro de aplicativo ou usuário), supondo que seus backups estejam concluídos até aquele ponto.
Bulk-logged | Requer backups de log
Um suplemento do modelo de recuperação completa que permite operações de cópia em massa de alto desempenho
Reduz o uso de espaços de log usando o mínimo de registro em log para a maioria das operações em massa.
Os backups de log podem ter um tamanho significativo, porque as operações minimamente registradas em log são capturadas no backup de log
Como verificar o valor atual de uma base de dados
SELECT name, recovery_model_desc FROM sys.databases WHERE name = 'AdventureWorks' ;
Alterar o modelo de recuperação de uma base de dados
USE [master] ;
ALTER DATABASE AdventureWorks SET RECOVERY FULL;
USE [master] ;
ALTER DATABASE AdventureWorks SET RECOVERY SIMPLE;
² BACKUP DATABASE AdventureWorks TO DISK = N'D:\BACKUP\AdventureWorks.bak' WITH CHECKSUM
³ RESTORE VERIFYONLY FROM DISK = 'D:\BACKUP\AdventureWorks.bak'
Hoje vimos sobre a importância do backup e como funciona dentro do SQL Server. Gostou desse post? Deixe seu comentário e acompanhe o blog.
Jo 3.16 - Porque Deus amou tanto o mundo que deu seu filho unigênito para que todo aquele que nele crer não pereça mas tenha a vida eterna.