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 do SGBD Firebird, mas o contato com administradores de outros bancos de dados deixou claro que a maioria dos erros é comum entre eles também e literalmente todo mundo tropeça nas mesmas pedras. Se você puder acrescentar algo a esta lista (mesmo algo específico de um determinado SGBD), entre em contato conosco pelo nosso e-mail [email protected].

1. Excluir a cópia de backup anterior antes de criar uma nova cópia de backup

Este erro é mais comum entre iniciantes que não percebem que o principal objetivo de uma cópia de backup do banco de dados não é apenas criar uma cópia do banco de dados, 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 permanece desprotegido desde o momento em que a última cópia de backup é excluída até o momento em que a nova é criada, porque o banco de dados não possui 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 crie 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 após a criação de uma nova.

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 tiver sido verificada e estiver 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 confusão dessas geralmente acontece em uma sexta-feira à noite, quando as coisas ficam agitadas e quando as orientações da gerência ficam meio contraditórias. Um pouco de azar e um fim de semana prolongado na sala do servidor está garantido para você.

O Firebird tem uma espécie 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 o auxílio do utilitário gbak se sua opção padrão -create estiver ativada e se o nome de 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 diretiva 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

Os fluxos padrão de entrada/saída possibilitam fazer um truque engraçado com muitos SGBDs (incluindo o Firebird): implementar um backup em streaming com a restauração do banco de dados a partir dele ao mesmo tempo. Nenhum arquivo de backup intermediário é criado como resultado. Isso é 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 ocorrer uma falha grave de disco durante esse processo de backup/restauração, o banco de dados inicial pode ser danificado enquanto nenhum novo banco de dados ainda foi criado. É 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. É 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 arrays RAID (versão 1 ou superior :)). Além disso, há pessoas que acreditam que alguns servidores “de marca” são à prova de falhas, mas esse é 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. Nenhum controle sobre a conclusão bem-sucedida do processo de backup

É um erro bastante comum tanto entre administradores quanto entre os chefes de departamentos de TI. Se você não verifica os resultados do processo de backup, é como se nem o tivesse realizado. Você deve receber notificações sobre o processo de backup concluído com sucesso por e-mail ou, melhor ainda, também por mensagem de texto. E a ausência de tais notificações é sinal de um 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?’ Aí vai - o administrador geralmente configura o processo de backup, mas acha entediante 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. É a respeito da questão de quem é o culpado quando parece que as cópias de backup estavam lá, mas na verdade não estão no momento em que você precisa delas :)

! uma vez 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 os usuários sobre problemas e oferecer ferramentas de controle resumido (isso é 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á um monitoramento resumido de segundo nível com o auxílio da ferramenta Control Center, que permite ver os status de todos os servidores e bancos de dados monitorados em uma única página.

6. Nenhuma validação de backup

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

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

Recomendação para Firebird: você pode automatizar a validação de backup com o auxílio do FBDataGuard.

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

Normalmente, 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.

O 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 de dados, verificando assim a cópia de backup (há maneiras de erros se infiltrarem na cópia restaurada, mas essa é outra forma de o administrador do banco de dados estragar as coisas relacionadas a uma 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).

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

No caso de grandes bancos de dados Firebird (maiores que 500 GB), é aconselhável usar o nbackup para não desacelerar as operações dos usuários, 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á também, assim como o banco de dados original.

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

Além disso, é aconselhável realizar um 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. Nenhum controle sobre o 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 em um disco junto com o 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. Nenhum controle sobre o tempo necessário para criar uma cópia de backup

O processo de backup levava 40 minutos literalmente há meio ano e então 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 do seu array RAID, resultando em 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 (a propósito, 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 controla o tempo necessário para fazer uma cópia de backup, pode passar despercebido por um problema recém-surgido e perder a chance de corrigi-lo antes que 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 “se precipitar”, 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 com as atualizações automáticas do Windows habilitadas (por padrão, as atualizações são aplicadas às 3 da manhã). Isso leva a uma desaceleraçã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 o auxílio de ferramentas de backup de arquivos ou de backup de máquina virtual enquanto o servidor de banco de dados está em execução

Muitos administradores esquecem que qualquer SGBD possui 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 do mero backup de arquivos (incluindo apenas copiar os arquivos do banco de dados) ou do backup de máquina virtual. As ferramentas de backup de arquivos leem o banco de dados sequencialmente e isso pode levar um bom tempo, especialmente no caso de grandes bancos de dados, de modo que é impossível garantir a integridade da cópia de backup criada.

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 em caso de quaisquer operações de escrita ativas com o banco de dados no momento da coleta dos blocos alterados.

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

1. desligar completamente os serviços e processos do SGBD para que não haja nada no cache,
2. usar agentes e/ou scripts que coloquem o banco de dados em um modo especial que torne seguro copiar o arquivo do banco de dados sequencialmente. Por exemplo, existe um mecanismo chamado VSS writer para bancos de dados MSSQL. Sob demanda, ele coloca o banco de dados no modo compatível com snapshot no momento em que um snapshot é feito. Se você usa 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 colocar o banco de dados no modo compatível com backup, a cópia resultante do banco de dados 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 do Trabalho 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 que o processo de backup comece e desbloqueá-lo após o término do processo. Para outros SGBDs existem ferramentas semelhantes para ativar/desativar os modos correspondentes.

Alguns administradores de banco de dados têm certeza de que podem fazer backup de seus bancos de dados com segurança com a ajuda de ferramentas padrão de backup de arquivos se o SGBD tiver um log de transações, porque no máximo apenas esse log será corrompido. É um equívoco perigoso que os desenvolvedores de SGBDs não apoiam.

As raízes desse equívoco são claras: a publicidade agressiva dos desenvolvedores de máquinas virtuais e ferramentas de backup geralmente deixa de mencionar que bancos de dados, assim como outros arquivos atualizados intensivamente, exigem configuração avançada. Não acredite no hype - nem todos os iogurtes têm benefícios iguais.

Recomendações: não use ferramentas de backup de arquivos e de VMs 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

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

Todos adoram a replicação pela capacidade de sincronizar dados em outro servidor com o mínimo de atraso, mas o backup também tem algumas vantagens indiscutíveis. Por exemplo, em caso de exclusão acidental (ou intencional) de dados, a replicação rapidamente e imperturbavelmente enviará 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 certo esforço para configurar corretamente tanto a replicação quanto o backup e, ainda assim, a possibilidade de erros existe de qualquer forma.

Recomendações: Se você tem 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 tanto ferramentas de backup quanto de replicação.

Resumo

Não é tão fácil configurar backup para seu SGBD favorito, então geralmente os administradores de banco de dados de organizações onde os dados são valorizados costumam usar ferramentas profissionais de backup que permitem levar em conta as questões mencionadas acima e prevenir os problemas.

Para o Firebird (perdão pela 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 dos backups.

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

Contatos

Fique à 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