Evolução do backup de banco de dados

A principal razão para quedas de cabelos e noites mal dormidas de DBAs e System Engineers, quando o assunto é banco de dados, é com certeza o backup. Dependendo de como é feito, o backup pode gerar muita dor de cabeça mesmo quando está funcionando bem. E custar alguns empregos se não funcionar (e claro que as pessoas só descobrem isto quando precisam restaurar alguma coisa).

Reação de DBA quando perguntada sobre o backup

Reação de DBA quando perguntada sobre o backup

Os principais problemas (e RISCOS) relacionados aos métodos de backup de bancos de dados atualmente são:

  • Janela de backup: a execução de backup precisa começar e terminar dentro de um certo período de tempo. Porém, dependendo da carga no banco de dados, velocidade do storage, rede, da forma como os dados são jogados para fita ou área de armazenamento de backup, etc., um job de backup pode acabar levando tanto tempo que acaba sendo executado em horários em que o sistema está em produção, ou seja, acaba afetando a performance dos servidores e sistemas que utilizam o banco. Nos piores casos pode até chegar a mais de 24 horas, inviabilizando a execução de backups diários e tornando o risco de perder dados críticos seu companheiro de trabalho permanente.
  • Tempo para recuperação: Shit happens, e quando o pior acontece você precisa rezar para aquela fita com o último backup full esteja funcionando direitinho. Só que em alguns casos, cada minuto em que o sistema fica fora do ar, é dinheiro que está escoando pelo ralo, são clientes perdidos, é credibilidade descarga abaixo. E restaurar backups de fita sempre vão levar muitos minutos, às vezes horas. Mesmo que o cliente possa fazer restaurações demoradas sem perder dinheiro, esse é o tipo de tarefa capaz de gerar úlceras de preocupação nos donos dos dados e no pobre do operador de backup (que usa o tempo de restore para enviar currículos caso a tarefa não seja bem sucedida).
  • Confiabilidade: Mesmo que tenham melhorado muito, backups em fita, que ainda são a principal forma de armazenar backups, não são confiáveis o suficiente. Pelo menos não o suficiente para que um DBA não se apavore caso precise da fita. E como um restore normalmente leva muito tempo e pode precisar de várias fitas, você pode demorar muito tempo para descobrir que está ferrado.
  • Ponto de recuperação: O quanto de seus dados você pode perder? Óbvio que a maioria das pessoas vai responder que não pode perder nada, mas isso não é uma expectativa realista. Em caso de um problema com seu banco de dados (como um ataque de rinocerontes em seu data center), alguns dados, os dados mais recentes, você vai perder. Ou eles acabam não indo para o backup por serem extremamente recentes, ou não houve tempo para replicá-los no banco de dados espelho. A frequência de seus backups e a forma como você planeja seu DR (disaster recovery) podem definir o quanto você vai perder. O problema é que normalmente é simplesmente inviável aumentar a frequência dessas operações.

Isso ainda é verdade tanto para bancos de dados mais “maduros”, como o Oracle, quanto para bancos que estão amadurecendo, como o SQL Server da Microsoft. Isso sem falar em MySQL, Sybase, DB2, PostgreSQL e outros mais obscuros. Realizar backups com todos estes problemas já é prática a tanto tempo, que a maioria das pessoas nem cogita outras possibilidades. É a operação padrão, ao projetar um sistema com um banco de dados, a equipe de TI automaticamente se prepara para montar todo esse esquema.

Mas graças a Santo Isidoro, hoje existem maneiras muito melhores para acabar com esses problemas, para transformar o backup em uma brisa ao invés de um inferno. O grande problema é que estas formas mais evoluídas  não são muito conhecidas, mesmo por DBAs e administradores de storage. Mas para entender porque isso representa uma grande evolução na forma de se fazer backup, precisamos fazer uma rápida revisão sobre os métodos ultrapassados.

  • Pré-história: A forma mais primordial consistia em desligar o banco de dados, realizar o backup e depois colocar o banco no ar novamente. Porém muitos sistemas não podem ser simplesmente desligados todo dia por várias horas (pelo menos é o que os pacientes de hospitais informatizados preferem acreditar). Outra forma é um dump lógico dos dados, extrair os dados do banco para um arquivo que pode ser importado caso fosse necessário restaurar os dados. Isto gera dados com um tamanho que pode ser bem maior que o banco de dados original, problemas de formatos na recuperação e impacto de performance. Ainda são formas utilizadas para bancos menores e menos importantes.
Métodos antigos de backup de BDs

Métodos antigos de backup de BDs

  • Atual mas ultrapassado: Hoje existe uma proliferação de softwares para backup, com integração com storage e dispositivos de fita, com automatização do processo de backup, possibilidade de realizar backups incrementais para diminuir as janelas de backup, luzinhas piscando para todos os lados, etc.. Os grandes problemas são os custos dessas soluções, a fauna bastante diversificada de software que precisa ser instalada nos clientes para integrar tudo, necessidade de técnicos que praticamente tem PhD em backup, além de não resolver muito bem as 4 grandes questões já citadas: janela de backup, tempo para recuperação, confiabilidade e ponto de recuperação. Obviamente muito melhor que os métodos pré-históricos, mas ainda geradores de dor de cabeça.
