Após a conclusão temporária das postagens com assunto segurança, vamos iniciar um dos pontos mais importantes na área de dados: Backup e Restore. Com essa série de postagens, pretendo trazer todo o conteúdo possível a respeito da persistência de dados e como restaurar um banco.

Conceituando

Backups em banco de dados são procedimentos que permitem persistir todas as transações e operações realizadas dentro de um banco. As técnicas utilizadas para backup e restore reúnem um conjunto de habilidades e ferramentas tecnológicas que permitem persistir os dados mesmo em casos de falhas graves ou até mesmo fatais.

É de suma importância para um DBA que o saiba elaborar um plano de backup e disaster recovery evitando perda de dados e o comprometimento do negócio.

Mesmo com todo planejamento e cuidado ao elaborar um plano de backup, este em alguns casos, pode não ser suficiente, e com isso, podemos adotar as ferramentas de alta disponibilidade como: Availability Group, Log Shipping e Database Mirror.

E o que pode causar perda de dados de uma organização? No geral, temos alguns fatores que causam isso:

  • Falha de Hardware
  • Corrupção de Banco
  • Atividades maliciosas

Para iniciar no assunto de backup, precisamos entender como funciona o ‘recovery model’ do SQL Server pois, é com ele que vamos basear as políticas de backup e restore dos bancos na instância.

Recovery Model

É uma configuração que um banco hospedado, dentro de uma instância do SQL Server possui e, irá determinar, como iremos planejar o backup do banco em questão, quais serão as maneiras de estabelecer um restore no banco e a frequência e os tipos de backup que serão utilizados.

O TempDB utiliza o modo simple de recovery, uma vez que por sua natureza, ele não precisa armazenar log nem transações.

Não é aconselhável ficar alternando o modo de recuperação do banco, uma vez que isso pode desconfigurar toda a política de backup. Por exemplo:  Se um banco está em recovery full, com a política de backup estabelecida e o backup de log configurado e, em algum momento ocorre mudança do modo de recuperação, o backup de log é desconfigurado e só retornará ao normal, após novo backup full do banco em questão.

Somente alterar o modo de recuperação se de fato for necessário e abaixo, cada um dos modelos e suas características.

Full Recovery

É a configuração que como o nome sugere, armazena todas as transações ocorridas no banco dentro do log file, persistindo os dados até que ocorra um backup de log e ‘limpe’ o log do banco.

Todas as transações (insert, update e delete) ficam no log até que que sejam escritas nas data pages do banco e persistidas no disco. As transações no log file são limpas quando ocorre uma operação de backup ou se for executado um comando de checkpoint.

O DBA precisa ficar atento em bancos com recovery full, pois como o log tem tendência de crescimento infinito, este pode acabar causando problemas de espaço tanto em log file quanto em disco. Muitas vezes, a política de backup do log não é suficiente para que o log seja limpo a tempo, é preciso atenção.

Se o arquivo de log chegar ao seu tamanho máximo e o autogrowth não estiver configurado, seu banco irá parar até que o arquivo de log seja limpo.

NOTA: banco de dados em ambiente de produção deve sempre ser configurado como o modo Recovery Full. Do contrário, a perda de dados é iminente.

A imagem abaixo, mostra uma simulação de log full:

Bulk-Logged

O bulk-logged é um modo de recuperação de banco que é muito similar ao full, com uma pequena diferença: ELE NÃO GRAVA operações de bulk insert, select into, BCP, Create Index e outras operações volumosas no banco de dados. 

Se nenhuma operação volumosa de dados como citado acima estiver ocorrendo, ele se comporta como um modo de recovery full. Isso garante maior agilidade nessas operações, porém, se houver qualquer falha e um restore for necessário, essas operações de bulk deverão ser recriadas.

O bulk log permite recovery point-in-time, porém ele não irá recuperar essas operações volumosas. Terão de ser refeitas.

O bulk logged também pode ser conhecido como o log mínimo

Este modelo pode ser usado quando uma organização possui dados críticos porém, não querem registrar operações de bulk no log file.

Abaixo, vou deixar um link do blog do Fabiano Amorim, onde ele aborda esse assunto e explica da melhor forma possível.

SIMPLE

Vamos começar falando do recovery simple, que é um modo que não permite armazenamento do log para backup e por isso, não é possível o restore point-in-time

O recovery simple permite um rápido restore do banco em casos de falhas ou desastres graves e até mesmo, executar um attach de um banco em outro servidor

O recovery simple configura o banco para sempre realizar um recycle do transaction log. Como assim?

Todas as transações são escritas no log, antes de serem escritas em disco. Quando o Lazy writer passa essas transações do log para as data page e consequentemente, para o disco, aquele espaço que foi dedicado para a transação que acabou de ir para o disco é limpo e utilizado por outra transação

O recovery simple não é feito para ambientes que precisam manter todas as transações em log até que elas sejam devidamente persistidas no disco.

Visto isso, podemos perceber que no recovery simple, não há possibilidade do restore ‘point-in-time’ nesse modelo de configuração.

Em recovery simple, somente backup full e differential são permitidos.

Assim, terminamos o primeiro post sobre backup, fazendo uma introdução dessa importante operação e dos modos de recuperação que o SGBD da Microsoft possui. No próximo post veremos como deve-se basear uma estratégia de backup e sua importância.

Até breve! Saúde!