Guia completo para backup e restauração de banco de dados MongoDB

Introdução: Por que os backups são importantes para o MongoDB?

Ao usar o MongoDB na produção, o backup é essencial – ele pode significar a diferença entre a recuperação de um incidente e a perda permanente de dados. Um banco de dados como o MongoDB que contém informações de usuários, transações, informações de produtos ou estado de aplicativos é um banco de dados em que a integridade dos dados se traduz diretamente em continuidade dos negócios. Os processos de backup e restauração dos dados do MongoDB são a base dessa integridade.

Uma única falha de hardware, exclusão não intencional ou infecção por ransomware pode resultar em perda significativa de dados. As opções de recuperação viáveis nesses casos também não existiriam se não houvesse uma estratégia de backup sólida e confiável em vigor. A qualidade de um plano de backup do MongoDB implementado hoje determinará a rapidez com que os sistemas poderão voltar a ficar on-line depois de uma eventual falha, como acontece com a maioria dos sistemas, infelizmente.

Quais são os riscos de não ter uma estratégia de backup confiável?

Há três categorias principais de risco na execução de um sistema MongoDB sem nenhuma estratégia de backup:

• Operacional
• Financeiro
• Reputacional

Todas essas categorias têm algum tipo de efeito que se acumulará com o tempo e se tornará muito mais difícil de corrigir após eventos de perda de dados.

O risco operacional é o mais imediato. Quando um nó primário falha, uma coleção cai ou uma migração falha, o cluster fica em um estado inconsistente. Para começar, o banco de dados de backup do MongoDB esperado não existe, de modo que a equipe precisa executar a recuperação forense a partir de logs de aplicativos ou exportações fragmentadas, se existirem.

A exposição financeira vem logo em seguida. As obrigações de conformidade impostas por regulamentações como GDPR, HIPAA e SOC 2 significam que uma falha de backup será um incidente de conformidade, não uma mera falha técnica. Auditorias subsequentes, multas e notificações obrigatórias de violação podem ser atribuídas a práticas de backup e restauração do MongoDB mal implementadas ou inexistentes.

Os modos de falha mais comuns que as organizações encontram incluem:

• Quedas acidentais de coleções – um desenvolvedor executa db.collection.drop() no ambiente errado
• Migrações de esquema malfeitas – um script de transformação corrompe documentos em escala antes que o erro seja detectado
• Ataques de ransomware e infraestrutura – os dados criptografados tornam-se inacessíveis sem uma cópia off-line
• Falha de hardware sem redundância – um nó autônomo cai sem réplica e sem snapshot recente
• Corrupção silenciosa – os problemas de integridade dos dados não são detectados até que um backup seja necessário e, nesse momento, os backups existentes também podem ser corrompidos

Os danos à reputação são mais difíceis de quantificar, mas isso não os torna menos reais. Tanto os usuários individuais quanto os corporativos que confiam seus dados a uma plataforma esperam que esses dados permaneçam seguros. Um evento de perda de dados amplamente divulgado, mesmo que tenha sido causado por um problema de infraestrutura e não por intenção mal-intencionada, prejudica tanto a confiança do usuário que leva anos para ser recuperada e reconstruída.

Como os tipos de implementação do MongoDB afetam as necessidades de backup (autônomo, conjunto de réplicas, cluster sharded)?

A topologia de implementação do MongoDB atualmente em uso determina os possíveis métodos de backup disponíveis, o nível de complexidade e as garantias de consistência disponíveis. As três principais topologias existentes são autônoma, conjunto de réplicas e cluster fragmentado, todas com diferentes requisitos de backup.

As implementações autônomas são as mais simples de fazer backup, mas apresentam o maior risco inerente. Como não há um sistema secundário para o qual fazer o failover enquanto os backups estão sendo executados, qualquer processo de backup altamente intensivo em E/S competirá diretamente com o tráfego de produção. Os snapshots do sistema de arquivos com suporte à semântica copy-on-write são os mais adequados nessa situação, como LVM ou ZFS (ambos são instantâneos e não causam interrupções).

Os conjuntos de réplicas introduzem um alto grau de flexibilidade operacional. O processo de backup do MongoDB pode ser descarregado em um nó secundário, mantendo a carga de trabalho de backup isolada da carga de trabalho primária. Os backups baseados no Oplog também se tornam possíveis nesse caso, permitindo a recuperação pontual para qualquer momento usando a janela de retenção do oplog – algo que as implementações autônomas não podem oferecer.

O oplog é um registro com data e hora limitados de cada operação de gravação no banco de dados, que o MongoDB pode usar para fins de replicação, reproduzindo-o para restaurar os dados para qualquer ponto anterior no tempo.

Os clusters sharded exigem a coordenação mais cuidadosa. Cada shard é tratado como um conjunto de réplicas independente, e é por isso que capturar todos os shards e o conjunto de réplicas do servidor de configuração no mesmo ponto lógico no tempo para obter um backup consistente em todo o cluster. O recurso de balanceador de blocos deve ser pausado antes do início do backup, e seria difícil garantir a consistência entre os fragmentos sem uma coordenação explícita. O MongoDB Atlas Backup (serviço de banco de dados em nuvem gerenciado do MongoDB) lida com a maioria dessas tarefas automaticamente, mas os clusters sharded autogerenciados ainda exigem orquestração manual ou uma ferramenta de terceiros.

Que objetivo de tempo de recuperação (RTO) e objetivo de ponto de recuperação (RPO) devo considerar?

RTO e RPO são as duas métricas que definem o que uma estratégia de backup deve oferecer. O objetivo de tempo de recuperação (RTO) é a duração máxima aceitável entre um evento de falha e a restauração do serviço normal. O Recovery Point Objective (RPO) é a quantidade máxima aceitável de perda de dados, expressa em um ponto no tempo. Ambos os valores devem ser definidos antes mesmo de tentar selecionar ferramentas de backup ou padrões de agendamento – esses são os requisitos para os quais todas as outras decisões servem.

A maioria das organizações só consegue definir o RTO e o RPO depois de passar por uma interrupção de grande porte, o que as obriga a definir esses parâmetros sob pressão. Por exemplo, um aplicativo voltado para o cliente que processa pedidos continuamente não pode tolerar quatro horas de tempo de inatividade ou seis horas de perda de dados. Muitas configurações de backup que nunca foram testadas quanto ao estresse produziriam exatamente esses resultados.

Use a estrutura a seguir para estabelecer metas de linha de base:

Um pipeline de backup e restauração de banco de dados MongoDB com RPO de cinco minutos será completamente diferente de um pipeline com RPO de 24 horas. O backup contínuo baseado em Oplog é necessário para permitir pontos de recuperação abaixo de uma hora, pois ele captura cada operação de gravação quase em tempo real. As estratégias somente de snapshot (captura de snapshots em determinados intervalos) produzem um ponto de recuperação igual à frequência do snapshot, o que significa que uma programação de snapshot de quatro horas produz um RPO de quatro horas no pior dos casos.