Métodos atualmente mais usados

Métodos atualmente mais usados

O futuro!

Como o backup deveria ser

Como o backup deveria ser

Hoje, com a ajuda de hardware altamente integrado com software, é possível realizar backups de bancos de dados e superar os 4 cavaleiros do apocalipse do backup (também conhecidos como os 4 problemas anteriormente citados). Vou falar mais especificamente do storage da NetApp, mas existem alternativas. Como não conheço bem as alternativas, não posso me pronunciar sobre a qualidade dessas soluções.

Storage NetApp família FAS3100

Storage NetApp família FAS3100

Basicamente a solução de seus piores pesadelos envolve armazenar seu banco de dados em uma dessas máquinas. Além delas terem uma performance muito boa para bancos de dados ( e estou tomando o Oracle como referência), elas já vêm de fábrica com alguns truques muito espertos para facilitar o backup (aliás, não só de bancos de dados). Não vou entrar em detalhes de quais são os grandes truques para que isto funcione desta forma (talvez em posts futuros), mas já aviso aos que não conhecem NetApp tudo o que eu disser vai parecer um exagero, o tipo de mentira que o pessoal de marketing gosta de contar, mas asseguro que é tudo de verdade e que muitos clientes (incluindo a própria Oracle) utilizam este tipo de solução.  Ok, vamos aos fatos que vão te fazer parar de sofrer com a menção da palavra “backup”.

  • Janela de backup: Imagine conseguir realizar backups full de seu banco de dados em menos de 2 minutos, mesmo que ele tenha TeraBytes de dados. Imagine realizar diversos backups full ao longo do dia. E imagine que isso não envolve copias brutas de todos os dados e tenha um impacto imperceptível no banco de dados e no storage. Tudo isso é real e possível! As palavras chaves para este truque são NetApp e Snapshot!
  • Tempo para recuperação: Da mesma forma que o backup é feito em um piscar de olhos, a recuperação também é muito rápida. Você nunca mais vai precisar passar a noite inteira rezando um terço do lado de seu servidor pedindo para que a recuperação de seu banco de dados corrompido funcione. A recuperação é tão rápida que você só tem tempo para uma “Ave Maria”.
  • Confiabilidade: O storage possui diversos mecanismos de hardware e software para garantir a integridade dos dados: RAID-DP, checagem e realocação de bad blocks, memória NVRAM com bateria, Snapshots, cluster ativo-ativo, replicação para outro storage. Além disso, quando se fala em Oracle, o NetApp é o storage mais barato que implementa o Oracle HARD.
  • Ponto de recuperação: Como os backups podem ser realizados com maior frequência, a probabilidade de perder dados em caso de algum problema no banco é bastante diminuída.
  • Hoje o NetApp possui softwares para integração com Microsoft SQL Server e Oracle (sem falar em Exchange, SAP e VMware). Mesmo assim, não é coisa do outro mundo integrá-lo com um MySQL ou outro banco por exemplo. Para ver o SnapManager para Oracle em funcionamento, assista o seguinte vídeo feito pelo Neto da NetApp.

    5 Respostas para “Evolução do backup de banco de dados

    1. Faltou uma conclusão no post, não acha?
      Eu sei, eu sei, de certa forma você abordou tudo, mas é meio que tradição, aquele formato introdução – desenvolvimento – conclusão.

    2. O engraçado é que eu falo sobre os snapshots em empresas que usam storage tradicional e às vezes me dizem que HP, IBM, EMC já têm essa funcionalidade e que, portanto, não há nada de novo no NetApp.
      No entanto, TODOS os usuários de NetApp que conheço usam e abusam dos snapshots, o que não acontece quando o storage em questão é de outro fabricante.
      IBM, HP, EMC têm snapshot? Têm, mas por que será que ninguém usa?

    3. Hi Elcio,

      This is neto from Brazil

      How are you?

      Parabens pelo post. Com certeza, irei adiciona-lo aos meus favoritos.

      Parabens novamente

      All the best,

      neto
      NetApp – I love this company!

    4. quem faz o backups no bando de dados o sgbd ou o programador ?

      • Existem várias ferramentas prontas para isso, que já se integram com o SGBD e o storage, portanto não existe a necessidade do programador fazê-lo. Mas um programador poderia criar a rotina de backup se precisar.

    Deixe uma resposta

    Preencha os seus dados abaixo ou clique em um ícone para log in:

    Logotipo do WordPress.com

    Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

    Imagem do Twitter

    Você está comentando utilizando sua conta Twitter. Sair / Alterar )

    Foto do Facebook

    Você está comentando utilizando sua conta Facebook. Sair / Alterar )

    Foto do Google+

    Você está comentando utilizando sua conta Google+. Sair / Alterar )

    Conectando a %s