Chat with us, powered by LiveChat
Solicitar Orçamento
WW +41 21 641 6080 | EUA +1 800 256 0192 | CA +1 800 935 0725 | FR +33 261 880008 | UK +44 808 1890445
Fale Conosco
Home > Backup de dados corporativos > Ferramentas de Backup de Dados Corporativos > Solução de backup do MongoDB de nível empresarial para implantações em grande escala

Solução de backup do MongoDB de nível empresarial para implantações em grande escala

Realizar backups e restaurações granulares do MongoDB em servidores, conjuntos de réplicas e clusters fragmentados

Bancos de dados NoSQL, como o MongoDB, são capazes de lidar com volumes enormes de tráfego e dados graças a um design escalável que os torna uma solução inestimável para empresas que gerenciam milhões de usuários simultâneos.

Dito isso, fazer o backup de um cluster NoSQL, por si só, apresenta uma série de desafios de consistência de dados que as soluções de backup tradicionais não conseguem superar, uma vez que copiar arquivos brutos do banco de dados enquanto o servidor está em execução pode resultar em um artefato inconsistente ou impossível de ser restaurado, pois os arquivos podem sofrer alterações entre as leituras

O plug-in de backup e restauração do MongoDB do Bacula Enterprise se integra diretamente ao mecanismo do MongoDB e automatiza backups lógicos em um banco de dados ativo para servidores autônomos e conjuntos de réplicas, sem interromper as gravações. No entanto, no caso de clusters fragmentados, é necessário primeiro atender a vários pré-requisitos para automatizar o backup lógico.

Além disso, a arquitetura isolada de cinco módulos do Bacula limita o alcance do dano quando seu banco de dados MongoDB é violado e proporciona recuperação rápida quando a arquitetura é combinada com segmentação de rede, credenciais exclusivas e TLS mútuo.

Baixar versão de avaliação

Principais benefícios da solução de backup e restauração do MongoDB

  • Backups consistentes de bancos de dados MongoDB ativos – O plugin MongoDB do Bacula evita os artefatos inconsistentes gerados pela cópia direta de arquivos, ao acionar diretamente a própria ferramenta mongodump do MongoDB. Para servidores autônomos, isso gera um instantâneo lógico do conteúdo do banco de dados. Já para conjuntos de réplicas, o plugin gera uma cadeia de recuperação totalmente consistente ao adicionar metadados do oplog ao dump.
  • Backup lógico coordenado para clusters MongoDB fragmentados – O plug-in MongoDB do Bacula oferece às implantações de clusters fragmentados uma trajetória de backup lógico coordenada, sem a necessidade de scripts de orquestração personalizados. Ele captura os dados da aplicação por meio do mongos, juntamente com metadados de roteamento para a recuperação lógica dos dados da aplicação. No entanto, a consistência entre os fragmentos depende da paralisação do balanceador e da interrupção das gravações durante o backup.
  • Recuperação granular do MongoDB no nível do banco de dados e da coleção – Com o MongoDB Plugin, você pode filtrar e recuperar bancos de dados específicos ou coleções individuais sem precisar restaurar todo o cluster de bancos de dados. Com isso, os tempos de restauração tornam-se significativamente mais curtos, e o risco de sobrescrever dados íntegros junto com os danificados é significativamente reduzido. *A restauração granular no nível da coleção se aplica a artefatos lógicos completos e não pode ser combinada com a reprodução do oplog, o que significa que não é possível restaurar uma coleção específica para um ponto preciso no tempo em uma única operação.
  • Recuperação em um momento específico para conjuntos de réplicas do MongoDB – Como uma migração de esquema mal executada ou a exclusão acidental de uma coleção podem, infelizmente, apagar horas de gravações, o plug-in do MongoDB do Bacula registra segmentos do log de operações em cada tarefa incremental e diferencial para fornecer uma recuperação precisa em um momento específico (PITR). O parâmetro replay_to permite interromper a reprodução em qualquer ponto dentro da janela de oplog disponível. Esse recurso permite recuperar o conjunto de réplicas para o estado protegido mais próximo antes da ocorrência do incidente.

