Tipos de Backup e Recuperação de Banco de Dados no SQL Server

O procedimento para realizar o backup log também é extremamente simples. Basta que o banco atenda as particularidades mencionadas anteriormente.

1. Para fazermos o backup, temos que selecionar com o botão direito o nome do banco de dados > Tarefas > Fazer Backup
   
2. Será aberta a mesma janela do backup full. Contudo, nesse caso, iremos realizar algumas alterações, ficando dessa forma:
   
3. Em azul – Banco de dados: Neste campo, informamos o nome do banco que será feito o backup.
   Em verde – Tipo de Backup: Neste campo, informamos o tipo de backup que desejamos realizar. Como neste caso iremos realizar o backup log, portanto, iremos selecionar “Log de Transações”
   Em vermelho – Diretório: Neste campo, informamos o local em que queremos armazenar nosso arquivo de backup. Assim como no backup full, iremos armazenar em Program Files\Microsoft SQL Server\MSSQL15.InstanceName\MSSQL\Backup.

IMPORTANTE: Diferente do backup full, a extensão usada para o backup log é a .trn. Assim como exemplo da imagem acima, sublinhado em vermelho.

Dentre os três backups apresentados, o backup diferencial é o que menos é usado. Porém, isso não significa que ele não seja importante e, da mesma forma que os outros, é usado outro cenário. Seu nome já nos dá uma dica de qual é o seu propósito e como ele funciona.

O backup diferencial faz o backup do banco desde o último backup full executado. Isso é chamado de base do diferencial.

Para ficar mais simples de entender, podemos usar a imagem abaixo:

Todo o contorno da linha preta (incluindo as partes em vermelho e verde) – É o nosso banco de dados.

Parte vermelha – É o backup full. Assim como mostrado na imagem abaixo, efetuamos o backup do banco db_sistema no dia 04 de fevereiro de 2022 às 23:57 horas.

Parte verde – É o backup diferencial, que pega a diferença entre o último backup full realizado e o estado recente do banco de dados.

Ou seja, o backup diferencial tende a ser mais rápido, isso porque ele não faz o backup do banco de dados inteiro, somente da diferença.

Então, imagine que vamos rodar o backup diferencial às 10:00 horas do dia 05 de fevereiro de 2022. Ele vai fazer o backup do que foi alterado após às 23:57 horas do dia 04 de fevereiro de 2022 até às 10:00 horas do dia 05 de fevereiro de 2022.

Partindo do pressuposto que o seu banco de dados está com os backups full e log, ou até mesmo o diferencial, em dia, não há motivos para se preocupar exceto um, que pode lhe causar uma imensa dor de cabeça e atrapalhar o fluxo do seu negócio.

Como dito anteriormente, o banco de dados está suscetível a erros ou até mesmo situações em que são inseridos, alterados e/ou apagados determinados dados de forma equivocada. Felizmente, o seu banco está com os backups em dia. Então, fique feliz, pois há salvação e é extremamente possível recuperá-lo antes do erro ou ponto de falha, perdendo a menor quantidade de dados possível.

Nesta parte do artigo, vamos aprender como recuperar os backups do banco de dados, conseguindo reverter alguns desastres e erros.

Primeiro, é importante ressaltar que, uma vez que o banco e seus dados foram comprometidos, o mesmo terá que ser sobrescrito, ou seja, revertido para um estado anterior.

Para os exemplos, iremos utilizar o AdventureWorks2019 que é gratuito e disponibilizado pela Microsoft para fins de testes e aprendizados.  Conseguimos baixar o arquivo .bak no seguinte link: Bancos de dados de exemplo do AdventureWorks – SQL Server | Microsoft Docs

1. Na sua instância SQL Server, clique com o botão direito em Bancos de dados > Restaurar Banco de Dados
   
