Ao implantar o MongoDB em produção, tenha uma estratégia de backup e restauração para se proteger contra a 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.
Faça backup com o MongoDB Cloud Manager ou Ops Manager
O MongoDB Cloud Manager é um serviço de backup, monitoramento e automação hospedado para o MongoDB. MongoDB Cloud Manager oferece suporte ao backup e à restauração de conjuntos de réplicas e clusters fragmentados a partir de uma interface gráfica do usuário.
MongoDB Cloud Manager
Importante
Para fazer backup de seus conjuntos de réplicas e clusters fragmentados usando o MongoDB Cloud Manager, você deve estar usando o MongoDB Enterprise Server. Para mais informações, veja Instalar o MongoDB Enterprise.
O MongoDB Cloud Manager faz backup de conjuntos de réplica e clusters lendo dados de oplog de sua implantação do MongoDB. O MongoDB Cloud Manager cria snapshots em intervalos definidos e oferece recuperação de ponto no tempo.
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.
Ops Manager
Com o Ops Manager, os assinantes do MongoDB podem instalar e executar o mesmo software de backup que o MongoDB Cloud Manager em sua própria infraestrutura. O Ops Manager 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.
Faça backup copiando arquivos de dados subjacentes
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
- Se você restaurar a partir de arquivos obtidos por meio de backup "quente" enquanto o
mongodestiver em execução, o MongoDB detectará chaves "sujas" na inicialização e rolará automaticamente sobre a chave do banco de dados para evitar a reutilização de IP (Vector de Inicialização).
- Restaurando a partir do Cold Backup
No entanto, se você restaurar a partir de arquivos obtidos por meio de backup "frio" enquanto o
mongodnão estiver em execução, o MongoDB não detectará chaves "sujas" na inicialização e a reutilização de VI anulará as garantias de confidencialidade e integridade.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ânciamongodrola as chaves de banco de dados configuradas comAES256-GCMcifra e sai.
Se estiver usando backups baseados em sistema de arquivos para o MongoDB Enterprise, use o recurso de backup "quente".
Backup com snapshots do sistema de arquivos
Se o volume onde o MongoDB armazena seus arquivos de dados oferecer suporte a snapshots point-in-time, use esses snapshots para criar backups 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. O sistema operacional tira um snapshot do volume para usar como linha de base para o backup. 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 snapshots.
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.
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 de uma implantação autogerenciada com snapshots do sistema de arquivos e Backup de um cluster autogerenciado com snapshots do sistema de arquivos para obter instruções completas sobre como usar o LVM para criar snapshots.
Fazer backup com cp ou rsync
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.
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.
Faça backup com mongodump
mongodump e mongorestore são ferramentas para backup e restauração de pequenas implantações do MongoDB. Para saber mais, consulte Fazer backup e restaurar uma implantação autogerenciada com as ferramentas do MongoDB.
Para fazer backup de clusters fragmentados, consulte Fazer backup de um cluster fragmentado autogerenciado com um despejo de banco de dados.
Comparar métodos de backup
A tabela a seguir compara os métodos de backup para implantações no local.
Considerações de backup | Cloud Manager/Ops Manager | Snapshot do sistema de arquivos | |
|---|---|---|---|
RTO do backup | Baixo/depende do tipo de armazenamento de snapshots | Baixo | Alta |
RPO do backup | Baixo | Alta | Alta |
Custo de armazenamento de backup | Baixo/depende do tipo de armazenamento de snapshots | Médio | Alta |
Tempo da equipe para gerenciar backups | Nenhum/depende do tipo de armazenamento de snapshots | Alta | Alta |
Backup e restauração contínuos ponto-no-tempo (PIT) | Sim | No | No |
Complexidade da restauração | Baixa se a implantação estiver sob automação | Alto para um cluster fragmentado | Baixo |
Complexidade de um backup de cluster particionado | Baixo | Alta, requer ações adicionais | Alta, requer ações adicionais |
Impacto do backup na implantação do cluster fragmentado de origem | Baixo | Alta, requer bloqueio de gravação | Alta, requer bloqueio de gravação |
Consistências no backup do cluster fragmentado | Garantida | Não garantida, use | Não garantida, use |
Backup incremental | Sim, backup incremental diário e backup completo semanal | Depende do armazenamento e da ferramenta | No |
Define o escopo dos backups | Sim, com filtro de namespace | No | Sim |