12 Erros Comuns ao Fazer Backup de Bancos de Dados

por Alexey Kovyazin, 11 de novembro de 2015

Baixar PDF (Inglês) Este artigo foi inicialmente destinado a desenvolvedores e administradores de SGBD Firebird, mas os contatos com administradores de outros bancos de dados deixaram claro que a maioria dos erros é comum entre eles também e literalmente todos tropeçam quase nas mesmas pedras. Se você puder acrescentar algo a esta lista (mesmo algo específico para um SGBD em particular), entre em contato conosco pelo nosso e-mail [email protected].

1. Excluir a cópia de backup anterior antes que uma nova cópia de backup seja criada

Este erro é mais comum entre iniciantes que não percebem que o objetivo principal de uma cópia de backup de banco de dados não é apenas criar uma cópia do banco, mas tornar o tempo de inatividade de um sistema de informação (do qual o banco de dados é uma parte importante) o mais curto possível.

Como resultado, o sistema fica desprotegido desde o momento em que a cópia de backup mais recente é excluída até o momento em que a nova é criada, porque o banco de dados não tem uma única cópia de backup durante esse período. Como a criação de uma cópia de backup pode levar um bom tempo, é o momento perfeito para a lei de Murphy entrar em ação. Essa abordagem funciona especialmente bem quando combinada com o Problema 7 (veja abaixo).

Recomendações: não exclua a cópia de backup anterior antes que a nova seja criada! (e não faça uma nova cópia de backup em um arquivo existente).

Recomendação para Firebird: Existe uma ferramenta FBDataGuard incluída no HQbird (um pacote de distribuição avançado do Firebird) que exclui a cópia de backup mais antiga do histórico somente depois que uma nova é criada.

2. Sobrescrever um banco de dados existente ao restaurá-lo a partir de uma cópia de backup

Este erro é menos comum, embora os resultados possam ser muito piores. Se a cópia de backup não foi verificada e se revelar corrompida (veja o Problema 6), você não terá nem a cópia anterior do banco de dados nem uma cópia de backup válida.

Uma bagunça assim geralmente acontece numa sexta-feira à noite, quando as coisas ficam agitadas e quando as instruções da gerência ficam meio contraditórias. Um pouco de azar e um fim de semana lânguido na sala de servidores é o que te espera.

O Firebird tem um tipo de proteção contra esse erro - não será possível restaurar um banco de dados a partir de uma cópia de backup com a ajuda do utilitário gbak se a opção padrão -create estiver ativada e se o nome do arquivo especificado apontar para um banco de dados existente. Infelizmente, há uma maneira de contornar essa proteção: a opção -rep ainda permite sobrescrever o arquivo existente.

Recomendação: nunca sobrescreva o arquivo de um banco de dados em funcionamento sem uma diretriz por escrito da sua gerência.

Recomendação para Firebird: Use o FBDataGuard porque ele nunca sobrescreve o arquivo do banco de dados.

3. Usar backup/restauração em uma única etapa sem usar um arquivo de backup intermediário

Fluxos padrão de entrada/saída tornam possível fazer um truque engraçado com muitos SGBDs (incluindo o Firebird): implementar um backup em fluxo contínuo com restauração do banco de dados a partir dele imediatamente. Nenhum arquivo de backup intermediário é criado como resultado. É conveniente para manutenção de rotina e para executar uma operação de restauração de teste (desde que haja outra cópia de backup disponível), mas você não deve usá-lo para backup automático!

Por exemplo, se uma falha grave de disco ocorrer durante esse processo de backup/restauração, o banco de dados inicial pode ser danificado enquanto nenhum novo banco de dados foi criado ainda. É claro que, se você levar em conta o Problema 1 e houver uma cópia do banco de dados da tentativa anterior, apenas os dados criados ou atualizados no banco de dados após a criação dessa cópia serão perdidos.

Recomendações: não use backup/restauração em uma única etapa no modo automático e sempre verifique a disponibilidade de uma cópia suficientemente atualizada no modo manual.

4. Armazenar cópias de backup e o banco de dados no mesmo dispositivo físico