Os RTOs são igualmente sensíveis quando se trata de escolher uma estratégia de backup. A restauração de 2 TB de um arquivo mongodump do storage de objeto levaria várias horas para ser concluída. Enquanto isso, a restauração de um instantâneo do sistema de arquivos que reside no armazenamento em bloco anexado levaria apenas alguns minutos. O próprio processo de restauração do MongoDB, e não apenas o formato de backup, deve ser levado em consideração em todos os cálculos de RTO. As equipes que documentam e testam regularmente suas estruturas de restauração têm maior probabilidade de atingir suas metas de RTO quando isso for importante.

Como o backup do MongoDB se encaixa em uma estratégia mais ampla de proteção de dados corporativos?

O backup é apenas uma faceta de uma estratégia de proteção; não é a totalidade. Embora o backup do MongoDB abranja os dados no nível do banco de dados (coleções, índices, usuários e definições de configuração), a resiliência corporativa também exige uma cobertura adequada do estado do aplicativo, do gerenciamento de segredos e das dependências entre serviços. A estratégia de backup do MongoDB que uma empresa opta por implementar deve ser definida com esse objetivo abrangente em mente.

Por que o backup no nível do banco de dados não é suficiente para a resiliência da empresa?

Um backup completo do MongoDB captura todo o conteúdo do mecanismo do banco de dados. Ele não captura o seguinte:

• Configuração do aplicativo que informa ao banco de dados como se comportar
• Certificados TLS que protegem as conexões com o banco de dados
• Variáveis de ambiente que armazenam credenciais
• Estado da infraestrutura, que descreve a topologia de rede na qual ele é executado

A recuperação de um backup do MongoDB em um ambiente instável ou mal configurado criará um banco de dados funcional no qual seu aplicativo não poderá se conectar ou se autenticar. Para que as empresas sejam resilientes, elas precisarão levar em conta cada um dos itens a seguir:

1. Configuração e segredos do aplicativo – arquivos de ambiente, entradas do Vault, cadeias de conexão e chaves de API das quais os serviços dependem
2. Estado da infraestrutura – definições do Terraform ou do CloudFormation que descrevem o ambiente de rede, computação e armazenamento
3. Consistência de dados entre serviços – registros relacionados em outros bancos de dados ou filas de mensagens que devem estar alinhados com o ponto de restauração do MongoDB
4. A própria configuração do MongoDB – definições de conjunto de réplicas, funções de usuário e índices personalizados que nem sempre são capturados por um mongodump básico

Como os backups do MongoDB se integram às plataformas de backup corporativo?

Normalmente, a integração é obtida por meio de um dos três mecanismos principais: ganchos de backup pré/pós que acionam o mongodump ou um instantâneo antes de a plataforma capturar o sistema de arquivos, plug-ins baseados em agentes que o fornecedor da plataforma fornece ou suporta ou orquestração orientada por API em que a plataforma de backup chama um script externo que lida com as etapas específicas do MongoDB.

As plataformas com as quais as organizações mais comumente integram o MongoDB incluem:

• Bacula Enterprise. Integração baseada em plugins com suporte a scripts pré-job; adequada para ambientes regulamentados que exigem trilhas de auditoria
• Veeam. Abordagem que prioriza o instantâneo; a consistência do MongoDB requer processamento com reconhecimento de aplicativo ou scripts de pré-congelamento
• Commvault. Integração com o IntelliSnap para snapshots em nível de bloco; suporta topologias de conjunto de réplicas e cluster sharded
• NetBackup (Veritas). Baseado em agente com agendamento de políticas; plug-in MongoDB disponível para níveis de licenciamento corporativo

Como os sistemas de backup centralizados reduzem o risco operacional?

Ter cada equipe responsável por gerenciar seu próprio processo de backup do MongoDB resultará em agendamentos variáveis, retenção inconsistente e nenhuma maneira de saber se os backups foram bem-sucedidos. Os sistemas de backup centralizados reforçam a uniformidade da política em todas as instâncias do banco de dados, o que elimina a classe de incidentes que surgem quando o trabalho de backup de uma equipe é silenciosamente interrompido por semanas.

A vantagem operacional aqui não se refere apenas à visibilidade, mas também à responsabilidade. Um sistema centralizado que rastreia todas as tarefas de backup, verifica cada snapshot concluído e faz o escalonamento em caso de falha cria uma trilha claramente documentada que, muitas vezes, é necessária para fins de auditoria de conformidade. O gerenciamento de backup do MongoDB distribuído entre equipes tende a produzir lacunas que só são descobertas quando há uma necessidade urgente de restauração.

Quais estratégias de backup do MongoDB estão disponíveis?

A estratégia adequada de backup do banco de dados MongoDB dependerá da topologia de sua implantação, da janela tolerável de perda de dados e da complexidade operacional. As três estratégias básicas de backup descritas abaixo – backup lógico, backup físico e restauração point-in-time baseada em logs – também não são mutuamente exclusivas. Duas ou todas essas três opções são usadas em conjunto na maioria dos ambientes de produção.

O que é backup lógico e quando o senhor deve usar o mongodump/mongorestore?

O backup lógico tira um instantâneo dos dados do MongoDB como documentos BSON que são gravados em arquivos pelo mongodump. O Mongorestore é então capaz de restaurar esses dados em qualquer outra instância compatível do MongoDB. Esse processo é independente de topologia, não precisa de acesso a um sistema de arquivos e gera uma saída portátil que pode ser examinada, filtrada ou restaurada com base em cada coleção.

O backup do MongoDB produzido pelo mongodump captura documentos, índices, usuários e funções. Ele não captura o oplog nem as transações em andamento, o que significa que esse instantâneo pontual é tão consistente quanto o momento em que o dump é concluído, enquanto o processo em si pode levar minutos ou até horas (em grandes conjuntos de dados).

O backup lógico é a escolha certa quando:

• A portabilidade é importante – mover dados entre versões do MongoDB ou provedores de nuvem
• A restauração seletiva é necessária – recuperação de uma única coleção sem afetar o restante do banco de dados
• O conjunto de dados é pequeno – menos de ~100 GB, em que a duração do dump não cria um risco significativo de consistência
• Não há acesso ao sistema de arquivos disponível – ambientes de hospedagem gerenciada em que as APIs de snapshot não são expostas

Para implantações grandes e com muita gravação, o mongodump sozinho raramente é suficiente como estratégia principal de backup e restauração do MongoDB.

O que é backup físico e quando o senhor deve usar snapshots do sistema de arquivos?

O backup físico faz uma cópia dos arquivos de dados brutos que o MongoDB grava no sistema de arquivos (os arquivos do mecanismo de armazenamento WiredTiger, o diário e os índices) no nível do sistema de arquivos/bloco. As ferramentas adequadas para conseguir isso incluem snapshots LVM no Linux, snapshots AWS EBS e recurso de envio/recebimento ZFS.

Como o backup é instantâneo e ocorre fora do processo do mongoDB, os backups são muito mais rápidos de criar do que o mongodump em grandes conjuntos de dados e o próprio banco de dados quase não sabe que o backup está em andamento, em termos de desempenho.

