Olá, Dataholics! Muitos estudos por aí ? Pensando em agregar um pouco de conhecimento para quem não é da área ou ainda não se aprofundou neste assunto: você sabe o que é um Backup e a importância de realizá-lo com certa frequência? Para entendermos a importância, vamos primeiro entender o que é um Backup. Imagine que você é aquela pessoa moderna que adora tirar fotos da família, dos amigos e dos momentos, mas seus familiares são bem tradicionais e gostam de manter aquele álbum de fotos dentro de uma caixa de sapatos no fundo do armário. Todas as fotos que você tira com eles são impressas e guardadas neste álbum. Por algum motivo, como perder ou quebrar o celular, você fica sem essas fotos e também outras fotos que não mandou para eles. Você tem um Backup das fotos que estão no álbum impresso. Por outro lado, as fotos que você não enviou não têm esse "Backup". Backup nada mais é do que uma cópia dos arquivos em um determinado momento, como uma foto tirada. No SQL Server ou em qualquer outro banco de dados, o Backup contém informações sobre aquele banco de dados, tabelas e registros daquele momento em que o Backup foi efetuado. A importância disso, assim como no exemplo, é ter onde buscar esses dados caso ocorra algum incidente. Alguns desses incidentes podem incluir: - Inserção de dados errados - Exclusão de dados errados - Corrupção no banco de dados - Queda do servidor - Invasão do ambiente e todos os dados criptografados - Entre muitos outros Ao considerar esses riscos, é recomendável ter uma cópia de Backup armazenada externamente, seja em nuvem, em um servidor fisicamente separado ou em um dispositivo de armazenamento externo, como HDs ou SSDs. Com isso em mente, vou falar sobre os 3 tipos de backups mais comuns utilizados no SQL Server: Backup Full: Ele é uma cópia de todo o banco de dados, tabelas e registros da base selecionada para a realização do backup. Você pode estar pensando: "Minha base de dados tem 1TB, não é possível fazer isso todos os dias devido ao tempo de execução e à sobrecarga do ambiente, o que fazer?" A resposta é executar o Backup Diferencial! Backup Diferencial (DIFF): O Backup Diferencial serve para que você possa realizar backups com um menor espaço de tempo, salvando as informações diferenciais, ou seja, todas as informações que o Backup Full não tem. "Ok, entendi, mas não entendi." Para facilitar o entendimento, imagine que cada cor na imagem representa informações diferentes. Note que, logicamente, um Backup Diferencial não pode ser criado sem ter um Backup Full antes. Isso ocorre porque o Diferencial utiliza o Backup Full como base para identificar as informações diferentes. Com isso podemos concluir que o Backup Diferencial normalmente será menor do que o Backup Full, exceto em raras situações. Seguindo o exemplo da rotina conforme a imagem, você me pergunta: "Socorrooo, fiz um Backup Diferencial na segunda-feira às 20:00h e na terça-feira às 19:00h fiz um update errado!!! Vou perder 23 horas de dados?" Talvez. Quase sempre depende, né! rs Existem três tipos de Recovery Model que são os tipos de recuperação configurados para o seu banco de dados. Vou citar os dois mais utilizados. De maneira superficial e para fácil entendimento: Recovery Model Simple: não possui Backup de Log. Recovery Model Full: contém Backup de Log. Backup de Log: Logs de transações são as informações que são inseridas, alteradas ou excluídas do seu banco de dados. O SQL Server grava todos os Logs de transações efetuadas no seu banco de dados. Uma das diferenças entre o Modelo de Recuperação Simples e o Modelo de Recuperação Full é que no Simples todos esses dados de Log são excluídos do "histórico" do SQL Server após serem concluídos, enquanto o modelo de Recovery Model Full armazena essa informação. Uma rotina de Backup SEMPRE se iniciará com um Backup Full, pois é com ele que os primeiros Backups Diferenciais e o primeiro Backup de Log irão procurar. O segundo Backup de Log sempre procurará as informações a partir do primeiro Backup de Log, o terceiro Backup de Log procurará todas as modificações feitas desde o segundo Backup de Log e assim por diante. Já o Backup Diferencial procurará sempre o último Backup Full realizado. "Então, se eu realizar esse Backup de Log, ou seja, realizar o Backup dessas informações inseridas, alteradas ou excluídas, eu consigo restaurar meu banco de dados antes de ter feito o Update errado?" A resposta é sim! Dependendo de como sua rotina de Backup estiver montada, você consegue restaurar uma base de dados até um determinado ponto que você queira. Isso dependerá da recorrência do seu Backup de Log. Vamos para a prática para entender! Fiz uma linha do tempo de acontecimentos, das realizações de Backups e também das atualizações numeradas a seguir: Primeiramente criei o banco de dados BASE_ARTIGO e também uma tabela FRUTAS com 3 colunas: Id_fruta Nome_fruta Cor_fruta Logo após inseri alguns registros e realizei o Backup Full no Domingo as 22:00 horas. Dados do Backup Full armazenados: Já na segunda-feira: 11:00 horas, foi realizado um Insert (Número 1) neste banco de dados: 14:00 horas, realizado o primeiro Backup do Log (Log 1) que contém todos os dados desde o Backup Full: 18:00 horas, foi realizado um Insert (Número 2) neste banco de dados: 20:00 horas, foi realizado o primeiro Backup Diferencial: Na terça-feira: 07:00 horas, houve um Update (Número 3) trocando a cor da fruta para 'Verde' onde o nome da fruta for 'Uva' : 12:00 horas, outro Update foi realizado (Número 4), porém ocorreu que a pessoa foi alterar a cor do Kiwi para marrom, mas passou um campo errado como filtro no where, gerando alterações em todos os registros que tinham a cor verde: Sem perceber, a pessoa deixou inconsistente a base de dados, isso em um cenário real seria muito grave! Mas a Base que está em Recovery Model FULL e utiliza de uma boa estratégia de rotina de backups não tem muito com o que se preocupar. O Backup do Log irá nos ajudar, mas por enquanto não perceberam o erro e foi gerado outro Backup do Log ( Log 2 ). 14:00 horas, foi realizado a rotina padrão do Backup de Log ( Log 2 ): Voltando a Imagem da linha do tempo, note que o Log 2 "pensa: Onde está o Log anterior? " Ele encontra o Log anterior e realiza o Backup dos números 2, 3 e 4. ( Na realidade, os dados depois da execução do Log 1, O SQL é inteligente e já vai salvando os dados de Log, até que seja realizado um próximo Backup de Log, isso pode fazer com que cresça muito seu arquivo de Log caso sua janela de intervalo de um Backup de Log para outro seja muito grande , pois vai acumulando) . 17:00 horas alguém realiza um Insert na tabela FRUTAS com os valores: 'Maça' e 'Vermelha'. 20:00 horas executa o Backup Diferencial 2 : Após isso, o indivíduo que realizou o UPDATE errado percebe e avisa o DBA: "Fiz UPDATE com WHERE errado e alterei linhas que não eram para alterar!" (Pense se isso fosse em uma tabela com milhões de registros...) Graças ao Backup de Log conseguimos retornar o banco de dados para um momento anterior ao que foi atualizado errado, realizando um RESTORE Point in Time onde consigo fazer o banco retornar ao ponto número 3. Porém, perceba que as alterações feitas no número 5 (e em diante se tivesse) são perdidas. Perder alguns dados recentes e relançá-los é melhor do que perder dados de um ou mais dias. Normalmente a frequência de Backup de Log em ambientes principalmente de produção é com um intervalo muito baixo. Já vi ambientes com intervalo de 5 a 10 minutos entre um Backup de Log e outro. Em outro artigo para não ficar muito longo aprofundarei mais a explicação do script de Backups juntamente com o Restore, onde eu faço a recuperação de uma base já existente ou de uma base nova na minha Instância. Muito obrigado por ler até aqui. Quaisquer dúvidas comente aqui e também seria super interessante ter seu feedback! #GODATAHOLICS 💙🚀