Muitos de vocês podem achar engraçado que o conselho que damos seja meio infantil - o ABC do backup. Certo, isso é verdade, mas o banco de dados e o disco podem acabar sendo armazenados em um mesmo sistema de armazenamento de dados devido à popularidade dos ambientes virtuais. E certamente falhará no momento mais inoportuno. Além disso, ainda há pessoas que acreditam que nada pode acontecer com seus dados se usarem matrizes RAID (versão 1 ou superior :)). Além disso, há pessoas que acreditam que alguns servidores de “marca” são à prova de falhas, mas isso é um caso especial.

Recomendações: não armazene cópias de backup e o banco de dados no mesmo dispositivo, por mais confiável que ele possa parecer.

5. Sem controle sobre a conclusão bem-sucedida do processo de backup

É um erro bastante comum tanto entre administradores quanto entre chefes de departamentos de TI. Se você não verificar os resultados do processo de backup, é melhor nem realizá-lo. Você deve receber notificações sobre a conclusão bem-sucedida do processo de backup por e-mail ou, melhor ainda, também por mensagem de texto. E a ausência dessas notificações é um sinal de problema!

Um leitor atento que chegou a este ponto do nosso artigo (embora ainda seja cedo para dar um prêmio por isso) pode perguntar: ‘Mas o que isso tem a ver com a gerência?’ Aqui está o porquê - o administrador geralmente configura o processo de backup, mas acha chato demais verificar as notificações, especialmente quando elas são armazenadas em uma pasta separada, então nunca é demais solicitar relatórios adicionais sobre o status do processo. É sobre a questão de quem é o culpado quando parece que as cópias de backup existem, mas na verdade não estão lá no momento em que você precisa delas :)

! quando combinado com o Problema 2, não temos nem o banco de dados nem sua cópia de backup.

Recomendações: use ferramentas de automação de backup que possam monitorar processos de backup bem-sucedidos e malsucedidos, notificar usuários sobre problemas e oferecer ferramentas de controle resumido (é especialmente relevante quando você precisa controlar dezenas e centenas de processos de backup em servidores diferentes).

Recomendação para Firebird: o FBDataGuard verifica se o processo de backup foi concluído e envia a notificação correspondente. Para sistemas com muitos bancos de dados, há monitoramento resumido de segundo nível com a ajuda da ferramenta Control Center que permite ver os status de todos os servidores e bancos de dados monitorados em uma única página.

6. Sem validação do backup

O fato de as cópias de backup estarem armazenadas em algum lugar não significa que elas podem ser lidas de lá.

É por isso que você deve verificar regularmente as cópias de backup que cria para garantir que elas não estejam corrompidas ou copiadas para /dev/null.

Recomendação para Firebird: você pode automatizar a validação do backup com a ajuda do FBDataGuard.

7. Sem verificações de integridade do banco de dados ao usar cópias de backup não verificadas

Geralmente, os bancos de dados usam vários tipos de backup - dumps, cópias de backup regulares, etc. Sem entrar em detalhes, podemos destacar duas categorias: verificadas e não verificadas. No caso do Firebird, são gbak e nbackup.

Gbak lê todo o banco de dados no nível de registros para criar um arquivo de backup e cria um banco de dados inserindo registros em um novo banco, verificando assim a cópia de backup (há maneiras de erros entrarem na cópia restaurada, mas isso é outra forma de o administrador de banco de dados bagunçar as coisas relacionada a migração mal organizada) e o próprio banco de dados (se ele puder ser lido do início ao fim, provavelmente não está corrompido).

Nbackup (também conhecido como backup incremental) bloqueia temporariamente o arquivo principal do banco de dados para atualizações (no estado consistente) e permite copiar rapidamente o arquivo do banco de dados (total ou parcialmente/incrementalmente).

No caso de bancos de dados Firebird grandes (maiores que 500 GB), é aconselhável usar o nbackup para não desacelerar as operações do usuário, mas ao mesmo tempo é necessário validar o banco de dados porque as cópias de backup não verificadas que ele cria são cópias de páginas do banco de dados e, se um erro residir no nível de registros (devido a uma falha de RAM) ou no nível lógico, uma cópia de backup não verificada o conterá tanto quanto o banco de dados original.

Para evitar isso, você deve usar validação online para o banco de dados original (validação online com a ajuda do gfix está disponível a partir da versão 2.5.4 do Firebird, enquanto nossa ferramenta FBDataGuard suporta validação online de banco de dados para as versões 1.5-2.5).