O principal pré-requisito para o backup físico é a consistência do sistema de arquivos. O MongoDB deve estar em um estado de checkpoint limpo ou deve ter o journaling ativado (uma medida padrão com o WiredTiger) para que o snapshot represente um estado recuperável. Tentar criar um snapshot sem levar isso em conta resultaria em um backup que poderia nem mesmo ser iniciado durante um procedimento de recuperação de desastres do MongoDB.

O backup físico é a escolha certa quando:

• O tamanho do conjunto de dados é grande – onde a duração do mongodump criaria uma lacuna de consistência inaceitavelmente ampla
• O RTO é apertado – as restaurações em nível de bloco são mais rápidas do que a reimportação em nível de documento
• A infraestrutura oferece suporte a snapshots atômicos – ambientes EBS, LVM ou ZFS em que snapshots copy-on-write estão disponíveis
• A restauração completa do cluster é o cenário esperado, em vez da recuperação seletiva em nível de coleção

Como funcionam os backups point-in-time e os métodos baseados em oplog?

A recuperação point-in-time funciona emparelhando um snapshot de base com a reprodução do oplog para recuperar uma implementação do MongoDB para qualquer ponto específico dentro da janela de retenção do oplog. Os nós secundários usam o oplog para fins de replicação, enquanto os backups o utilizam para preencher a lacuna entre o snapshot de base e o ponto de recuperação de destino.

O processo funciona da seguinte forma: um snapshot de base é tirado no momento T, capturando o estado completo do banco de dados. O oplog é então capturado continuamente ou em intervalos a partir do tempo T. Na restauração, o instantâneo de base é usado primeiro e, em seguida, as entradas do oplog são reproduzidas até o registro de data e hora de destino, criando um estado do banco de dados que é preciso para aquele momento exato.

Há duas restrições práticas que regem essa abordagem. A primeira é o fato de que o oplog é limitado – já que as entradas mais antigas são sobrescritas quando novas entradas precisam acontecer, portanto, a janela de recuperação sempre será limitada pelo tamanho do oplog e pelo volume de gravação. A segunda restrição lida com o fato de que a recuperação point-in-time requer um conjunto de réplicas, pois as implantações autônomas não têm oplog e não podem suportar esse método sem o Atlas ou uma solução de terceiros.

Quando o senhor deve usar o backup incremental do MongoDB em vez do backup completo?

Um backup completo copia todo o conjunto de dados em cada execução. Um backup incremental copia apenas as modificações feitas desde o último backup, seja por meio do oplog tailing ou do rastreamento de alterações em nível de bloco. A melhor opção para cada organização varia drasticamente, dependendo do tamanho do conjunto de dados, da frequência de backup e do custo de armazenamento.

Uma estratégia típica de backup é usar um backup completo semanal com backups incrementais diários ou de hora em hora, oferecendo uma compensação entre a necessidade de espaço e a complexidade da restauração. Cada backup completo reinicializa a cadeia incremental e limita a idade do incremento, reduzindo o escopo da corrupção até certo ponto.

Quais ferramentas e serviços suportam o backup e a restauração do banco de dados MongoDB?

O ecossistema de backup e restauração do MongoDB abrange um grande número de elementos segregados em grupos: serviços de nuvem gerenciados, utilitários de linha de comando nativos, ferramentas no nível do sistema de arquivos e plataformas corporativas de terceiros. Cada uma dessas opções tem uma posição distinta no espectro “simplicidade operacional – controle”.

Quais são os prós e os contras do MongoDB Atlas Backup?

O MongoDB Atlas Backup é um serviço de backup totalmente gerenciado que vem com os clusters do Atlas. O serviço é executado continuamente, não exige nenhuma configuração após a ativação e ainda oferece suporte à recuperação baseada em registro de data e hora a qualquer momento durante o período de retenção. É a maneira mais simples de implementar um plano de backup do MongoDB pronto para produção para equipes que já usam o MongoDB Atlas.

Os recursos mais notáveis do Atlas Backup estão resumidos na tabela abaixo.

A portabilidade é a maior limitação do Atlas Backup. Se uma solução foi configurada para um cluster, ela não é transferida para uma implementação autogerenciada, e todas as restaurações precisam ser realizadas por meio da interface do Atlas ou da API (inacessível por meio de ferramentas padrão do mongorestore). Essa única restrição pode ser um obstáculo para as organizações que trabalham com mandatos de várias nuvens ou requisitos regulamentares centrados na residência de dados.

Como funciona o MongoDB Atlas Backup to S3 e quando o senhor deve usá-lo?

O MongoDB Atlas Backup to S3 é um recurso de exportação de instantâneos, e não um fluxo de replicação contínua. Ele pode ser acionado manualmente ou em uma programação. Uma vez acionado, o Atlas tira um instantâneo consistente do cluster, gravando-o em um bucket S3 especificado em um formato que possibilita restaurar esses dados posteriormente com as ferramentas padrão do MongoDB. O instantâneo exportado produzido como resultado é desacoplado do próprio Atlas, tornando-o apropriado para arquivamento de longo prazo, cópia entre regiões ou como parte dos requisitos de retenção de conformidade.

Também é importante deixar claro o que é e o que não é esse recurso. O Atlas Backup não oferece streaming em tempo real das alterações do registro de dados para o S3. A exportação é feita em um ponto específico no tempo, e o intervalo entre essas exportações é o RPO efetivo para qualquer coisa que dependa exclusivamente de cópias do S3. As equipes que precisam de pontos de recuperação em menos de uma hora devem tratar essas exportações do S3 como uma camada de arquivamento secundária, e não como um mecanismo de recuperação de dados primário.

Os backups do Atlas devem ser empregados quando houver necessidade de retenção ou portabilidade de longo prazo fora do Atlas. Não confie nele como o único método de backup do MongoDB na produção, especialmente quando os RPOs já são suficientemente rigorosos.

Como o mongodump/mongorestore se compara ao mongorestore com replay de oplog?

O mongodump normal tira um único instantâneo lógico consistente do banco de dados. A restauração por meio do mongorestore repete o snapshot como está, criando um banco de dados que retorna ao seu estado exato no momento em que o dump foi concluído, sem nenhuma opção de recuperação para qualquer outro ponto.

O mongorestore com repetição de oplog amplia o resultado mencionado acima, aplicando as operações no oplog em relação ao instantâneo restaurado, trazendo o banco de dados para um registro de data e hora desejado. Essa funcionalidade essencial é o que torna possível a recuperação point-in-time para implementações autogerenciadas.

O sinalizador de repetição do oplog(–oplogReplay) força o mongorestore a aplicar todas as entradas do oplog incluídas no dump diretamente assim que o processo de restauração do documento for concluído. Essa opção é possível com o uso de um sinalizador específico(–oplog) para capturar o próprio oplog junto com o mongodump.

Como os snapshots no nível do sistema de arquivos (LVM, EBS, ZFS) podem ser usados com segurança com o MongoDB?

O requisito de consistência para que um backup físico do MongoDB seja válido são os arquivos de dados que representam um ponto de verificação limpo do WiredTiger. A razão pela qual o WiredTiger pode ser usado é que ele grava dados em segundo plano e mantém um diário. Se o senhor tirar um instantâneo dos arquivos de dados enquanto o mecanismo estiver em execução, o instantâneo poderá ser recuperado, desde que o journaling esteja ativado (como sempre está por padrão). Ele não precisa necessariamente ser um instantâneo dos dados enquanto o Mongo estiver parado, mas precisa ser um instantâneo atômico no nível do sistema de arquivos.

