Depois de entendermos sobre os modelos de recuperação e como eles impactam nas operações de backup, vamos neste post, entender como podemos montar nossa estratégia de backup para evitar perda de dados e interrupções nas operações de uma empresa

Base para estratégia de backup

Desenvolver uma estratégia de backup é ter os riscos de perda de dados importantes reduzidos ao máximo. Vale ressaltar, que o DBA, não pode assumir por conta própria o desenvolvimento de uma estratégia de backup sem antes, entender o negócio e sua criticidade.

O primeiro passo para uma estratégia de backup é entender o quanto uma organização está disposta a perder de dados e o quão rápida a instância precisa estar recuperada e online novamente.

Entender a predisposição das empresas a ‘perda de dados’ irá impactar na política de backup e restore, além de esclarecer, como iremos programar nosso backup de log.

Abaixo, segue um breve check list para um documento de estratégia de persistência de dados: 

  • Os diferentes tipos de backup que irão ocorrer; (Full, Differential, Log);
  • A frequência dos backups

Como boa prática para uma estratégia de backup satisfatória, o DBA ou responsável, deve estabelecer sua política de backup com base em três métricas que são recomendadas para este tipo de operação. Abaixo, estão elas:

  • Recovery time objective (RTO) – tempo máximo de downtime que um banco pode ter;
  • Recovery point objective (RPO) – quantidade máxima aceitável de perda de dados, geralmente em minutos;
  • Recovery level objective – granularidade dos dados que precisam ser restaurados (instância, grupo de DB, DB, grupo de tabelas)

Geralmente, consideramos as duas primeiras métricas RPO e RTO para a criação da rotina de backup. O recovery level é mais utilizado em situações de lição aprendida e relato da solução aplicada.

Tendo essas três métricas, o DBA está apto a elaborar um plano condizente com as necessidades do negócio da empresa.

TIPOS DE OPERAÇÕES DE BACKUP

Há três modos de realizar backup de um banco dentro do SQL Server, são eles:

  • Full – captura e guarda todas as transações que ocorreram no banco. Serve de base para o backup differential e de log;
  • Differential – armazena todas as mudanças que ocorreram no banco desde o último backup full;
  • Incremental ou Log Backup – é o backup do transaction log do banco de dados. Escreve todas as transações que estão no log em disco e ao final, ‘limpa’ o arquivo de log reutilizando o espaço;
  • File ou File Group – é um backup mais específico para os data files do banco ou um filegroup específico. Muito usado em bancos de grande porte onde um processo de backup é mais custoso;
  • Partial – simula o backup full, porém, exclui os filegroup read_only 

E o que devemos analisar para criar um bom plano de backup? Abaixo, alguns fatores:

  • Tamanho do banco de dados;
  • Estrutura dos DB files: bancos com o MDF muito grandes, são mais custosos para realizar backup. Considere criar múltiplos   NDF’s;
  • Velocidade de rede, disco, local que os dados estão armazenados. Fatores de hardware podem impactar a métrica de R.T.O;
  • O quanto um processo de backup está ‘pesando’ no sistema. Quanto de processamento ele está consumindo;
  • Qual o volume de operações que aquele ambiente realiza, do tipo: insert, update, delete;
  • O quanto de compressão aquele banco suporta;
  • Se o ambiente em questão precisa de point-in-time recovery;
  • Como o Transaction log é gerenciado;
  • Modo de recuperação e se é preciso que esteja em recovery full;
  • Qual menor período de movimento que o banco possui?;
  • Qual o impacto que as mudanças causam no banco?;
    • grande – considerar um partial backup.
  • Estimar o tamanho aproximado do full backup para considerar o tamanho em disco. Usar a SP_spaceused (deve ser executada no banco que se deseja avaliar);
  • Tipo de modificação (insert, update, delete) – dependendo do tipo e quantidade de modificações, elas podem influenciar no log e no backup diferencial. Se for um ambiente de muitos inserts, pode ser melhor um backup de log com maior frequência.

PARTICULARIDADES SOBRE AMBIENTES SIMPLE E FULL RECOVERY MODEL

Simple – realizar backup diferencial entre os backups full. Como não há backup de log nesse modo de recuperação, todas as mudanças feitas entre os backups full, serão armazenadas nos backups diferenciais

Full – programar o backup de log com uma certa frequência, além de embutir entre eles backups diferenciais, para agilizar eventuais operações de recovery/restore do banco;

NOTA: Se houver apenas um backup full na programação de backup e o restante for backup de log, o restore desse banco irá demorar um tempo considerado, principalmente se formos considerar a frequência do backup de log e o dia que o banco apresentou parada

Uma questão a ser considerada em todo ambiente, quando se trata de estabelecer uma política de backup, é o ambiente de produção, avaliando com cuidado a disponibilidade, proteção e recuperação do(s) banco(s) deste ambiente. A maior recomendação para bancos importantes após o backup é testar o restore em outro ambiente para validar se as operações estão de acordo com o planejado.

E assim, fechamos mais um post sobre backup, desta vez, dando uma luz sobre como estabelecer uma política de backup para o seu ambiente, baseado nas suas particularidades e tamanho banco.

Para o próximo post, vamos ver na prática como criar arquivos de backup para os bancos de dados e seus log file.

Vejo vocês em breve, fiquem bem e saúde!

Publicidade