2. Será aberta a seguinte tela.Note que não há nenhum arquivo de backup escolhido. Para escolher o arquivo, basta selecionarmos os componentes marcados em vermelho, conforme as imagens abaixo:
   
   
3. Nesta tela, temos que ter atenção em alguns pontos:
   • Primeiro: É importante informar no campo “Local do Arquivo de Backup” (linha azul) o diretório em que está armazenado o arquivo .bak do banco de dados que você está tentando restaurar. Sem isso, o SQL não saberá qual arquivo será restaurado e o restore falhará. No meu caso, baixei o arquivo do banco AdventureWorks e coloquei no diretório padrão de backups do SQL, mas o local onde irá armazená-lo fica a seu critério.
   • Segundo: Selecionar o arquivo de backup que deseja restaurar (linha vermelha). Para nosso exemplo, iremos selecionar o bak;
   • Terceiro: Concluído os dois passos anteriores, podemos clicar em “OK” (linha verde) e OK novamente na próxima tela;
     

4. Feito isso, você deve receber a tela da seguinte maneira. Note que ele reconheceu o dispositivo em que estamos pegando o arquivo de backup (C:\Program Files\Microsoft SQL Server\MSSQL15.CARLOSMENDES\MSSQL\Backup\AdventureWorks2019.bak), o nome do banco de dados (AdventureWorks) e a data na qual foi feito o backup (segunda-feira, 15 de junho de 2020 às 20:26:36).
   
5. Caso quisessemos, poderíamos alterar o nome do banco de dados e restaurá-lo com outro nome, mas nesse caso não será necessário.
6. Por fim, basta clicar em “OK” e você deve receber a seguinte mensagem de sucesso, conforme a imagem abaixo:
   
7. Agora, conseguimos ver que o banco está em nossa instância SQL foi recuperado com êxito.
   Obs.: Caso não apareça o banco, basta clicar com o botão direito em Banco de dados > Atualizar (Refresh) e ele deverá aparecer.
   

Como falamos antes, a recuperação de um banco de dados visa, acima de tudo, voltar o banco ao estado antes da falha ou do erro que aconteceu. Acontece que, dependendo do tamanho do banco de dados e de quando foi feito o último backup full, a perda de dados pode ser gigante. Para entender melhor, vamos montar o cenário, aplicando com a prática.

Supondo que meu banco restaurado há pouco, AdventureWorks, seja meu banco de produção, extremamente crítico, com diversas transações e processos em execução. Eu faço o backup full dele diariamente, durante a madrugada, pois o banco é grande e demora para concluir o backup. Então, eu executo o backup full do meu banco de dados às 02:00 horas.

Imagine que este banco está recebendo conexões e processos normalmente. Em um dado momento, preciso que seja criada a tabela “funcionário”. Sendo assim, executo a DDL de criação da tabela e começo a popular a mesma, conforme o exemplo abaixo:

Agora, iremos dropar a tabela criada anteriormente, com o comando DROP TABLE. Note que ao executar o comando select na tabela “funcionário”, recebemos o erro do Database Engine informando que a tabela não existe no banco.

Ou seja, tínhamos criado uma tabela chamada “funcionário” e populamos ela com dados. Mas, após o drop, ela não existe mais. Você pode até estar pensando: “Ok, só precisamos restaurar o backup full do banco de dados”. Contudo, a tabela “funcionario” foi criada após o backup full. Se restaurássemos, não teríamos a tabela de volta.

Por sorte, fomos precavidos e rodamos o backup log após a criação da tabela e, com ele, conseguimos restaurar o banco de dados até o momento em que o drop table ocorreu. Primeiro, temos que ter em mente que, para restaurar um backup log, devemos primeiro restaurar o último backup full que foi executado, e após isso, aplicar os arquivos de log até o momento em que a tabela foi apagada. Então vamos lá!

Vamos restaurar um backup full, da mesma forma que restauramos o banco AdventureWorks2019, mas dessa vez, ao invés de fazermos via tela gráfica, faremos via script. Isso porque nesse caso, como iremos restaurar um log por cima, precisamos nos atentar em alguns pontos e adicionar alguns comandos.

1. Seguindo o passo a passo para recuperar um backup full, antes de clicar em “OK”, vamos clicar em Script > Janela do Editor de Nova Consulta
   
