Backup e restore do MongoDB (mongodump, mongorestore, snapshot)

Configura a rotina de backup de um MongoDB já instalado e descreve, cenário por cenário, a recuperação a partir do backup. Backup: mongodump de uma única collection, de um banco de dados ou de todo o deployment (--archive --gzip; em replica set, ponto consistente com --oplog e leitura a partir do secondary), arquivo de credenciais, backup agendado com retenção via systemd timer/cron, restore de teste e snapshot opcional do sistema de arquivos. Restore: ensaio de restore, restore completo, um único banco de dados/collection, retorno a um instante específico com backup + oplog, clone para outro cluster e sharded cluster. Com centenas de GB de dados, quando é necessária uma recuperação rápida ou em sharded cluster, prefere-se snapshot ou uma ferramenta corporativa (PBM, Ops Manager) em vez do mongodump; a escolha é explicada nos primeiros passos.

Topologia: Servidor de backup ou um membro + replica set / instância única / sharded cluster (mongos)

Cenários

• Configurar o backup: mongodump, agendamento e restore de teste — Usuário de backup, arquivo de credenciais, mongodump manual e agendado, restore de teste com renomeação; snapshot e mongoexport opcionais. Se for a primeira configuração, comece por aqui.
• O backup pode mesmo ser restaurado? (--dryRun e ensaio em instância temporária) — Sem tocar nos dados de produção: integridade do arquivo, namespaces e oplog contidos nele e, opcionalmente, restore completo em um mongod temporário com contagem de documentos.
• Restaurar todos os dados do backup (restore completo, --drop) — Os dados foram perdidos ou corrompidos em grande parte e o deployment voltará ao instante em que o backup foi feito. As gravações posteriores ao backup são perdidas; a aplicação fica parada durante o restore.
• Restaurar um único banco de dados ou collection (--nsInclude, com novo nome ou no lugar) — Uma collection/banco de dados foi excluído ou corrompido, o restante está íntegro: só esse namespace vem do backup; os demais dados não são tocados e a aplicação pode continuar no ar.
• Voltar a um instante específico: backup + oplog (drop acidental, update/delete incorreto) — A operação incorreta ocorreu depois do backup e as gravações até aquele instante também são necessárias: o último backup completo é restaurado e o oplog de produção é aplicado até imediatamente antes da operação incorreta (--oplogReplay --oplogLimit). Somente replica set.
• Restaurar o backup em outro cluster / servidor (clone, ambiente de teste, migração) — O deployment de origem não é tocado: o backup é restaurado em outro replica set ou instância (cópia para teste/relatórios, migração de servidor, mudança de versão); os usuários são migrados opcionalmente.
• Restaurar um sharded cluster: limites do mongodump e o método correto — A estrutura do backup é um sharded cluster: restore lógico via mongos (recriação das shard keys, balancer) ou reconstrução física de todo o cluster com snapshots coordenados.

Antes de começar

• O servidor de backup está em um sistema operacional suportado; o relógio está sincronizado via NTP e o fuso horário está correto (os nomes dos arquivos de backup e o agendamento seguem a hora local).
• Há resolução de nomes e acesso às portas deste servidor para os endereços ….… Em replica set, os nomes na string de conexão devem ser iguais aos nomes dos membros em rs.conf(); o driver se conecta a esses nomes.…
• … está em um disco separado do disco de dados ou em um compartilhamento de rede, e o espaço livre é pelo menos o tamanho do backup compactado (geralmente 20–50% dos dados) multiplicado pelos dias de retenção. Um backup no mesmo disco se perde junto com os dados se o disco falhar.
• A autorização está habilitada e você tem o usuário … (funções root ou userAdminAnyDatabase + clusterAdmin) e sua senha. O usuário de backup é criado com esse usuário.
• A janela do oplog é bem maior que a duração do backup completo (pelo menos algumas horas). --oplog coleta as entradas do oplog geradas durante o backup; se a janela for menor que o backup, ele falha.… No retorno no tempo, a primeira entrada do oplog de produção deve ser anterior ao término do backup completo a ser usado; caso contrário, as operações intermediárias não existem em lugar nenhum.…
• Há acesso HTTPS ao repositório do MongoDB (repo.mongodb.org) ou um mirror interno configurado; se as ferramentas estiverem instaladas no servidor, as versões são exibidas.
• O dbPath (…) está no LV … e o volume group tem pelo menos … livres. O journal do WiredTiger (…/journal) deve estar no mesmo LV; se foi movido para outro disco, o fsyncLock antes do snapshot é obrigatório.
• Há permissão de root ou sudo. Se for feito um restore completo, a janela de manutenção e a aprovação da equipe da aplicação foram obtidas.… Antes do restore, o incidente foi registrado (quando, qual operação, quem); a equipe da aplicação sabe quais dados serão restaurados.…
• O backup foi configurado com o cenário "Configurar o backup" deste guia: as ferramentas (mongorestore, mongosh) e o arquivo de credenciais … (…: backup + restore) existem neste servidor. Caso contrário, execute primeiro as duas primeiras fases do cenário Configurar o backup.
• No restore, dados e índices são regravados: o disco de dados dos servidores de destino tem espaço livre de pelo menos 1,5 vez o volume (não compactado) a ser restaurado.… Em replica set, os secondaries recebem as mesmas gravações via replicação; a janela do oplog diminui durante o restore.…
• Há espaço livre em … equivalente ao tamanho não compactado dos dados a restaurar (backup completo + oplog). O mongod temporário escuta somente em 127.0.0.1 na porta …; a porta precisa estar livre.
• O destino (…) está instalado e em execução, a autorização está habilitada e você tem a senha do usuário … (root). A versão do destino é igual ou mais nova que a da origem (ex.: 7.0 → 8.0); restore para versão mais antiga não é suportado.