Além disso, é aconselhável realizar backup verificado de vez em quando (uma vez por semana, por exemplo) além do backup não verificado.

Recomendação para Firebird: além da verificação de integridade online, o FBDataGuard permite testar o processo de restauração de backup no modo automático.

8. Sem controle do espaço livre para cópias de backup

Na verdade, é um erro clássico: se não houver espaço suficiente, as cópias de backup ocupam todo o espaço livre e o processo termina com um erro. Armazenar cópias de backup no mesmo disco do banco de dados pode levar a uma interrupção na operação do banco de dados, e armazená-las no disco do sistema pode resultar em uma falha do sistema.

Em combinação com o Problema 4, o melhor resultado possível será aquele em que o sistema para de funcionar porque o banco de dados também precisa de espaço livre, mas ele está ocupado pelas cópias de backup. Quanto à combinação com os Problemas 5 e 2, isso nos deixa novamente sem o banco de dados e sem sua cópia de backup.

Recomendações: use ferramentas de backup que prevejam o tamanho do backup e avisem sobre a possível falta de espaço livre.

Recomendação para Firebird: o FBDataGuard controla o tamanho do espaço livre para fins de backup e também o tamanho do espaço livre no disco com os bancos de dados, bem como no disco do sistema.

9. Sem controle sobre o tempo necessário para criar uma cópia de backup

O processo de backup levava 40 minutos literalmente há seis meses e, de repente, já leva três horas - por quê? O tamanho do banco de dados pode ter aumentado ou um disco pode ter saído da sua matriz RAID, resultando em um desempenho de gravação consideravelmente mais lento, e todas as suas cópias de backup podem estar prestes a partir deste mundo. Ou um bom colega seu pode ter executado mais um sistema de backup ao mesmo tempo (aliás, o Firebird permite executar vários processos de backup ao mesmo tempo, embora não esteja muito claro por que alguém precisaria disso). Se você não controlar o tempo necessário para fazer uma cópia de backup, pode não perceber um problema recém-surgido e perder a chance de corrigi-lo antes que ele se torne massivo.

Além disso, se o sistema de backup não monitora os status das tarefas de backup e as executa apenas de acordo com o agendamento, você pode facilmente “sair na frente”, o que significa a situação em que o sistema inicia um novo processo de backup enquanto o anterior ainda não terminou.

Recomendações: use ferramentas que controlem o tempo que o processo de backup leva!

Recomendação para Firebird: o FBDataGuard controla o tempo que o processo de backup leva.

10. Fazer backup do banco de dados enquanto atualizações do sistema operacional estão sendo aplicadas

É um problema muito comum, especialmente em combinação com o Problema 9 e atualizações automáticas do Windows habilitadas (por padrão, as atualizações são aplicadas às 3h da manhã). Isso leva a uma lentidão na melhor das hipóteses, mas se o sistema operacional for reiniciado para aplicar as atualizações, a cópia de backup será danificada. Pelo menos, a boa notícia é que o sistema operacional não é atualizado todos os dias.

Recomendações: agende as atualizações do sistema operacional para quando elas não interferirem no processo de backup.

11. Fazer backup do banco de dados com a ajuda de ferramentas de backup de arquivos ou ferramentas de backup de máquina virtual enquanto o servidor de banco de dados está em execução

Muitos administradores esquecem que qualquer SGBD tem um cache ativo e complexo que contém dados sendo lidos e gravados, enquanto os próprios arquivos do banco de dados são abertos no modo de acesso aleatório. É por isso que é necessário usar tipos especiais de backup em vez de mero backup de arquivos (incluindo apenas copiar arquivos do banco de dados) ou backup de máquina virtual. As ferramentas de backup de arquivos leem o banco de dados sequencialmente e isso pode levar bastante tempo, especialmente no caso de bancos de dados grandes, então é impossível garantir a integridade da cópia de backup criada.

As máquinas virtuais podem usar os mecanismos de snapshots e Changed Block Tracking, mas é necessário sincronizar as cópias de backup criadas para obter uma cópia de backup consistente do banco de dados, pois a cópia de backup ficará inconsistente caso haja operações de escrita ativas com o banco de dados no momento da coleta do conjunto de blocos alterados.