Principais recursos do plug-in do Bacula para o MongoDB

Integridade dos dados e segurança de acesso

  • Validação da continuidade da cadeia antes da restauração — Sempre que uma restauração é acionada, o MongoDB Plugin verifica automaticamente a integridade da soma de verificação, a identidade da cadeia, o vínculo com o pai, a impressão digital da fonte e os limites do oplog. Se algum elemento estiver faltando ou não corresponder, o plugin bloqueará a restauração antes que ela chegue ao banco de dados.
  • Suporte à autenticação TLS e MONGODB-X509 — O plug-in do MongoDB se conecta a ambientes MongoDB seguros sem comprometer os padrões de autenticação. Ele oferece suporte a TLS tanto na conexão do driver Java quanto na camada das Ferramentas de Banco de Dados do MongoDB; ao SCRAM para autenticação baseada em senha; e ao MONGODB-X509 para autenticação baseada em certificado, na qual o nome de usuário do MongoDB deve corresponder exatamente ao assunto do certificado do cliente. Além disso, as credenciais de conexão são gerenciadas por meio de um `password_file` para isolá-las dos logs de tarefas e da saída de configuração.
  • Metadados de manifesto e cadeia para auditabilidade – Cada tarefa de backup do MongoDB produz um registro completo e verificável do que foi copiado, incluindo a versão de origem, a topologia, os bancos de dados selecionados e as somas de verificação. Esses arquivos de metadados acompanham os artefatos de backup no catálogo do Bacula, na pasta /@mongodb, e estão disponíveis para auditoria e planejamento de restauração sem interferir no ambiente em produção.

Infraestrutura de backup adaptável

  • Suporte a backup para múltiplas topologias — O plug-in oferece suporte aos três tipos de implantação do MongoDB (ou seja, servidores autônomos, conjuntos de réplicas e clusters fragmentados), e o comportamento do backup se ajusta automaticamente à topologia, sem qualquer tipo de intervenção manual. Servidores autônomos recebem um backup lógico completo por meio do mongodump. Conjuntos de réplicas recebem um backup completo que inicia uma cadeia de recuperação, seguido por tarefas incrementais e diferenciais que registram segmentos do oplog. Clusters fragmentados são copiados por meio do mongos, com metadados de roteamento capturados juntamente com os dados da aplicação.
  • Relatórios de simulação para backup e restauração – O comando dry_run=yes gera um relatório completo do que o backup ou a restauração realizaria, sem gravar ou alterar nada, de modo que quaisquer erros de configuração ou problemas de compatibilidade sejam identificados muito antes de a tarefa ser executada em um ambiente produtivo. Para o backup, isso valida a conexão, a topologia, as permissões, a compatibilidade da ferramenta e o espaço de trabalho disponível.

Conjunto completo de recursos do plug-in do MongoDB

A recuperação em um ponto específico no tempo, juntamente com os outros recursos listados anteriormente, é apenas uma parte do panorama geral do que o plug-in pode oferecer para o backup e a recuperação do seu banco de dados MongoDB. Abaixo, você pode ver a ampla gama de recursos que o plug-in oferece a grandes empresas com milhões de usuários simultâneos.

Recursos de backup

  • Backups completos, incrementais e diferenciais — O plug-in oferece suporte a todos os três níveis de tarefa. Os conjuntos de réplicas obtêm cadeias verdadeiras baseadas no oplog; e as implantações autônomas e fragmentadas obtêm artefatos lógicos do tipo completo em todos os níveis.
  • Backup lógico via mongodump — Cada backup é um artefato lógico produzido pela própria ferramenta mongodump do MongoDB, que mostra o conteúdo real do banco de dados no momento em que a tarefa foi executada.
  • Filtragem de bancos de dados e coleções — Filtros de inclusão e exclusão permitem delimitar qualquer tarefa de backup a bancos de dados específicos ou coleções individuais.
  • Captura de metadados de roteamento de cluster fragmentado — Para implantações fragmentadas, o plug-in registra a associação aos fragmentos e os metadados de roteamento juntamente com os dados da aplicação para dar suporte ao planejamento de restauração no nível da aplicação por meio do mongos. Isso abrange apenas a recuperação lógica dos dados da aplicação.