A forma como esse nível de atomicidade é alcançado depende da ferramenta:

• Instantâneos LVM – instantâneos copy-on-write de um volume lógico; instantâneos e consistentes se os dados e o diário do MongoDB residirem no mesmo volume. Para dividi-los entre volumes, é necessário fazer o snapshot de ambos simultaneamente.
• Instantâneos do Amazon EBS – instantâneos em nível de bloco acionados via API do AWS; adequados para MongoDB hospedado na nuvem com dados em volumes EBS. A consistência de vários volumes requer o uso de grupos de snapshots de vários volumes do EBS.
• Envio/recebimento de ZFS – os snapshots de ZFS são atômicos por design e capturam o conjunto de dados completo em um estado consistente. Adequado para implementações locais em que o ZFS é o sistema de arquivos subjacente.

O único cenário que pode ser considerado inseguro nessas circunstâncias é quando o MongoDB é usado sem journaling em um sistema de arquivos não ZFS. Felizmente, esse tipo de configuração é raro nas implementações modernas, mas ainda assim vale a pena verificar antes de confiar em backups do MongoDB baseados em snapshot durante a produção.

Existem ferramentas de backup de terceiros e quais recursos elas oferecem?

Várias soluções de terceiros complementam ou fornecem uma alternativa aos recursos de backup integrados do MongoDB, especialmente em ambientes corporativos autogerenciados em que o Atlas não está em uso:

• Percona Backup for MongoDB (PBM) – de código aberto, oferece suporte a backup lógico e físico, recuperação de repetição de logs e coordenação de cluster sharded. A alternativa auto-hospedada mais capaz ao Atlas Backup.
• Bacula Enterprise – plataforma de backup corporativo com integração ao MongoDB por meio de scripts pré/pós-trabalho e suporte a plugins; recursos sólidos de trilha de auditoria e conformidade para ambientes regulamentados.
• Ops Manager (MongoDB) – plataforma de gerenciamento local do próprio MongoDB que inclui backup contínuo com restauração pontual baseada em logs; requer uma implantação separada do Ops Manager.
• Dbvisit Replicate – ferramenta de captura de dados de alteração que pode servir como função de backup para o MongoDB, transmitindo as alterações para um destino secundário.
• Serviços de snapshot nativos da nuvem – o AWS Backup, o Azure Backup e o Google Cloud Backup oferecem suporte a snapshots em nível de volume que podem incluir diretórios de dados do MongoDB quando configurados corretamente.

Um ponto de partida comum para a maioria das implantações autogerenciadas que não têm uma plataforma de backup corporativo existente é o Percona Backup for MongoDB. Ele é gratuito, desenvolvido ativamente e tem as principais funções necessárias para o fluxo de trabalho completo de backup e restauração do banco de dados MongoDB.

Como o backup do MongoDB pode ser integrado ao Bacula Enterprise para proteção empresarial?

O Bacula Enterprise é uma solução abrangente de backup que permite às organizações centralizar a proteção de dados em ambientes heterogêneos compostos por servidores físicos, máquinas virtuais, instâncias de nuvem e bancos de dados.

A integração de backup do MongoDB com o Bacula é alcançada por meio de scripts pré e pós-trabalho. O Bacula inicia um mongodump ou um snapshot do sistema de arquivos antes de fazer o backup dos arquivos gerados e, em seguida, executa ações de retenção de dados, criptografia e transferência remota de acordo com a política pré-configurada.

O que o Bacula traz para uma estratégia de proteção de dados MongoDB que as ferramentas nativas não oferecem:

• Agendamento centralizado e aplicação de políticas – os trabalhos de backup do MongoDB são executados na mesma estrutura de agendamento e retenção que todas as outras cargas de trabalho no ambiente, eliminando a inconsistência que vem dos trabalhos cron gerenciados pela equipe.
• Trilhas de auditoria e relatórios de conformidade – cada tarefa de backup é registrada com carimbos de data/hora, status de sucesso e volume de dados, produzindo o registro verificável que os setores regulamentados exigem
• Armazenamento e transporte criptografados – por padrão, os dados são criptografados em repouso e em trânsito, com o gerenciamento de chaves feito no nível da plataforma e não por banco de dados
• Alerta e escalonamento de falhas – os trabalhos de backup do MongoDB que falharam passam pelo mesmo pipeline de alerta que as falhas de infraestrutura, em vez de passarem despercebidos em um registro de script
• Suporte a cópias em vários locais e em air-gap – o Bacula oferece suporte a alvos de fita, armazenamento de objetos e locais remotos, o que é valioso para organizações que exigem cópias de backup do MongoDB off-line ou em air-gap como parte de sua postura de proteção contra ransomware

É também uma transição perfeita para as organizações que já estão confiando no Bacula Enterprise para suas necessidades de backup. Em vez de construir mais uma infraestrutura de backup separada, o processo de backup do MongoDB é facilmente integrado ao sistema existente, resultando em uma redução significativa da proliferação de ferramentas e da complexidade de gerenciamento.

Como o senhor realiza um backup seguro para diferentes topologias de MongoDB?

Um método de backup do MongoDB adequado para um único servidor não garante necessariamente a integridade e a ausência de interrupções de serviço quando aplicado a um conjunto de réplicas ou cluster sharded sem adaptação. Um dos principais motivos para isso é um grande número de fatores que mudam dependendo da topologia do MongoDB escolhida.

Como o senhor faz backup de um conjunto de réplicas sem afetar a disponibilidade?

O backup do seu conjunto de réplicas se baseia em um único princípio principal: nunca faça um backup com uso intensivo de recursos contra o primário quando puder evitá-lo. O primário recebe todo o tráfego de gravação, e um processo de backup que luta por sua E/S é a fonte de latência sentida por todos os usuários do aplicativo. A melhor opção é um secundário dedicado – configurado como um membro oculto, de preferência, para que não receba tráfego e exista apenas para tarefas operacionais como o backup.

O processo de backup seguro do conjunto de réplicas segue esta ordem:

1. Verifique o atraso da replicação no secundário de destino antes de iniciar. Um secundário com atraso produz um backup que não reflete o estado atual dos dados – verifique rs.printSecondaryReplicationInfo() e confirme se o atraso está dentro dos limites aceitáveis.
2. Selecione um secundário oculto ou de baixa prioridade como destino do backup para evitar a extração da capacidade de leitura dos membros que atendem aos aplicativos.
3. Inicie o backup – mongodump ou um snapshot do sistema de arquivos – no diretório de dados ou no ponto de extremidade de conexão do secundário.
4. Capture o oplog junto com o backup se for necessária uma recuperação pontual. Use –oplog com o mongodump ou registre o intervalo de registro de data e hora do oplog que corresponde à janela do snapshot.
5. Verifique o backup antes de fazer o rodízio das cópias antigas. Um backup que nunca foi testado não é um backup – é uma suposição.