2. Com isso, teremos o seguinte script:
   
   Segue script:
   USE [master]
   ALTER DATABASE [AdventureWorks2019] SET SINGLE_USER WITH ROLLBACK IMMEDIATE /* –> Estamos alterando o banco de dados para usuário único, fazendo com que asconexões abertas com o banco que será restaurado sejam encerradas, e as transações em andamento sejam revertidas; */
   RESTORE DATABASE [AdventureWorks2019] /* –> Comando para restaurar o banco de dados (Informa o banco de dados que vamos restaurar — banco destino); */
   FROM  DISK = N’Backup Path’ /* –> Informa qual é o backup que está sendo resturado; */
   WITH  FILE = 1, /* –>  Informa a partir de qual datafile será realizado o restore (Quando = 1, significa que será usado o datafile primário (primary) — .MDF); */
   NOUNLOAD,
   NORECOVERY, /* –> Permite que mais sequências de backup sejam restauradas; */
   REPLACE, /* –> Significa que o banco de dados será sobrescrevido; */
   STATS = 5 /* –> Porcentagem de progresso que será informada durante o restore (Quando = 5, significa que o SQL mostrará a porcentagem de progresso do restore de 5 em 5); */
   GO
3. Vale lembrar que é extremamente importante colocar a opção Isso porque ela vai permitir que posteriormente, consigamos restaurar o backup log após o backup full.
   1. Como vimos acima, o restore foi executado com sucesso. Sendo assim, o banco de dados que estamos recuperando, AdventureWorks2019, deverá ficar com o status “Restoring” (Restaurando). Dessa forma:
      
   2. Muito bem, agora temos que restaurar o backup log. Para fazermos isso, temos que clicar com o botão direito em Tarefas > Restaurar > Log de Transações
      
      
   3. Com isso, você deverá ver a seguinte tela. Para escolhermos o arquivo de log que vamos restaurar, devemos marcar o checkbox “Do dispositivo:” e clicar no quadrado marcado em vermelho e depois em “Adicionar” como mostra as imagens abaixo:
      

    

4. Assim como na recuperação do backup full, temos que escolher o arquivo que iremos restaurar. Mas dessa vez, iremos escolher o backup log que fizemos anteriormente, logo após criarmos a tabela “funcionario”. Após selecionado clique em “OK” e depois em “OK” novamente.
   
   1. Feito isso, clicaremos em Script > Ação do Script para a Nova Janela de Consulta
      
   2. Assim, o script deverá aparecer em uma nova janela de edição de query:
      
      Note que foi aberto em uma sessão diferente. É importante que você copie e cole o script na mesma sessão em que você rodou o restore do backup full. Desta vez, sem a opção norecovery. Isso porque queríamos resgatar apenas este backup log. Contudo, quando for restaurado mais de um backup log, sempre deverá ter a opção norecovery, deixando apenas o último arquivo que será restaurado sem essa opção. Dessa forma, o Database Engine entende que não há mais sequências de backup para serem restauradas, e que o banco pode enfim entrar em uso.
   3. Por fim, quando executado com sucesso, deverá receber algo como isto:
      
   4. Se você verificar o banco de dados AdventureWorks2019, ele não está mais com o status “Restoring” (Restaurando), estando finalmente online novamente.
      
   5. Agora, chegou o momento de verificarmos se a tabela “funcionario” que havia sido excluída, está de volta, executando o seguinte script:
      
      USE AdventureWorks2019
      GO
      SELECT *FROM FUNCIONARIO
   6. Podemos notar que a tabela está no banco de dados novamente e com os registros que foram inseridos logo após sua criação.
      
      Assim, podemos ver a importância de sempre estar com o backup full e log em dia. Isso porque, quando esses eventos de desastre no banco de dados surgirem, será possível recuperar o que foi perdido de forma mais assertiva e pontual. Mesmo tendo suas particularidades, todos os tipos de backup (full, log e diferencial) possuem o mesmo objetivo e ajudam a garantir a segurança das informações em caso de comprometimento da integridade do banco de dados. Além disso, também vimos que é possível recuperar estes backups, retornando o estado do banco no momento específico antes de algum erro cometido. Por isso, mantenha sempre seu ambiente SQL Server com os backups em dia, para que em caso de falhas ou outros problemas que interfiram no seu banco de dados, a margem de perda de dados seja a menor possível.