Fases do guia

• Instalação das ferramentas — Adicionar o repositório do MongoDB … · Adicionar o repositório do MongoDB … · Instalar mongodump, mongorestore e mongosh · Preparar o diretório de backup
• Usuário de backup e arquivo de credenciais — Criar o usuário de backup · Gravar o arquivo de credenciais (--config) · Testar a conexão
• Backup manual (mongodump) — Verificar o tamanho dos dados e a janela do oplog · Parar o balancer · Fazer o backup com mongodump · Reiniciar o balancer · Verificar o backup (gzip e dryRun) · Backup de subconjunto por consulta (--query)
• Restore (mongorestore) — Restore de teste com renomeação (--nsFrom/--nsTo) · Comparar as contagens de documentos · Excluir o banco de teste · Definir a função para oplogReplay · Restore completo no lugar (--drop) · Revogar o privilégio temporário …
• mongoexport / mongoimport (transferência de dados, não é backup) — Exportar a collection (mongoexport) · Importar para uma collection separada (mongoimport) · Comparar os tipos e limpar
• Snapshot do sistema de arquivos — Fazer LVM snapshot (com fsyncLock) · Arquivar o snapshot no diretório de backup · Fazer cópia de arquivos com fsyncLock
• Backup de sharded cluster: limites e caminho corporativo — Escolha do método para backup consistente de sharded cluster
• Backup agendado e retenção — Restringir o balancer para rodar fora do horário de backup · Escrever o script de backup · Tornar o script executável · Preparar o acesso SSH ao servidor remoto · Criar o service e o timer do systemd · Disparar manualmente o backup agendado e verificar …
• Monitoramento e manutenção — Monitorar a idade do último backup · Testes regulares de recuperação
• 1. Diagnóstico: arquivos de backup e ferramentas — Listar os arquivos de backup e os backups mais recentes em ordem
• 2. Ensaio: leitura do arquivo — Verificar a integridade da compactação (gzip -t) · Testar o restore sem gravar dados (--dryRun) · O arquivo tem oplog? (ponto consistente)
• 3. Ensaio: restore completo em instância temporária — Preparar o mongod para a instância temporária · Iniciar o mongod temporário · Restaurar o backup na instância temporária · Contar os dados restaurados · Parar e remover a instância temporária
• 4. Depois — Registrar o resultado do ensaio
• Sharded cluster: o restore completo não é feito com este cenário — Passe para o cenário de sharded cluster
• 1. Diagnóstico: o restore completo é o cenário certo? — Ver o estado atual e os dados afetados · Testar o restore sem gravar dados (--dryRun)
• 2. Rede de segurança — Parar a aplicação e verificar as conexões · Fazer backup do estado atual (ponto de retorno)
• 3. Execução: restore completo — Conceder privilégio temporário para oplogReplay · Restaurar o backup no lugar (--drop… --oplogReplay…) · Revogar o privilégio temporário · Limpar as collections temporárias de usuários do restore
• 4. Verificação — Verificar as contagens de documentos e de índices · Verificar se o replica set está sincronizado
• 5. Depois — Fazer um novo backup completo e liberar a aplicação
• 1. Diagnóstico: estado atual do namespace e estado no backup — Ver o estado em produção · Testar o restore sem gravar dados (--dryRun)
• 2. Rede de segurança — Fazer backup do estado atual (ponto de retorno)
• 2. Execução: restaurar com novo nome — Restaurar o backup com novo nome (--nsFrom/--nsTo) · Comparar as contagens do backup e de produção · Reinserir em produção os documentos excluídos ($merge) · Excluir a cópia temporária
• 3. Execução: restaurar no lugar (--drop) — Preservar a shard key: shardear a collection novamente · Restaurar o namespace no lugar
• Retorno no tempo somente em replica set — Neste deployment não é possível retorno no tempo com oplog
• 1. Diagnóstico: instante da operação incorreta e janela do oplog — Encontrar a operação incorreta no oplog · Verificar se o backup completo está dentro da janela do oplog
• 2. Rede de segurança: copiar o oplog de produção — Fazer uma cópia do oplog de produção · Fazer backup do estado atual (ponto de retorno)
• 3. Execução: voltar àquele instante na instância temporária — Preparar o mongod para a instância temporária · Iniciar o mongod temporário · Restaurar o backup completo na instância temporária · Aplicar o oplog de produção até antes da operação incorreta · Verificar os dados recuperados na instância temporária · Transferir os dados recuperados para produção …
• 4. Depois — Fazer um novo backup completo e eliminar a causa raiz
• 1. Diagnóstico: o destino está correto e é compatível? — Verificar que o destino não é a origem e conferir a versão · Testar o restore sem gravar dados (--dryRun)
• 2. Rede de segurança e credenciais do destino — Gravar um arquivo de credenciais temporário para o destino · Fazer backup dos dados existentes no destino