Menu Docs

Página inicial do DocsDesenvolver aplicaçõesManual do MongoDB

Métodos de backup do MongoDB

Nesta página

  • Fazer backup com o Atlas
  • Faça backup com o MongoDB Cloud Manager ou Ops Manager
  • Faça backup copiando arquivos de dados subjacentes
  • Faça backup com mongodump

Ao implementar o MongoDB em produção, você deve ter uma estratégia para capturar e restaurar backups no caso de eventos de perda de dados.

O MongoDB Atlas, a opção de serviço MongoDB hospedado na nuvem, oferece dois métodos totalmente gerenciados para backups:

  1. Backups em nuvem, que utilizam a funcionalidade nativa de snapshot do provedor de serviços de nuvem da implementação para oferecer opções robustas de backup. Os backups na nuvem oferecem:

  2. Legacy Backups (Obsoleto), que utilizam cópias de segurança incrementais de dados em sua implantação.

O MongoDB Cloud Manager é um serviço de backup, monitoramento e automação hospedado para o MongoDB. O MongoDB Cloud Manager oferece suporte ao backup e à restauração de conjuntos de réplicas do MongoDB e clusters fragmentados a partir de uma interface gráfica do usuário.

O MongoDB Cloud Manager oferece suporte ao backup e à restauração de implementações MongoDB.

O MongoDB Cloud Manager faz backup contínuo de conjunto de réplicas e clusters fragmentados do MongoDB lendo os dados de registro de sua implementação do MongoDB. O MongoDB Cloud Manager cria snapshots de seus dados em intervalos definidos e também pode oferecer recuperação de ponto no tempo de conjuntos de réplicas do MongoDB e clusters fragmentados.

Dica

snapshots de cluster fragmentados são difíceis de alcançar com outros métodos de backup MongoDB.

Para começar a usar o MongoDB Cloud Manager Backup, inscreva-se no MongoDB Cloud Manager. Para obter documentação sobre o MongoDB Cloud Manager, consulte a documentação do MongoDB Cloud Manager.

Com o Ops Manager, os assinantes do MongoDB podem instalar e executar o mesmo software central que alimenta o MongoDB Cloud Manager em sua própria infraestrutura. O Ops Manager é uma solução local que tem funcionalidade semelhante à do MongoDB Cloud Manager e está disponível com assinaturas Enterprise Advanced.

Para obter mais informações sobre o gerente de operações, consulte a página MongoDB Enterprise Advanced e o Manual do gerente de operações.

Observação

Considerações para mecanismos de armazenamento criptografados usando AES256-GCM

Para mecanismos de armazenamento criptografados que utilizam o modo de criptografia AES256-GCM, o AES256-GCM exige que cada processo utilize um valor de bloco de contador único com a chave.

Para mecanismo de armazenamento criptografado configurado com cifra AES256-GCM:

  • Restauração a partir de um hot backup
    A partir da versão 4.2, se você restaurar a partir de arquivos obtidos via backup "quente" (ou seja, o mongod está em execução), o MongoDB pode detectar chaves "sujas" na inicialização e rolar automaticamente a chave do banco de dados para evitar a reutilização IV (Initialization Vector).
  • Restaurando a partir do Cold Backup

    No entanto, se você restaurar a partir de arquivos obtidos via backup "frio" (ou seja, o mongod não está em execução), o MongoDB não poderá detectar chaves "sujas" na inicialização, e a reutilização do IV anulará as garantias de confidencialidade e integridade.

    A partir do 4,2, para evitar a reutilização das chaves após restaurar de um snapshot de sistema de arquivos frio, o MongoDB adiciona uma nova opção de linha de comando --eseDatabaseKeyRollover. Quando iniciada com a opção --eseDatabaseKeyRollover, a instância mongod rola as chaves de banco de dados configuradas com AES256-GCM cifra e sai.

Dica

  • Em geral, se estiver usando backups baseados em sistema de arquivos para o MongoDB Enterprise 4.2+, use o recurso de backup "hot", se possível.

  • Para as versões 4.0 e anteriores do MongoDB Enterprise, se você usar AES256-GCM modo de criptografia, não faça cópias de seus arquivos de dados ou restaure a partir de snapshots do sistema de arquivos ("quente" ou "frio").