Recursos de restauração

  • Recuperação em um ponto específico no tempo para conjuntos de réplicas — O parâmetro replay_to interrompe a reprodução do oplog em qualquer ponto dentro da janela de oplog disponível. A precisão da recuperação depende da retenção do oplog, da frequência da tarefa e do último limite de cadeia capturado com sucesso.
  • Restauração por streaming no mongorestore — Cargas úteis completas de arquivos são transmitidas diretamente do armazenamento do Bacula para o mongorestore sem a necessidade de gravar primeiro os arquivos de dump completos no disco local.
  • Restauração entre hosts — O plug-in transmite artefatos para o mongorestore em qualquer destino válido, o que permite testes em sandbox e migrações de cluster. No entanto, a portabilidade do formato lógico não garante que todas as combinações de versão do servidor, versão das Ferramentas de Banco de Dados, FCV, definição de índice ou recurso de coleção possam ser restauradas.
  • Controle da estratégia de conflito — O parâmetro conflict_strategy controla como o plug-in lida com os dados existentes no destino da restauração. Você pode definir conflict_strategy=fail por meio da sessão de restauração do Bacula para restaurações de validação e conflict_strategy=drop apenas quando for seguro substituir os dados existentes no destino.

Segurança

  • Suporte à conexão TLS – O TLS é suportado tanto na conexão do driver Java quanto na camada das Ferramentas de Banco de Dados do MongoDB.
  • Autenticação SCRAM e MONGODB-X509 – O plug-in também suporta a autenticação SCRAM baseada em senha e a autenticação MONGODB-X509 baseada em certificado, na qual o nome de usuário do MongoDB deve corresponder exatamente ao assunto do certificado do cliente.
  • Isolamento de credenciais por meio do password_file – As credenciais de conexão são gerenciadas por meio de um password_file. Elas não são incorporadas em URIs, o que as mantém separadas dos logs de tarefas e da saída de configuração.
  • Usuário de backup com privilégios mínimos – O plug-in foi projetado para ser executado sob um usuário de backup dedicado do MongoDB, ao qual são concedidos apenas os privilégios necessários para o modo de backup selecionado.

Plugin de backup e restauração do MongoDB: comparação de topologias

O plugin do MongoDB ajusta seu comportamento de backup com base na topologia de implantação à qual está conectado. A tabela abaixo mostra o que cada topologia suporta, para que seja mais fácil para você planejar sua estratégia de backup e suas expectativas de recuperação antes da execução da primeira tarefa.

 

Recursos Autônomo Conjunto de réplicas Cluster fragmentado
Backup completo Sim Sim Sim
Incremental / Diferencial Artefatos lógicos do tipo completo (sem cadeia de oplog) Cadeia verdadeira baseada em oplog Recuperação de dados de aplicativos
Recuperação em um ponto no tempo (PITR) Não Sim — via replay_to Não
Captura de oplog Não Sim — tarefas incrementais e diferenciais Não
Validação da continuidade da cadeia Não Sim — antes de cada restauração Não
Captura de metadados de roteamento Não Não Sim — associação a shards e configuração de roteamento
Proteção do balanceador necessária Não Não Sim
(1) o balanceador deve estar parado; (2) migrações de blocos desativadas; (3) gravações impedidas durante o dump
Destino da conexão Mongod primário Primário gravável (URI do conjunto de réplicas preferencial) Somente mongos
Método de restauração Restauração lógica completa via mongorestore Repetição da cadeia validada via mongorestore Restauração do aplicativo por meio do mongos com preparação de roteamento

Como o Bacula protege os dados de backup do MongoDB contra ameaças cibernéticas?