Há também um caso interessante que vale a pena observar: se todos os secundários ficarem para trás devido a um pico no tráfego de gravação, talvez seja melhor atrasar completamente o backup em vez de correr o risco de criar um instantâneo inconsistente.

Como o senhor faz o backup de um cluster sharded e coordena a consistência no nível do shard?

O backup de cluster fragmentado é o mais complicado para gerenciar cenários de backup do MongoDB. Isso ocorre porque o senhor precisa atingir um ponto consistente no tempo em vários conjuntos de réplicas executados em momentos diferentes, independentemente uns dos outros. Cada shard tem seu próprio oplog e seu próprio estado, e o conjunto de réplicas do servidor de configuração é onde os metadados do cluster são armazenados, o que mapeia os blocos para os shards. Um backup que consegue capturar shards em diferentes momentos é inútil por padrão, pois cria uma imagem de cluster inconsistente.

O processo de coordenação aqui requer as seguintes etapas:

• Interromper o balanceador de blocos usando sh.stopBalancer() antes de iniciar qualquer atividade de backup. Um balanceador ativo migra blocos entre fragmentos durante o backup, o que produz um estado em que o mesmo documento pode aparecer em dois instantâneos de fragmentos ou em nenhum deles.
• Desative todas as migrações de blocos programadas durante a janela de backup para evitar que o rebalanceamento automático seja retomado no meio da captura.
• Faça primeiro o backup do conjunto de réplicas do servidor de configuração. O servidor de configuração mantém o mapa de blocos autoritativo – capturá-lo antes dos fragmentos garante que os metadados reflitam o estado do cluster antes do backup.
• Capture cada conjunto de réplicas de fragmentos usando o mesmo processo secundário-primeiro descrito acima, o mais próximo possível do tempo operacionalmente.
• Registre o registro de data e hora do oplog para cada shard no ponto de captura. Esses registros de data e hora são necessários se a restauração point-in-time precisar alinhar os estados dos fragmentos durante a recuperação.
• Reative o balanceador assim que todos os backups de fragmentos forem confirmados como concluídos.

O MongoDB Atlas realiza tudo isso automaticamente para clusters sharded hospedados pelo Atlas. Quanto aos ambientes autogerenciados, o Percona Backup for MongoDB tem a opção de executar um backup coordenado do cluster sharded sem a necessidade de gerenciamento manual do balanceador.

Como o senhor garante que os backups sejam consistentes ao usar journaling e WiredTiger?

O mecanismo WiredTiger (mecanismo de armazenamento padrão para MongoDB) grava dados por meio de uma combinação de ponto de verificação e journaling. Pelo menos uma vez a cada 60 segundos (ou sempre que o diário atingir um determinado limite de tamanho), o WiredTiger grava um ponto de verificação consistente no disco. Todas as gravações no disco são registradas em um diário entre os pontos de verificação. Dessa forma, os arquivos de dados + diário sempre conterão todo o estado recuperável do sistema.

Para o backup do MongoDB baseado em snapshot, isso significa que um snapshot do sistema de arquivos tirado em qualquer ponto enquanto o journaling estiver ativado pode ser restaurado com segurança. O instantâneo pode ficar entre dois pontos de verificação, mas o WiredTiger reproduzirá o diário automaticamente na inicialização para atingir a consistência.

O único requisito aqui é que tanto o diário quanto o diretório de dados precisam estar na mesma operação de instantâneo. Não é correto tirar um snapshot separado do diretório de dados e outro snapshot do diretório do diário – isso quebra a garantia de recuperação.

Quais são as etapas para restaurar o MongoDB a partir de backups?

Uma estratégia de backup que nunca foi restaurada é, por definição, não testada. O processo de restauração exige o mesmo nível de documentação e prática que o processo de backup, pois cada momento em que ele é necessário nunca é tranquilo.

Como restaurar um banco de dados de backup do MongoDB e preservar usuários e funções?

As informações de usuários e funções no MongoDB estão contidas no banco de dados de administração , e não nas coleções que eles governam. Uma operação de mongorestore em um banco de dados específico não restaurará os usuários e as funções desse banco de dados. Uma restauração completa (que também reescreve o banco de dados de administração ) pode, sem saber, remover usuários existentes ou duplicar usuários conflitantes.

O processo de restauração mais seguro com preservação de usuários e funções consiste em:

1. Interromper todas as conexões de aplicativos com a instância de destino antes do início da restauração. As conexões ativas durante uma restauração criam condições de corrida entre as gravações de entrada e o processo de restauração.
2. Restaurar primeiro o banco de dados de destino, excluindo o banco de dados administrativo : mongorestore –db <dbname> –drop <dump_path>/<dbname>.
3. Inspecione o banco de dadosadministrativo despejado antes de restaurá-lo, especificamente as coleções system.users e system.roles, para confirmar que não há conflitos com os usuários existentes na instância de destino.
4. Restaure os usuários e as funções seletivamente usando mongorestore –db admin –collection system.users e system.roles em vez de restaurar o banco de dados administrativo completo em uma única passagem.
5. Verifique as atribuições de função após a restauração executando db.getUsers() e confirmando que as contas de serviço de aplicativo têm os privilégios esperados.
6. Reative as conexões de aplicativos somente após a conclusão da verificação.

É recomendável usar o sinalizador –drop (soltar cada coleção antes da restauração) quando estiver executando uma restauração completa. No entanto, ele deve ser usado com cautela ao restaurar em uma instância que já contém os dados que o senhor deseja manter.

Como o senhor restaura um snapshot físico e traz os membros de volta para um conjunto de réplicas?

Há duas etapas separadas para a restauração de um snapshot físico: primeiro, os arquivos de dados devem ser restaurados e, em seguida, o nó deve ser adicionado novamente ao conjunto de réplicas.

Ver isso como um único processo costuma ser a causa de muitos problemas.

Fase 1 – Restauração do snapshot:

1. Interrompa completamente o processo mongod no nó de destino antes de tocar em qualquer arquivo de dados.
2. Limpe o diretório de dados existente para evitar que o WiredTiger encontre arquivos de armazenamento conflitantes na inicialização.
3. Monte ou copie o snapshot para o diretório de dados, garantindo que os arquivos de dados e o diretório do diário estejam presentes e intactos.
4. Inicie o mongod no modo autônomo – sem o sinalizador –replSet – para permitir que o WiredTiger conclua sua passagem de recuperação e alcance um ponto de verificação limpo antes que as operações de conjunto de réplicas sejam retomadas.

Fase 2 – Reintegração ao conjunto de réplicas:

1. Desligue o mongod autônomo assim que a passagem de recuperação for concluída de forma limpa.
2. Reinicie o mongod com o sinalizador–replSet restaurado para o nome original do conjunto de réplicas.
3. Adicione o membro de volta usando rs.add() do primário se ele tiver sido removido ou permita que ele se reintegre automaticamente se estiver apenas temporariamente off-line.
4. Monitore o progresso da sincronização inicial – se o snapshot for suficientemente recente, o membro aplicará apenas as entradas do oplog que perdeu, em vez de executar uma sincronização inicial completa do zero.

Observação importante: um instantâneo mais antigo do que a janela de retenção do oplog acionará um processo de sincronização inicial completo, independentemente de outras circunstâncias, o que pode ser um processo demorado quando se trata de conjuntos de dados grandes e complexos.

Como o senhor executa uma restauração point-in-time usando backups do oplog ou da nuvem?

A restauração pontual é um processo de duas etapas, independentemente de ser realizada por meio da reprodução do oplog em um cluster autogerenciado ou por meio da interface do Atlas. A primeira etapa prepara o estágio, tirando um instantâneo completo do estado do cluster antes do ponto de recuperação. A segunda etapa pega esse instantâneo e o avança reproduzindo apenas as operações entre o instantâneo e o registro de data e hora de destino.

Para a recuperação autogerenciada baseada em oplog, o mongorestore aceita o sinalizador –oplogReplay juntamente com um dump que foi capturado com –oplog. O sinalizador –oplogLimit especifica o teto do registro de data e hora – em segundos desde a época – além do qual as entradas do oplog não são mais aplicadas. Para identificar o registro de data e hora correto, é necessário inspecionar os registros do oplog ou do aplicativo para localizar a última operação “boa” antes do evento que acionou a restauração.

Para a restauração pontual do Atlas, todo o processo é conduzido usando a UI ou a API do Atlas. Um registro de data e hora de destino é selecionado dentro da janela de retenção, o Atlas constrói a restauração internamente e o cluster recuperado é provisionado como uma nova instância. O cluster original não é sobrescrito por padrão, preservando sua capacidade de comparar estados antes de se comprometer com o ponto de recuperação.

Em ambos os cenários, a única etapa que todas as equipes tendem a ignorar quando estão sob pressão é a verificação do estado recuperado, antes de desativar a máquina de produção. Essa etapa também é a que descobre índices perdidos, permissões de usuário incorretas e recuperações incompletas antes de atingir a produção.

Como o senhor lida com as incompatibilidades de versões entre o backup e as versões de destino do MongoDB?

Há um perigo real em restaurar um backup do MongoDB de um intervalo de versões para outro. O formato de armazenamento do WiredTiger pode mudar, assim como o esquema do oplog e os sinalizadores de compatibilidade de recursos, o que faz com que o backup não seja concluído ou que o banco de dados seja iniciado, mas não funcione corretamente.

Alguns dos exemplos mais comuns de cenários de restauração são:

O sinalizador Feature Compatibility Version (FCV) é o mecanismo que o MongoDB usa para restringir o acesso a recursos específicos da versão. Um banco de dados restaurado a partir de um backup 6.0 em uma instância 7.0 começará com a FCV definida como 6.0, restringindo o acesso a recursos somente 7.0 até que setFeatureCompatibilityVersion seja executado explicitamente.

Não atualize o FCV até que o banco de dados restaurado tenha sido validado – ele não pode ser revertido depois de definido.

Sempre que a incompatibilidade de versão for inevitável, é melhor restaurar os dados em um sistema com a mesma versão da fonte de backup, validar os dados e, em seguida, realizar um upgrade padrão no local.

Como automatizar e programar os backups do MongoDB de forma confiável?

Um backup do MongoDB que exige que alguém o inicie não é uma estratégia. É um hábito, e os hábitos sobre processos manuais de backup são frequentemente esquecidos durante emergências. A automação elimina o elemento humano dessa equação, mas só pode ser útil se sobreviver a situações que tornam os backups necessários – um servidor com carga pesada, uma rede não confiável ou um problema de infraestrutura.

Quais padrões de agendamento minimizam a carga e atendem ao seu RTO/RPO?

A programação de backups é sempre um compromisso entre a frequência e o impacto. Executar um mongodump em um primário com muita gravação a cada hora ajuda a atender a RPOs agressivos, mas também faz com que os backups concorram com o tráfego de produção pelo mesmo desempenho de E/S. A solução aqui não é fazer menos backups, mas abordar os backups de forma mais inteligente.

A regra número um é fazer o backup fora do horário de pico. Na maioria dos casos, isso significa o fim da noite ou o início da manhã no fuso horário dos principais usuários. No entanto, há algumas exceções que podem não ter um “período de silêncio”, como plataformas analíticas, aplicativos financeiros ou aplicativos distribuídos globalmente. Para essas situações, transferir o backup para um secundário replicado é uma etapa essencial, em vez de opcional.

A regra número dois é alinhar os tipos de backup e sua frequência. A execução de backups completos é cara – realizá-los diariamente ou semanalmente é mais do que suficiente na maioria dos casos. Os backups incrementais do MongoDB ou os processos de arquivamento de oplog preenchem as lacunas entre os backups completos – eles geralmente são realizados de hora em hora ou até mesmo continuamente sem nenhum impacto perceptível no desempenho.

Com isso em mente, podemos formar uma pequena tabela com as sugestões para diferentes opções de frequência de backup:

Como as ferramentas de orquestração, os scripts ou os cron jobs podem se tornar resilientes e idempotentes?

A condição de falha mais frequentemente observada em um processo de automação de backup e restauração do MongoDB desenvolvido internamente é um script que falha silenciosamente. Um trabalho do cron que existe com um código diferente de zero, não grava dados no destino e não alerta pode passar despercebido por dias ou até semanas. A primeira indicação de um trabalho desse tipo geralmente é a falha de uma operação de restauração que não consegue encontrar os dados que deveria restaurar.

A resiliência começa com o tratamento explícito de falhas. Todo script de backup deve verificar se a saída produzida não está vazia e se está dentro de um intervalo de tamanho esperado antes de ser encerrado com êxito. Um mongodump que é concluído, mas grava um arquivo quase vazio – o que acontece quando problemas de conexão interrompem a exportação no meio do caminho – deve ser tratado como uma falha, não como um sucesso. Os códigos de saída por si só não são suficientes.

A idempotência é importante quando os backups fazem parte de um pipeline de orquestração maior. Um trabalho de backup que é seguro para ser executado duas vezes sem se preocupar com a produção de artefatos duplicados ou conflitantes é muito mais fácil de recuperar se um agendador o disparar duas vezes devido a uma sobreposição de tempo ou lógica de nova tentativa. Isso cria a necessidade de ter uma saída de gravação para destinos nomeados exclusivamente – nomes de arquivos com carimbo de data/hora ou chaves de armazenamento de objetos – ao usar operações de movimentação atômica em vez de gravar diretamente no caminho final. Um backup parcialmente gravado que fica no caminho de destino (indistinguível de um completo) é um dos modos de falha mais insidiosos em todo o pipeline de backup e restauração do MongoDB.

Quando se trata de equipes com ferramentas de infraestrutura existentes, ferramentas como Ansible, Kubernetes CronJobs e Airflow podem oferecer ambientes de execução muito mais observáveis e controláveis em comparação com o cron bruto. Elas oferecem lógica de repetição integrada, histórico de execução e ganchos de alerta que o cron básico simplesmente não tem.

Como o senhor monitora os trabalhos de backup e alerta sobre falhas?

O monitoramento de um pipeline de backup do MongoDB não se limita apenas a rastrear se o trabalho foi executado no início. Um trabalho que é executado, mas que gera um backup corrompido ou incompleto, é muito pior do que um trabalho que falha em alto e bom som, porque somente a primeira situação cria uma sensação de falsa confiança. As métricas que valem a pena acompanhar nessas situações são:

• Os trabalhos de backup relatam sucesso, mas o tamanho do arquivo de saída caiu significativamente em comparação com a execução anterior – um sinal de captura parcial ou interrupção de conexão no meio do despejo.
• A duração do backup aumentou substancialmente sem um aumento correspondente no volume de dados – geralmente um indicador precoce de contenção de E/S ou atraso de replicação no secundário de origem.
• O local de armazenamento de destino não recebeu um novo backup dentro da janela esperada – captura casos em que o próprio agendador falhou ou o trabalho foi silenciosamente ignorado.
• Os resultados do teste de restauração, que devem ser executados em relação a um backup de amostra em uma cadência regular, mostram erros ou produzem um banco de dados que falha nas verificações de validação no nível do aplicativo.

Os alertas para essas condições precisam ser enviados para o mesmo pipeline de plantão que os alertas de infraestrutura, e não para uma caixa de entrada separada que é verificada apenas esporadicamente.

Como a segurança e a conformidade afetam as práticas de backup do MongoDB?

Um backup é uma duplicata dos dados críticos que é armazenada em um local fora do limite de segurança do banco de dados de produção. Todos e quaisquer controles de acesso, níveis de criptografia e auditoria devem ser pelo menos tão seguros – se não mais – quanto o banco de dados de produção.

Como os backups devem ser criptografados em repouso e em trânsito?

A criptografia em repouso garante que os arquivos de backup armazenados em disco, fita ou armazenamento de objetos sejam ilegíveis sem a chave de descriptografia correspondente.

Para arquivos de backup do MongoDB gravados no armazenamento de objetos, isso significa ativar a criptografia do lado do servidor no bucket de destino – AES-256 via AWS S3, Google Cloud Storage ou Azure Blob Storage – ou criptografar o arquivo de backup antes que ele saia do sistema de origem (com uma ferramenta como GPG). A chave de criptografia deve ser armazenada separadamente do próprio backup; uma chave armazenada junto com os dados que ela protege não oferece nenhuma proteção significativa.

A criptografia em trânsito garante que os dados de backup que se deslocam entre a instância do MongoDB, o agente de backup e o destino do armazenamento não possam ser interceptados.

O TLS deve ser aplicado em todas as conexões do mongodump usando o sinalizador –tls e a configuração do certificado correspondente. Para soluções de backup gerenciadas pela plataforma, como o Atlas Backup ou o Bacula Enterprise, a criptografia de transporte é gerenciada pela plataforma, mas ainda assim vale a pena verificar se a configuração impõe o TLS em vez de apenas suportá-lo como uma opção.

Como o senhor controla o acesso aos backups e aplica o privilégio mínimo?

Os arquivos de backup do MongoDB devem ter os mesmos controles de acesso que o banco de dados de produção. É importante tentar restringir ao máximo o número de usuários e aplicativos que podem ler/gravar ou excluir arquivos de backup usando as medidas a seguir:

• Os volumes ou buckets de armazenamento de backup devem negar o acesso público por padrão, com acesso concedido somente às contas de serviço específicas e às funções de IAM exigidas pelo pipeline de backup.
• O acesso humano aos arquivos de backup deve exigir aprovação explícita e ser registrado – os testes de restauração de rotina devem usar uma conta de restauração dedicada com privilégios mais baixos em vez de credenciais administrativas.
• As permissões de gravação e exclusão nos destinos de backup devem ser separadas – o sistema que cria os backups não deve ter a capacidade de excluí-los, o que limita o raio de ação de um agente de backup comprometido.
• Os registros de acesso ao backup devem ser mantidos independentemente dos próprios arquivos de backup, de modo que o histórico de acesso sobreviva mesmo que os backups sejam excluídos.
• O armazenamento entre contas ou entre projetos deve ser usado sempre que possível, garantindo que um ambiente de produção comprometido não conceda automaticamente acesso aos dados de backup.

Como as políticas de retenção e os requisitos de exclusão de dados afetam a estratégia de backup?

A política de retenção no backup segue em duas direções opostas. O aspecto operacional sugere uma preferência por um período de retenção de backup muito longo – quanto mais tempo o senhor puder restaurar, mais opções de backup haverá. O aspecto de conformidade (GDPR, CCPA, HIPAA) sugere uma preferência de exclusão – se um usuário solicitar que os dados sejam excluídos do sistema ativo, eles também deverão ser excluídos dos backups.

Isso cria uma tensão genuína para a estratégia de backup do MongoDB. Um backup imutável que não pode ser modificado ou excluído atende aos requisitos de proteção contra ransomware, mas entra em conflito com o direito de exclusão.

A solução prática é um modelo de retenção em camadas: backups de curto prazo que são mutáveis e sujeitos a solicitações de exclusão e backups de arquivamento de longo prazo que contêm dados anônimos ou pseudonimizados em que os registros individuais foram eliminados antes do arquivamento. Para implementar isso, é necessário que o pipeline de backup esteja ciente da classificação dos dados – quais coleções contêm dados pessoais e quais não contêm – em vez de tratar toda a saída de backup do MongoDB como equivalente.

Como os backups imutáveis e a proteção contra ransomware se aplicam ao MongoDB?

Os eventos de ransomware que têm como alvo a infraestrutura de backup se concentram na destruição das opções de recuperação antes da implantação da carga útil do ransomware. Se o invasor tiver a capacidade de excluir ou criptografar arquivos de backup, a principal defesa contra o pagamento de um resgate será destruída. Os backups imutáveis (arquivos que não podem ser modificados ou excluídos por um período específico) são uma das várias opções quando se trata de remover essa possibilidade.

Os mecanismos que impõem a imutabilidade na camada de armazenamento incluem:

• O bloqueio de objeto S3 no modo de conformidade impede a exclusão ou a substituição de objetos de backup durante o período de retenção configurado, mesmo pelo proprietário da conta ou por usuários administrativos.
• O armazenamento WORM (Write Once Read Many) em sistemas locais oferece proteção equivalente para a infraestrutura de backup baseada em fita e disco.
• Contas de nuvem ou unidades organizacionais separadas para o armazenamento de backup garantem que as credenciais comprometidas no ambiente de produção não concedam acesso à conta de backup.

Como os backups off-line ou air-gapped podem reduzir o impacto da violação?

Um backup air-gapped é desconectado física ou logicamente de qualquer rede que um invasor possa acessar a partir do ambiente de produção.

Para o backup do MongoDB, isso normalmente significa exportação periódica para fita, disco off-line ou um ambiente de nuvem sem acesso programático dos sistemas de produção. O ponto de recuperação de um backup air-gapped é limitado pela frequência com que a lacuna é atravessada para gravar novos dados – transferências diárias ou semanais são comuns – fazendo com que as cópias air-gapped sejam as mais apropriadas para atuar como uma camada de recuperação de último recurso, em vez de ser o principal condutor do fluxo de trabalho de recuperação do banco de dados.

A troca aqui também é deliberada: um backup mais lento e menos frequente que sobrevive a um comprometimento total da infraestrutura é mais valioso no pior cenário do que um backup contínuo que é criptografado junto com todo o resto.

Quais são as práticas recomendadas para backups de produção do MongoDB?

As seções acima abrangem estratégias, ferramentas e procedimentos individuais isoladamente. As práticas recomendadas são o que as mantém unidas em um ambiente de produção – os padrões mínimos, os requisitos de documentação e as métricas de integridade que garantem que uma arquitetura de backup do MongoDB permaneça confiável ao longo do tempo em vez de se degradar silenciosamente à medida que a infraestrutura e as equipes mudam e evoluem.

Quais políticas mínimas devem ser implementadas em cada implantação de produção?

A política mínima aceitável de backup do MongoDB depende da criticidade da implementação. Um ambiente de desenvolvimento e um banco de dados de produção regulamentado não requerem os mesmos controles, mas ambos exigem algo deliberado e testado. A tabela a seguir define os requisitos de linha de base por nível de implementação:

Dois requisitos se aplicam universalmente, independentemente do nível. Primeiro, todo backup deve ser armazenado em um local separado da instância que protege – um backup que reside no mesmo disco que o banco de dados do qual faz backup não é um backup, mas uma cópia. Em segundo lugar, toda estratégia de backup deve incluir pelo menos uma restauração testada antes de ser considerada operacional. Uma configuração que nunca foi restaurada com sucesso é uma suposição, não uma política.

Como o senhor documenta os procedimentos de backup e restauração para as equipes de plantão?

A documentação de backup que existe apenas na cabeça do engenheiro que construiu o pipeline falha no momento em que esse engenheiro se torna inacessível, o que geralmente é o momento exato em que ele é mais necessário. Os livros de execução devem ser escritos para o engenheiro que nunca tocou nesse sistema antes, pois é totalmente possível que ele seja o responsável pela execução de uma restauração às 2h da manhã após um incidente.

A documentação eficaz de backup e restauração do banco de dados MongoDB inclui:

• A localização de cada destino de backup – nomes de buckets de armazenamento, caminhos e métodos de acesso, com instruções sobre como se autenticar neles em um ambiente limpo
• Os comandos exatos necessários para iniciar uma restauração, incluindo sinalizadores, cadeias de conexão e quaisquer variáveis de ambiente que devam ser definidas antes do início da restauração
• O resultado esperado de uma restauração bem-sucedida – como é uma inicialização saudável do mongod, quais coleções devem ser verificadas e como validar se as contas de usuário e os índices estão intactos
• Modos de falha conhecidos e suas resoluções – erros de incompatibilidade de versão, sintomas de restauração parcial e o que fazer se o backup mais recente estiver corrompido
• Contatos de escalonamento – para quem ligar se o procedimento documentado não resolver o incidente, incluindo os contatos de suporte do fornecedor para Atlas, Bacula ou qualquer outra plataforma em uso

A documentação deve estar em um local acessível durante uma interrupção da infraestrutura, não exclusivamente em um wiki que seja executado na mesma plataforma que acabou de cair.

Quais métricas e SLAs devem ser monitorados para a integridade do backup?

A integridade do backup é medida usando várias métricas operacionais. Um pipeline de backup que está tecnicamente em execução, mas que produz resultados degradados – arquivos menores do que o esperado, duração crescente, janelas perdidas – está falhando lentamente, e essa falha só se tornará visível no pior momento possível. As métricas a seguir fornecem um alerta antecipado:

Essas métricas devem ser rastreadas na mesma plataforma de observabilidade usada para o monitoramento da infraestrutura, e não em uma planilha, nem revisadas manualmente. O alerta automatizado sobre violações de limites garante que um pipeline de backup do MongoDB degradado seja tratado com a mesma urgência que um serviço de produção degradado, em vez de ser descoberto após o fato.

Principais conclusões

• Sua topologia de implementação no MongoDB (autônoma, conjunto de réplicas ou cluster sharded) determina quais métodos de backup estão disponíveis para o senhor.
• Defina seu RTO e RPO antes de selecionar qualquer ferramenta – esses são os requisitos que todas as outras decisões devem atender.
• O MongoDB Atlas Backup é a opção gerenciada mais fácil; o Percona Backup for MongoDB (PBM) é a melhor alternativa auto-hospedada.
• O armazenamento de backup deve ser criptografado, com controle de acesso e imutável – trate-o com o mesmo rigor de segurança que a produção.
• Monitore os trabalhos de backup quanto ao tamanho da saída e à variação da duração, e não apenas se foram concluídos.
• Um backup que nunca foi restaurado é uma suposição – teste e documente seus procedimentos de restauração regularmente.

Conclusão

O backup e a restauração do MongoDB não é um processo que pode ser ativado uma vez e imediatamente esquecido – é uma disciplina operacional contínua que abrange a seleção de ferramentas, o agendamento, a segurança, a documentação e os testes regulares. A estratégia certa para uma instância de desenvolvimento autônoma não se parece em nada com a estratégia certa para um cluster de produção fragmentado que atende a dados regulamentados, e a lacuna entre esses dois contextos é a origem da maioria das falhas de backup.

As organizações que se recuperam de forma limpa de eventos de perda de dados não são as que têm as ferramentas de backup mais sofisticadas – são as que testaram seus procedimentos de restauração antes de precisar deles, documentaram esses procedimentos para as pessoas que não estavam na sala quando o sistema foi construído e trataram a integridade do backup como uma métrica operacional de primeira classe em vez de uma reflexão tardia.

Perguntas frequentes

Os backups do MongoDB podem ser consistentes em arquiteturas de microsserviços?

Para obter um backup consistente entre os microsserviços, cada um mantendo seu próprio banco de dados MongoDB, é necessário coordenar os carimbos de data/hora dos instantâneos em todos os serviços simultaneamente – um problema de orquestração não trivial. Na prática, a maioria das equipes aceita a consistência eventual entre os backups no nível do serviço e confia na lógica de reconciliação no nível do aplicativo para lidar com as lacunas, em vez de tentar fazer um único backup atômico entre serviços.

Como fazer backup de implementações multilocatário do MongoDB com segurança?

As implementações multilocatário que isolam os locatários por banco de dados podem ser copiadas seletivamente usando o sinalizador –db do mongodump, permitindo a restauração por locatário sem tocar nos dados de outros locatários. As implementações que colocam os dados do locatário em coleções compartilhadas exigem lógica de exportação no nível do aplicativo para obter o mesmo isolamento, pois o mongodump opera no nível da coleção e não pode filtrar nativamente por campo do locatário.

Como as implementações do MongoDB em contêineres e baseadas em Kubernetes alteram a estratégia de backup?

As implantações do MongoDB baseadas em Kubernetes – normalmente gerenciadas por meio do MongoDB Kubernetes Operator ou de um StatefulSet – introduzem uma infraestrutura efêmera que torna as suposições de instantâneos do sistema de arquivos não confiáveis. A abordagem recomendada é usar backups lógicos via mongodump acionados como Kubernetes CronJobs ou implantar o Percona Backup for MongoDB junto com o cluster, que foi projetado para operar nativamente em ambientes em contêineres com suporte a volume persistente.