Você pode criar um backup de uma implantação MongoDB fazendo uma cópia dos arquivos de dados subjacentes do MongoDB.

Se o volume onde o MongoDB armazena seus arquivos de dados oferecer suporte a snapshots point-in-time, você poderá usar esses snapshots para criar backups de um sistema MongoDB em um momento exato no tempo. Os snapshots do sistema de arquivos são um recurso do gerenciador de volume do sistema operacional e não são específicos do MongoDB. Com os snapshots do sistema de arquivos, o sistema operacional tira um snapshot do volume para usar como linha de base para o backup de dados. A mecânica dos snapshots depende do sistema de armazenamento subjacente. Por exemplo, no Linux, o Logical Volume Manager (LVM) pode criar capturas instantâneas. Da mesma forma, o sistema de armazenamento EBS da Amazon para EC2 suporta capturas de imagem.

Para obter um snapshot correto de um processo de mongod em execução, você deve ter o registro no diário habilitado e o diário deve residir no mesmo volume lógico que os outros arquivos de dados do MongoDB. Sem o registro no diário ativado, não há garantia de que o snapshot seja consistente ou válido.

Para obter uma captura de imagem consistente de um aglomerado compartilhado, você deve desabilitar o balanceador e capturar uma captura de imagem de cada fragmento, bem como um servidor de configuração em aproximadamente o mesmo momento no tempo.

Para obter mais informações, consulte Backup e restauração com snapshots do sistema de arquivos e Backup de um cluster Sharded com snapshots do sistema de arquivos para obter instruções completas sobre como usar o LVM para criar snapshots.

Se o sistema de armazenamento não for compatível com snapshots, você poderá copiar os arquivos diretamente usando cp, rsync ou uma ferramenta semelhante. Como a cópia de vários arquivos não é uma operação atômica, é necessário interromper todas as gravações no mongod antes de copiar os arquivos. Caso contrário, você copiará os arquivos em um estado inválido.

Os backups produzidos copiando os dados subjacentes não oferecem suporte à recuperação pontual de conjuntos de réplicas e são difíceis de gerenciar em clusters fragmentados maiores. Além disso, esses backups são maiores porque incluem os índices e duplicam o preenchimento e a fragmentação do armazenamento subjacente. mongodump, por contraste, cria cópias de segurança menores.

mongodump lê dados de um banco de dados MongoDB e cria arquivos BSON de alta fidelidade que a ferramenta mongorestore pode utilizar para preencher um banco de dados MongoDB. mongodump e o mongorestore são ferramentas simples e eficientes para backup e restauração de pequenas implantações do MongoDB, mas não são ideais para capturar backups de sistemas maiores.

mongodump e mongorestore operar em um processo mongod execução e podem manipular os arquivos de dados subjacentes diretamente. Por padrão, o mongodump não captura o conteúdo do banco de dados local.

mongodump captura apenas os documentos no banco de dados. O backup resultante é eficiente em termos de espaço, mas mongorestore ou mongod precisam reconstruir os índices após a restauração dos dados.

Quando conectado a uma instância do MongoDB, o mongodump pode afetar adversamente o desempenho do mongod . Se seus dados forem maiores do que a memória do sistema, as consultas removerão o conjunto de trabalho da memória, causando falhas na página.

Os aplicativos podem continuar modificando dados enquanto o mongodump captura a saída. Para conjuntos de réplicas, o mongodump fornece a opção --oplog para incluir em sua saída entradas oplog que ocorrem durante a operação mongodump . Isso permite que a operação mongorestore correspondente reproduza o oplog capturado. Para restaurar um backup criado com --oplog, use mongorestore com a opção --oplogReplay .

No entanto, para conjuntos de réplicas, considere o MongoDB Cloud Manager ou o Ops Manager.

Observação

Para usar mongodump e mongorestore como uma estratégia de backup para clusters fragmentados, você deve parar o balancer de cluster fragmentado e usar o comando fsync ou o método db.fsyncLock() no mongos para bloquear gravações no cluster durante os backups.

Os clusters fragmentados também podem usar um dos seguintes processos coordenados de backup e restauração, que mantêm as garantias de atomicidade das transações entre shards:

Consulte Backup e restauração com ferramentas do MongoDB e Fazer backup de um cluster fragmentado com despejos de banco de dados para obter mais informações.

← Gerencias áreas de fragmentos