Os sistemas de banco de dados têm a responsabilidade de armazenar e garantir a disponibilidade consistente de dados relevantes sempre que necessário, a qualquer momento da operação. A maioria das empresas não consegue continuar com os negócios após casos de perda de dados como resultado de uma falha de banco de dados, ponte de segurança, erro humano ou falha catastrófica que pode destruir completamente os nós operacionais em produção. Manter bancos de dados no mesmo data center coloca um em alto risco de perder todos os dados em caso desses ultrajes.
Replicação e Backup são as formas mais usadas de garantir alta disponibilidade de dados. A seleção entre os dois depende da frequência com que os dados são alterados. O backup é melhor quando os dados não mudam com mais frequência e não há expectativa de ter tantos arquivos de backup. Por outro lado, a replicação é preferida para dados que mudam com frequência, além de alguns outros méritos associados, como servir dados em um local específico, reduzindo a latência das solicitações. No entanto, a replicação e o backup podem ser usados para máxima integridade e consistência dos dados durante a restauração em qualquer caso de falha.
Os backups de banco de dados trazem mais vantagens além de fornecer um ponto de restauração para fornecer noções básicas para a criação de novos ambientes para desenvolvimento, acesso aberto e preparação sem temperar com a produção. A equipe de desenvolvimento pode testar de forma rápida e fácil recursos recém-integrados e acelerar seu desenvolvimento. Os backups também podem ser usados no ponto de verificação para erros de código sempre que os dados resultantes não forem consistentes.
Considerações para fazer backup do MongoDB
Os backups são criados em determinados pontos para refletir (agindo como um instantâneo do banco de dados) quais dados o banco de dados hospeda naquele determinado momento. Se o banco de dados falhar em um determinado ponto, podemos usar o último arquivo de backup para reverter o banco de dados para um ponto anterior à falha. No entanto, é preciso levar em consideração alguns fatores antes de fazer uma recuperação e eles incluem:
- Objetivo do ponto de recuperação
- Objetivo de tempo de recuperação
- Isolamento de banco de dados e instantâneo
- Complicações com fragmentação
- Processo de restauração
- Fatores de desempenho e armazenamento disponível
- Flexibilidade
- Complexidade da implantação
Objetivo do ponto de recuperação
Isso é feito para determinar quantos dados você está pronto para perder durante o processo de backup e restauração. Por exemplo, se tivermos dados do usuário e dados do fluxo de cliques, os dados do usuário terão prioridade sobre a análise do fluxo de cliques, pois o último pode ser regenerado por operações de monitoramento em seu aplicativo após a restauração. Um backup contínuo deve ser preferido para dados críticos, como informações bancárias, dados do setor de produção e informações de sistemas de comunicação, e deve ser realizado em intervalos curtos. Se os dados não forem alterados com frequência, pode ser mais barato perder grande parte deles se você fizer um instantâneo restaurado de, por exemplo, 6 meses ou 1 ano antes.
Objetivo de tempo de recuperação
Isso é para analisar e determinar a rapidez com que a operação de restauração pode ser feita. Durante a recuperação, seus aplicativos sofrerão algum tempo de inatividade que também é diretamente proporcional à quantidade de dados que precisam ser recuperados. Se você estiver restaurando um grande conjunto de dados, levará mais tempo.
Isolamento de banco de dados e instantâneo
O isolamento é uma medida de quão próximos os instantâneos de backup estão dos servidores de banco de dados primários em termos de configuração lógica e física. Se eles estiverem próximos o suficiente, o tempo de recuperação reduz à custa do aumento da probabilidade de serem destruídos ao mesmo tempo em que o banco de dados é destruído. Não é aconselhável hospedar backups e o ambiente de produção no mesmo sistema para evitar que qualquer interrupção nos servidores também seja mitigada nos backups.
Complicações com fragmentação
Para um sistema de banco de dados distribuído por meio de fragmentação, alguma complexidade de backup é apresentada e as atividades de gravação podem ter que ser pausadas em todo o sistema. Fragmentos diferentes terminarão diferentes tipos de backups em momentos diferentes. Considerando backups lógicos e backups de instantâneos,
Backups lógicos
- Os fragmentos são de tamanhos diferentes, portanto, terminarão em momentos diferentes
- Os dumps baseados no MongoDB ignorarão o --oplog, portanto, não serão consistentes em cada fragmento.
- O balanceador pode estar desligado enquanto deveria estar ligado apenas porque alguns fragmentos talvez não tenham concluído o processo de restauração
Backups de instantâneo
- Funciona bem para uma única réplica das versões 3.2 e posteriores. Você deve, portanto, considerar atualizar sua versão do MongoDB.
Processo de restauração
Algumas pessoas fazem backups sem testar se funcionarão em caso de restauração. Um backup em essência é fornecer um recurso de restauração, caso contrário, ele se tornará inútil. Você deve sempre tentar executar os backups em diferentes servidores de teste para ver se eles estão funcionando.
Fatores de desempenho e armazenamento disponível
Os backups também tendem a ter vários tamanhos como os dados do próprio banco de dados e precisam ser compactados o suficiente para não ocupar muito espaço desnecessário que pode cortar os recursos gerais de armazenamento do sistema. Eles podem ser arquivados em arquivos zip, reduzindo assim seus tamanhos gerais. Além disso, como mencionado anteriormente, é possível arquivar os backups em diferentes datacenters a partir do próprio banco de dados.
Os backups podem determinar diferentes desempenhos do banco de dados, pois alguns podem degradá-lo. Nesse caso, os backups contínuos renderão algum contratempo, portanto, devem ser convertidos em backups agendados para evitar o esgotamento das janelas de manutenção. Na maioria dos casos, os servidores secundários são implantados para oferecer suporte a backups. Nesse caso:
- Não é possível fazer backup de nós únicos de forma consistente porque o MongoDB usa leitura não confirmada sem um oplog ao usar o comando mongodump e, nesse caso, os backups não serão seguros.
- Use nós secundários para backups, pois o processo em si leva tempo de acordo com a quantidade de dados envolvidos e os aplicativos conectados sofrerão algum tempo de inatividade. Se você usar o primário que também precisa atualizar os Oplogs, poderá perder alguns dados durante esse tempo de inatividade
- O processo de restauração leva muito tempo, mas os recursos de armazenamento atribuídos são pequenos.
Flexibilidade
Muitas vezes você pode não querer alguns dos dados durante o backup, como no exemplo do Objetivo do Ponto de Recuperação, pode-se querer que a recuperação seja feita e filtre os dados de cliques do usuário. Para fazer isso, você precisa de uma estratégia de backup parcial que forneça a flexibilidade de filtrar os dados nos quais você não está interessado, reduzindo assim a duração da recuperação e os recursos que seriam desperdiçados. O backup incremental também pode ser útil para que apenas as partes de dados que foram alteradas sejam copiadas a partir do último instantâneo, em vez de fazer backups inteiros para cada instantâneo.
Complexidade da implantação
Sua estratégia de backup deve ser fácil de configurar e manter com o tempo. Você também pode agendar seus backups para não precisar fazê-los manualmente sempre que quiser.
Conclusão
Os sistemas de banco de dados garantem “vida após a morte” se apenas houver um sistema de backup bem estabelecido no local. O banco de dados pode ser destruído por fatores catastróficos, erro humano ou ataques de segurança que podem levar à perda ou corrupção de dados. Antes de fazer um backup, é preciso considerar o tipo de dados em termos de tamanho e importância. Nem sempre é aconselhável manter seus backups no mesmo data center que seu banco de dados para reduzir a probabilidade de os backups serem destruídos simultaneamente. Backups podem alterar o desempenho do banco de dados, portanto, deve-se ter cuidado com a estratégia a ser usada e quando realizar o backup. Não execute seus backups no nó primário, pois isso pode resultar em tempo de inatividade do sistema durante o backup e, consequentemente, perda de dados importantes.