Para combater os cibercriminosos e proteger as organizações contra ransomware, o Bacula Enterprise — que conta com a confiança de grandes organizações como a NASA, a Marinha dos EUA e a Força Aérea dos EUA — protege os dados de backup do MongoDB por meio da integração direta com destinos de armazenamento imutáveis e em conformidade com o padrão WORM, de modo a impedir que um invasor com acesso às credenciais modifique, reclassifique ou, pior ainda, apague os dados até que o período de retenção configurado expire.

Arquitetura e Controle de Acesso

  • Arquitetura isolada de cinco módulos — Na arquitetura de cinco módulos do Bacula, o Daemon de Arquivos (cliente), o Director, o Daemon de Armazenamento, o Console e o banco de dados do Catálogo operam como componentes separados. Esse tipo de separação limita o alcance dos danos causados por um componente comprometido, especialmente quando combinado com segmentação de rede, credenciais exclusivas por componente, TLS mútuo e controles de acesso com o mínimo de privilégios.
  • Privilégios restritos do Daemon de Arquivos (cliente) — Os administradores podem limitar exatamente de quais diretórios um cliente pode fazer backup, para quais pode restaurar e em quais pode executar scripts, por meio das diretivas AllowedBackupDirectories, AllowedRestoreDirectories e AllowedScriptDirectories. O Daemon de Arquivos também pode ser executado no modo somente leitura, a fim de impedir qualquer modificação não autorizada a partir desse sistema.
  • Controle de Acesso Baseado em Função — O Bacula oferece suporte a um Controle de Acesso Baseado em Função (RBAC) granular por meio de Listas de Controle de Acesso (ACLs) especializadas que restringem com precisão o que um usuário do console pode visualizar e modificar. Essa segurança é aplicada nas camadas de controle JobACL, CommandACL, PoolACL e ScheduleACL.
  • Autenticação multifatorial — O acesso ao console suporta autenticação multifatorial (MFA) baseada em TOTP e está em conformidade com a RFC 6238, além da autenticação padrão por senha e TLS. O acesso à interface gráfica da Web suporta separadamente a autenticação por senha de uso único, que também inclui opções de validação biométrica por smartphone.

Imutabilidade e integridade dos dados

  • Proteção de volumes gerenciada pelo Bacula — O Bacula define um atributo “Somente Adição” (Append-Only) em volumes baseados em arquivos durante sua primeira tarefa de backup para evitar a perda de dados por sobrescrita. Assim que um volume é marcado como “Cheio”, um sinalizador de imutabilidade pode impedir que ele seja remarcado ou reutilizado até que seu período de proteção expire. Esses controles são aplicados na camada de aplicação e sua resistência a um invasor depende dos privilégios do sistema operacional, do suporte do sistema de arquivos, dos privilégios do Daemon de Armazenamento e da configuração de retenção.
  • Imutabilidade imposta por hardware e na nuvem — Para uma imutabilidade que resista até mesmo ao acesso privilegiado no nível do sistema operacional, o Bacula se integra à imutabilidade controlada por dispositivos no NetApp SnapLock, DataDomain RetentionLock e HPE StoreOnce, bem como ao modo de conformidade WORM e ao bloqueio de objetos no AWS S3, Azure e Google Cloud Storage. Ao contrário dos controles na camada de aplicação, esses são aplicados no nível do hardware ou do provedor de nuvem e não podem ser substituídos por credenciais do sistema operacional.
  • Verificação de tarefas e verificação de integridade baseada em hash — O Bacula pode detectar corrupção silenciosa calculando assinaturas SHA256 ou SHA512 dos dados dos arquivos e comparando o estado atual de um volume com seu registro no Catálogo. Para validação de integridade adversária, observe que essa comparação depende de o Catálogo permanecer intacto junto com os volumes de backup.
  • Armazenamento isolado (Air-Gapped) — O Bacula Enterprise opera inteiramente offline em ambientes totalmente isolados, sem dependência da internet. O Director, os Daemons de Armazenamento e os Daemons de Arquivos podem ser distribuídos por redes segregadas, de modo que os dados de backup do MongoDB permaneçam inacessíveis a ameaças externas, mesmo no caso de uma violação no nível da rede.

