Projetando uma rotina de backup

Projetando uma rotina de backup

Olá amigos!

Neste meu segundo post aqui no blog gostaria de falar um pouco mais sobre a questão de “backup e recover”, não que eu seja uma pessoa repetitiva, mais acredito que este tipo de assunto é o que mais atormenta a vida de um DBA no dia a dia.

Antes de entrarmos no assunto gostaria de agradecer a todos aqueles que acessaram o blog, espero sinceramente estar levando informações úteis a todos vocês.

Mas voltando ao assunto, muitas vezes quando você pergunta para alguém qual é o conceito de backup seja de um banco de dados ou de qualquer outro tipo de informação, a resposta na maioria das vezes é algo parecido como “Ahh… É uma cópia que eu faço e deixo guardada, para repor em caso de problemas”. Pela resposta já podemos prever que se acontecer algum problema, muito provavelmente o backup não será a solução, pois o conceito de backup vai muito além da “maldita” frase acima.

Especificamente no caso de banco de dados, a palavra backup representa muito mais do que “essa tal cópia que você tem que deixar guardada”. Representa todo um conceito de um “ambiente” que deve ser montado não pensando somente na guarda das informações, mais também em estratégias de recuperação e também na montagem de um cenário onde se possa tentar prever o máximo possível de falhas que venham ocorrer e estar sempre preparado para ter a solução dos mais variados tipos de problemas, vejamos alguns itens que nos auxiliam neste caso:

1 – Proteger o banco de dados dos mais diversos tipos de falhas: Monte um ambiente sempre tentando proteger o seu banco de dados das mais diversas falhas que possam ocorrer, dentre estas falhas podemos citar algumas como: falha de instrução, falha de processo de usuário, falha de rede, falha de instancia e falha de mídia. Estes são os tipos mais comuns de falhas que podem ocorrer então pense muito bem nestes itens, pois para cada um deles você deve ter um plano de recuperação dos dados a qualquer tempo, além de ter a infra-estrutura de seu servidor de banco de dados muito bem projetada para se proteger destas falhas.

2 – Aumentar o MTBF (Mean-Time-Between-Failures, Tempo Médio entre Falhas): Esse item é muito importante, pois na verdade ele é um indicador da sua competência, pois quanto mais falhas ocorrerem e essas falhas forem direcionadas ao banco de dados, você como o DBA sempre será apontado como o responsável. Então diminuir o tempo médio entre falhas é muito importante para o bom andamento das aplicações e também da sua imagem como responsável pelos bancos de dados, repare que o MTBF está diretamente ligado com a questão da proteção do banco de dados contra os mais diversos tipos de falhas, ou seja, se o item anterior for bem elaborado teremos ótimos resultados em relação ao MTBF.

3 – Diminuir o MTTR (Mean-Time-To-Recover, Tempo Médio para Recuperação): Outro indicador da sua competência. Sempre que houver algum problema que venha provocar a paralisação do seu banco de dados, ou a indisponibilidade parcial dele, você deve ter uma estratégia para recuperação rápida e eficiente (não eficaz), pois o MTTR também mede suas competências como DBA. Mais uma vez é um item diretamente ligado com o item numero um, para entender é só raciocinar friamente: “Se meu banco de dados estiver bem projetado contra falhas, meu MTBF será alto e em contrapartida o meu MTTR será baixo”.

4 – Minimizar a perda de dados: Sabemos que é praticamente impossível estar 100% protegido contra todos os tipos de falhas que possam ocorrer dentro de um banco de dados, porém quando elas acontecem precisamos ter medidas que sempre minimize a perda de dados, pois nos dias de hoje sabemos que a informação vale muito, e quando acontecer alguma falha e houver perda de dados a empresa poderá ter prejuízos e prejuízos muito altos que talvez possam custar milhões e milhões (além do seu emprego é claro).

Para poder realizar a preparação de seu ambiente, é preciso como em qualquer outro tipo de projeto que antes de qualquer coisa você faça uma profunda analise para o levantamento de riscos e requisitos, este levantamento é muito importante para que seu ambiente esteja bem preparado abaixo podemos verificar alguns itens relevantes neste sentido.

a) Requisitos empresariais:

Tempo médio para recuperação (aqui está o MTTR novamente), neste caso é preciso analisar por quanto tempo o banco de dados da empresa pode ficar indisponível (se é que pode), neste requisito você deve sempre ter uma ótima e rápida estratégia para recuperação do banco de dados.

Tempo médio entre falhas (novamente o MTBF), o banco de dados nunca deve apresentar falhas contínuas, procure modelar seu ambiente para que se seu banco de dados parar, que ele nunca pare duas vezes pelo mesmo motivo, pois isso pega muito mal.

Finalizando os requisitos empresariais, podemos ainda falar do “Processo Evolutivo” que na verdade é um mix de MTBF e MTTR que resumindo fica mais ou menos assim. “Com o passar do tempo seu banco de dados deve apresentar cada vez menos problemas (lembre-se de que o ideal é não ter problemas) e sempre que apresentar algum você deve solucioná-lo sempre cada vez mais rápido”.

b) Requisitos operacionais:

Testando e validando backups: Projetar uma rotina de backup, não apenas fazer uma analise das necessidades da empresa programar o backup e pronto! É muito importante que periodicamente o seu backup seja testado, não quero dizer testar se o backup está sendo executado corretamente isso NUNCA pode falhar, na verdade você testar se o backup que é executado sempre está apto para ser restaurado caso seja preciso.

c) Considerações técnicas:

Nas considerações técnicas, podemos incluir vários itens como:

Recursos: hardware, software, mão de obra e tempo.
Cópias físicas de imagens dos arquivos do sistema operacional.
Cópias lógicas dos objetos do banco de dados.
Volume de transações, que afeta a freqüência de backups desejados.

d) Questões relativas à Recuperação após Acidentes:

Neste item fugimos um pouco do aspecto técnico da coisa, mais se trata de uma questão muito importante, pois caso algo aconteça a empresa deve estar preparada para as mais criticas situações como:

• Terremoto inundação ou incêndio.
• Perda total de equipamento
• Defeito de hardware ou software de armazenamento
• Perda de funcionários importantes (como por exemplo, um DBA)

Estas são questões importantes e precisam ser levadas em conta quando falamos de uma estratégia de backup, pois como falamos no inicio o conceito de backup vai muito além do que se imagina. Backup não é só “uma cópia que fazemos periodicamente e guardamos para reposição em caso de problemas”.

Bom pessoal esse post foi um pouco extenso, mais acredito que deva ser útil para refletirmos um pouco sobre o assunto.

Forte abraço e até a próxima!