Menu Docs
Página inicial do Docs
/
Manual do MongoDB
/ /

Métodos de backup para um sistema autogerenciado

Nesta página

  • 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.

Esta página aborda métodos de backup para sistemasautogerenciados .

Para saber mais sobre os métodos de backup para sistemas hospedados no MongoDB Atlas, consulte Fazerbackup, restaurar e arquivar dados.

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 e clusters fragmentados do MongoDB a partir de uma interface gráfica de usuário.

O MongoDB Cloud Manager oferece suporte ao backup e à restauração de implantaçõ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, cadastre-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.

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

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 um snapshot consistente de um cluster fragmentado, você deve desabilitar o balanceador e capturar um snapshot de cada fragmento, bem como um servidor de configuração aproximadamente no mesmo momento. Para fazer backup de clusters fragmentados, consulte Fazer backup de um cluster fragmentado autogerenciado com um dump de banco de dados.

Para obter mais informações, consulte Backup e restauração de uma implantação autogerenciada com snapshots do sistema de arquivos e Backup de um cluster Sharded autogerenciado 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.

As cópias de segurança produzidas copiando os dados subjacentes não permitem a recuperação "point in time" para conjuntos de réplica e são difíceis de gerenciar para clusters maiores fragmentados. Além disso, esses backups são maiores porque incluem os índices e duplicam o preenchimento e a fragmentação do armazenamento subjacente. Já mongodump cria cópias de segurança menores.

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

mongodump e mongorestore operam em um processo mongod em 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 queries removerão o conjunto de trabalho da memória, causando falhas na página.

Os aplicativos podem continuar modificando os dados enquanto o mongodump captura a saída. Para conjuntos de réplicas, mongodump fornece a opção --oplog para incluir em sua saída entradas do oplog que ocorrem durante a operação mongodump. Isso permite que a operação mongorestore correspondente reproduza o registro 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.

Para fazer backup de clusters fragmentados, consulte Fazer backup de um cluster fragmentado autogerenciado com um despejo de banco de dados.

Observação

Para usar mongodump e mongorestore como uma estratégia de backup para clusters fragmentados, consulte Fazer backup de um cluster fragmentado autogerenciado com um despejo de banco de dados.

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 fazer backup e restaurar uma implantação autogerenciada com o MongoDB Tools e fazer backup de um cluster fragmentado autogerenciado com um dump de banco de dados para mais informações.

Voltar

defaultMaxTimeMS