Criptografia

  • Comunicações criptografadas — Os daemons do Bacula realizam a autenticação usando o SCRAM-SHA-256. A criptografia TLS deve ser ativada para todas as comunicações de rede em uma implantação segura e é suportada em todos os componentes do Bacula.
  • Conformidade com a norma FIPS 140-3 — O Bacula Enterprise oferece conformidade com a norma FIPS 140-3 por meio de seu Módulo Criptográfico, que utiliza o OpenSSL-FIPS e é certificado em diversas plataformas. O módulo pode ser utilizado em todos os componentes do Bacula.
  • Criptografia de dados em repouso — O Daemon de Armazenamento pode criptografar um destino de armazenamento inteiro de uma só vez, independentemente da fonte dos dados. Os administradores também podem configurar a criptografia separadamente para clientes individuais.

Detecção de ameaças

  • B Detecção de ransomware pelo BGuardian — O módulo de análise de segurança automatizada do Bacula, o BGuardian, verifica a solidez da configuração, o uso de criptografia, padrões de adulteração de backups e dezenas de outros indicadores de fortalecimento de segurança em todo o ambiente, gerando relatórios e alertas persistentes à medida que os problemas são detectados.
  • Verificação de malware e antivírus — O Bacula oferece defesa automatizada contra ameaças ao integrar um plug-in antivírus com o ClamAV para verificar se há vírus nos arquivos copiados durante as tarefas de verificação pós-backup.

O que você ganha ao implantar o Bacula Enterprise?

Cada implantação do Bacula Enterprise oferece os seguintes recursos nas áreas de recuperação, backup, preços e administração da plataforma.

Recursos eficientes de backup

  • Compressão adaptativa – Os algoritmos de compressão são configuráveis por tarefa, de modo que os administradores possam ajustar a compressão com base no tipo de dados e nos recursos disponíveis.
  • Backups completos, diferenciais e incrementais – O Bacula oferece suporte aos níveis de backup completo, diferencial e incremental. Uma estratégia típica começa com um backup completo, seguido por backups incrementais, o que evita a execução repetida de grandes backups completos em uma programação fixa.
  • Backups completos virtuais progressivos – O Bacula pode combinar um backup completo existente com seus incrementais subsequentes para criar um novo backup completo sintético sem precisar entrar em contato com o cliente novamente. Em vez disso, o processo lê os dados do armazenamento de backup existente. A diretiva Backups To Keep pode repetir essa consolidação de forma contínua.
  • Spooling em disco antes da gravação em fita – O Bacula pode gravar os dados de backup em um spool de disco antes de enviá-los para a fita como um fluxo contínuo. Isso ajuda a evitar o movimento de partida e parada da fita que pode ocorrer quando os dados chegam muito lentamente para manter a unidade gravando continuamente. O problema é particularmente comum em backups incrementais e diferenciais, que tendem a produzir fluxos de dados menores e menos consistentes do que os backups completos.
  • Transferências com Consciência de Largura de Banda – Apenas os dados alterados são transferidos pela rede após o backup inicial. Isso mantém o tráfego de rede mais baixo, sem exigir limitação manual da largura de banda ou soluções alternativas de agendamento.
  • Agendamento Frequente de Backups – As tarefas de backup podem ser executadas a cada poucos minutos, em vez de uma vez por dia, reduzindo a janela de perda potencial de dados de horas para minutos.
  • Proteção contínua de dados – O aplicativo cdp-client monitora as alterações nos arquivos e os copia para um diretório de spool à medida que elas ocorrem. O FileDaemon, então, envia esses dados para uma tarefa regular de backup do Bacula em intervalos definidos, de modo que as alterações possam ser capturadas em segundos ou minutos, em vez de esperar pelo próximo backup programado.

