Cuidados com o Backup do seu banco de dados SQL Server

Paulo Sergio Pereira

 

Neste artigo vou mostrar uma situação interessante que aconteceu comigo outro dia e que espero que não aconteça com vocês. A alguns meses atrás ajudei um amigo que trabalha com SQL Server más sem muita experiência a instalar  e configurar uma base de dados SQL Server, ajudei-o a montar também uma estratégia de backup de maneira que ficou tudo automático. Criamos scripts no banco de dados  e agendamos a execução usando o SQL Server Agent. A estratégia funciona da seguinte maneira:

 

1)     No domingo é feito um backup full (ver Nota 1) do banco as 00:00;

2)     Diariamente é feito um backup diferencial (ver Nota 2) do banco as 23:00;

3)     Diariamente de 3 em 3 horas é feito um backup do Log de transações (ver Nota 3);

 

Até aí nenhum problema, esta estratégia de backup tem sido utilizada a mais de seis meses e foi validada quando implantamos o sistema porém depois disso nunca foi necessário fazer o restore da base de dados então na pratica o backup nunca havia sido utilizado. Para o restore do banco de dados seriam necessários os seguintes passos:

 

1)     Fazer o restore do ultimo backup full;

2)     Fazer o restore do ultimo backup diferencial;

3)     Fazer o restore dos logs após o ultimo backup diferencial;

 

 

Nota 1. Backup FULL

Este é o tipo de backup que copia todas as informações do banco de dados, incluindo todos os filegroups e os arquivos do banco de dados. Este tipo de backup pode ser inviável para bases de dados muito grandes pois será necessário um período maior para a execução do processo.

 

 

Nota 2. Backup Diferencial

O backup diferencial do banco de dados contém os dados incluídos, excluídos ou alterados após o ultimo backup full, após restaurar o backup full devemos restaurar o ultimo backup incremental efetuado.

 

 

Nota 3. Backup do Log de Transações

Este tipo de backup faz cópia das informações contidas no log de transações do SQL Server, pode ser utilizado com os backup full e diferencial para minimizar a perda de dados em caso de necessidade de restauração do banco de dados.

 

 

O problema

Agora vamos a minha historia: A alguns dias meu amigo me liga desesperado dizendo que a nossa estratégia de backup estava com problemas pois ele precisava restaurar a base de dados (ele removeu os registros de uma tabela sem querer) e não estava conseguindo, na hora pensei comigo “ele deve estar tentando restaurar o backup na ordem incorreta”.

Para minha surpresa quando cheguei ao local ele estava restaurando o backup na ordem correta porém o SQL Server exibia uma mensagem de erro e o backup não era restaurado, veja na Figura 1 a mensagem exibida pelo SQL Server (simulei este acontecimento em meu Notebook depois para escrever este artigo). Este erro estava ocorrendo quando estávamos restaurando o ultimo backup diferencial, o ultimo backup full era restaurado sem problemas porém eles perderiam as informações de quase uma semana inteira de trabalho.

 

28-12pic01.bmp 

Figura 1. Fazendo o restore da base de dados

 

Fiquei pensando o que poderia haver de errado com o backup pois quando implantamos o sistema estava tudo certo, fizemos vários backups e restauramos várias vezes o banco também para validar a estratégia de backup. Foi aí que me veio a idéia de verificar nas propriedades do banco a data do ultimo backup (tenho uma boa experiência com SQL Server más nunca havia me deparado com essa situação) e foi aí que descobri que após o ultimo backup full havia sido feito um outro full durante a semana. Agora eu havia descoberto a causa do problema porém a solução seria mais difícil. Quando questionei meu amigo sobre esse backup full feito fora dos planos ele me disse que realmente havia feito um backup full durante a semana pois ele iria fazer alterações em algumas tabelas e fez um backup full caso algum problema ocorresse. Foi aí que veio a pergunta:

-          Onde está o arquivo com este backup que você fez?

A resposta dele

-          Como deu tudo certo depois da manutenção que fiz eu apaguei este arquivo.

 

Foi quando expliquei para ele o que havia acontecido, estávamos tentando restaurar um backup diferencial porém depois do ultimo backup full programado havia sido feito um outro backup full (o backup diferencial grava apenas as informações alteradas após a execução do ultimo backup full), sendo assim estávamos tentando restaurar informações inconsistentes.

 

Um backup full havia sido feito normalmente no domingo e na quarta-feira havia sido feito o outro pelo meu amigo e na quinta quando tentávamos restaurar o backup diferencial este só continha as informações após o backup da quarta más o nosso full era de domingo. Um pouco confuso isso né? Enfim tínhamos um grande problema em nossas mãos.

 

A solução

Depois de muito procurar encontramos em uma fita o backup do tal arquivo, restauramos este, o ultimo backup diferencial e os logs após o ultimo backup incremental. Ufa, perfeito restaurou sem problemas.

 

Conclusão

Fazer o backup dos nosso dados é extremamente importante porém deve ser feito com planejamento, seguindo as regras estabelecidas e nos períodos corretos. De nada adianta ter um backup feito sem horário estabelecido sem um local de armazenamento e sem nenhuma regra. Para tudo que fazemos devemos ter planejamento e para tarefas importantes como essa devemos ter ainda mais cuidado.