Para aqueles que desejam fazer backup de seus bancos de dados com a ajuda de ferramentas de backup de arquivos ou máquinas virtuais, podemos oferecer dois métodos:

1. desligar completamente os serviços e processos do DBMS para que não haja nada no cache,
2. usar agentes e/ou scripts que alternam o banco de dados para um modo especial que torna seguro copiar o arquivo do banco de dados sequencialmente. Por exemplo, existe um mecanismo chamado VSS writer para bancos de dados MSSQL. Sob solicitação, ele alterna o banco de dados para o modo compatível com snapshot no momento em que um snapshot é feito. Se você usar mecanismos baseados em Changed Block Tracking, você mesmo deve garantir que o banco de dados esteja consistente no momento da sincronização.

Se você não alternar o banco de dados para o modo compatível com backup, a cópia do banco de dados resultante parecerá como se um reset forçado (por exemplo, uma queda de energia) tivesse ocorrido no computador host. Esse nível de confiabilidade é absolutamente insuficiente para a maioria das empresas. Você pode saber mais sobre isso no artigo “Peculiaridades de Trabalhar com Bancos de Dados em Máquinas Virtuais”.

Para o Firebird, é necessário bloquear o arquivo principal do banco de dados com a ajuda do nbackup antes do processo de backup começar e desbloqueá-lo após o processo terminar. Para outros DBMSs existem ferramentas semelhantes para ativar/desativar os modos correspondentes.

Alguns administradores de banco de dados estão certos de que podem fazer backup de seus bancos de dados com segurança usando ferramentas padrão de backup de arquivos se o DBMS tiver um log de transações, porque apenas esse log será corrompido, no máximo. É uma concepção errônea perigosa que os desenvolvedores de DBMS não suportam.

As raízes dessa concepção errônea são claras: a publicidade agressiva dos desenvolvedores de máquinas virtuais e ferramentas de backup geralmente não menciona que bancos de dados, assim como outros arquivos intensivamente atualizados, exigem configuração avançada. Não acredite no hype - nem todos os iogurtes têm os mesmos benefícios.

Recomendações: não use ferramentas de backup de arquivos e VM sem as ferramentas de automação correspondentes para bancos de dados.

Recomendação para Firebird: use o FBDataGuard (do pacote de distribuição HQbird), ele fornece integração com ferramentas de backup compatíveis com VSS.

12. Substituindo backup por replicação

Backup de dados e replicação de dados são usados para aumentar a confiabilidade e prevenir a perda de dados, mas ainda assim são bastante diferentes.

Todos amam a replicação pela capacidade de sincronizar dados em outro servidor com o mínimo de atraso, mas o backup também tem vantagens indiscutíveis. Por exemplo, em caso de exclusão acidental (ou intencional) de dados, a replicação enviará rapidamente e imperturbavelmente as alterações para a réplica, enquanto o backup (especialmente com cópias em mídia somente leitura) é imune a tais operações. É preciso um certo esforço para configurar tanto a replicação quanto o backup corretamente, e ainda assim a possibilidade de erros existe de qualquer forma.

Recomendações: Se você tiver replicação configurada, não negligencie as cópias de backup, use ambas.

Recomendação para Firebird: use o pacote de distribuição HQbird Enterprise, ele inclui ferramentas de backup e replicação.

Resumo

Não é tão fácil configurar o backup para o seu DBMS favorito, então geralmente administradores de banco de dados de organizações que valorizam seus dados usam ferramentas profissionais de backup que permitem levar em consideração os problemas mencionados acima e prevenir os problemas.

Para Firebird (perdoe a propaganda) existe um pacote chamado HQbird que inclui o FBDataGuard.

Além disso, nossa empresa fornece suporte completo de backup e manutenção para Firebird e outros bancos de dados, esta é uma boa escolha para aqueles que não conhecem todos os detalhes técnicos de backups.

E, é claro, continue cultivando sua paranoia de administrador, por exemplo, levante-se e verifique suas cópias de backup agora mesmo :)

Contatos

Sinta-se à vontade para fazer qualquer pergunta: [email protected]

Quer receber notícias e artigos sobre Firebird? Junte-se a nós no Telegram https://t.me/firebirdsql