Recursos de recuperação ultrarrápida

  • Restauração completa do sistema (bare-metal) – O Bacula Enterprise pode recuperar um servidor inteiro, incluindo o sistema operacional, os aplicativos, a configuração e os dados, sem a necessidade de uma instalação manual prévia do sistema operacional.
  • Recuperação de dados multiplataforma – Os dados de backup podem ser recuperados em um sistema operacional diferente do original. Isso oferece às equipes mais flexibilidade durante substituições de hardware, migrações ou outros cenários de recuperação.
  • Validação automatizada da restauração – Testes automatizados podem verificar se os dados de backup são recuperáveis sem que seja necessário que um administrador execute um processo de validação separado.
  • Replicação geográfica de backup – O Bacula mantém uma única cópia de backup por padrão. Para criar cópias adicionais em outros locais, os administradores podem configurar tarefas de cópia ou migração. Uma configuração típica pode manter a cópia primária no armazenamento local, criar uma segunda cópia em outro tipo de mídia, como armazenamento em nuvem, e, em seguida, enviar uma terceira cópia para um local externo ou isolado da rede. Essa configuração ajuda a garantir que uma interrupção em todo o local não comprometa todas as cópias de recuperação disponíveis.

Controle de custos e licenciamento previsível de backup

  • Desduplicação em nível de bloco – Blocos de dados repetidos são armazenados apenas uma vez no catálogo de backup, o que reduz o consumo de armazenamento sem exigir alterações nas políticas ou programações de backup.
  • Fluxos de trabalho de armazenamento em camadas – Os dados de backup podem ser movidos automaticamente entre camadas de armazenamento à medida que envelhecem. Pontos de recuperação recentes podem permanecer em armazenamento mais rápido, enquanto backups mais antigos são transferidos para destinos de menor custo.
  • Licenciamento independente de volume – Os custos de licenciamento não aumentam à medida que os dados protegidos crescem. As equipes podem expandir seu ambiente de backup sem arcar com taxas de licença mais altas.
  • Custos previsíveis – Os preços fixos facilitam o planejamento dos orçamentos de infraestrutura, sem cobranças variáveis de licenciamento vinculadas ao crescimento do armazenamento ou a mudanças na carga de trabalho.
  • Preços independentes da carga de trabalho – O tamanho dos bancos de dados, o número de servidores e a quantidade de armazenamento protegido não afetam os custos de licenciamento.
  • Custos mais baixos em escala – Ambientes grandes ou em rápido crescimento podem adicionar dados protegidos sem aumentar as taxas de licença. A economia pode se tornar mais significativa à medida que os volumes de dados crescem, em comparação com modelos de licenciamento baseados em capacidade.

Gerenciamento e Administração de Backups

  • Interface Dupla – O BWeb oferece um console gráfico para o gerenciamento e monitoramento diários das tarefas. O Bconsole (agente de usuário) proporciona aos operadores controle total via linha de comando para a criação de scripts, automação e configuração avançada.
  • Escalabilidade sem Limites – A mesma arquitetura de plataforma gerencia ambientes que vão desde alguns poucos servidores até implantações que chegam a milhares, tudo sob um único plano de gerenciamento.
  • Descoberta automática de recursos – A plataforma analisa a infraestrutura para identificar e catalogar destinos de backup automaticamente. A cobertura de proteção permanece atualizada à medida que o ambiente cresce.
  • Relatórios detalhados – Relatórios programados abrangem resultados de tarefas, tendências de capacidade, status de conformidade e desempenho operacional em uma cadência definida.
  • Integração com sistemas externos – O Bacula se conecta a ferramentas de monitoramento, sistemas de tickets de TI e serviços de diretório, sem a necessidade de desenvolvimento personalizado obrigatório.

Perguntas frequentes

Como fazer backup de um banco de dados MongoDB em produção sem tempo de inatividade?

Para servidores autônomos e conjuntos de réplicas, o plug-in Bacula Enterprise MongoDB executa o mongodump em um banco de dados em produção sem interromper as leituras ou gravações, e o banco de dados permanece totalmente operacional durante as tarefas de backup. No entanto, a garantia de ausência de tempo de inatividade não se aplica a backups de clusters fragmentados, uma vez que esses backups exigem (1) interromper o balanceador de fragmentos por meio de sh.stopBalancer(), (2) desativar as migrações programadas de fragmentos e (3) impedir gravações e transformações de esquema durante o período do dump. É de se esperar que as gravações sejam interrompidas durante a janela de backup. Faça o backup do conjunto de réplicas do servidor de configuração primeiro e, em seguida, capture cada conjunto de réplicas de fragmento o mais próximo possível em termos de tempo.

Qual é a diferença entre um backup lógico e um físico no MongoDB?

Um backup lógico usa o `mongodump` para exportar os documentos, índices e esquemas do banco de dados para arquivos BSON portáteis. Esses arquivos são independentes do mecanismo de armazenamento subjacente e geralmente podem ser restaurados em um servidor diferente, embora as restaurações entre versões dependam da compatibilidade entre as versões do MongoDB, da versão das Ferramentas de Banco de Dados e da Versão de Compatibilidade de Recursos (FCV). Portanto, nem todas as combinações têm garantia de funcionamento. Um backup físico, por outro lado, copia os arquivos de dados brutos do disco, o que é muito mais rápido para conjuntos de dados muito grandes, mas vincula o artefato ao mecanismo de armazenamento e à versão originais.

Como funciona a recuperação em um ponto no tempo (PITR) para conjuntos de réplicas do MongoDB?

A recuperação em um ponto no tempo está disponível exclusivamente para conjuntos de réplicas. Quando é necessária uma restauração, o parâmetro `replay_to` interrompe a reprodução do oplog em qualquer ponto dentro da janela de oplog disponível e recupera o conjunto de réplicas para o estado protegido mais próximo dentro dessa janela antes que um incidente ocorra. Servidores autônomos e clusters fragmentados não oferecem suporte à PITR por meio deste plug-in, pois não fornecem uma cadeia de recuperação do oplog da mesma forma que os conjuntos de réplicas. Se você precisar recuperar uma coleção específica para um ponto no tempo, o caminho recomendado é restaurar primeiro a cadeia completa do conjunto de réplicas em um destino que não seja de produção e, em seguida, extrair e reconciliar os dados necessários no nível do aplicativo.

É possível restaurar uma única coleção do MongoDB sem recuperar todo o banco de dados?

Sim. O plug-in MongoDB do Bacula suporta filtros de inclusão e exclusão no nível do banco de dados e da coleção, de modo que uma tarefa de restauração possa ter como alvo uma coleção específica sem afetar o restante do banco de dados. Isso mantém as janelas de restauração curtas e minimiza o risco de sobrescrever dados íntegros junto com os dados danificados que você precisa substituir. Uma restauração completa do banco de dados está disponível quando necessário, mas nunca é a única opção.

Além disso, observe que a restauração granular no nível da coleção se aplica a artefatos lógicos completos e não pode ser combinada com a reprodução do oplog, o que significa que a recuperação em um ponto no tempo opera sempre no escopo completo do conjunto de réplicas. Se você precisar de ambas as opções, certifique-se de restaurar primeiro a cadeia completa do conjunto de réplicas em um destino fora de produção e, em seguida, extrair os dados necessários no nível da aplicação.

Por que usar o plug-in MongoDB do Bacula em vez de executar o mongodump manualmente?

O mongodump, por si só, é uma ferramenta capaz para uma única exportação lógica. Dito isso, sua limitação é que ele não oferece tudo (agendamento centralizado, retenção automatizada, validação de checksum, metadados da cadeia de recuperação e a lista continua) o que vem após o dump. O plug-in MongoDB do Bacula Enterprise integra o mongodump e o mongorestore ao mecanismo de políticas do Bacula, de modo que cada tarefa de backup do MongoDB seja adequadamente agendada, catalogada, validada e recuperável a partir do mesmo console que gerencia o restante da sua infraestrutura.

Mais ajuda sobre backup do MongoDB: