MongoDB: Backup e recuperação, segurança e operações

Última atualização: 2026-08-26

As operações são fundamentais para as implantações do MongoDB em produção — o domínio de backups, segurança e monitoramento pode evitar 90% dos incidentes em produção.

1. O que você vai aprender

• backups lógicos com mongodump / mongorestore
• Gerente de Operações / Políticas de backup do Atlas
• Certificação SCRAM e RBAC
• Criptografia TLS/SSL
• Monitoramento de operações (status do servidor / estatísticas do banco de dados / consultas lentas)

graph TB
    subgraph "Backup Strategy"
        A1[Daily Full Backup<br/>mongodump] --> S3[(S3/OSS<br/>Object Storage)]
        A2[oplog Continuous<br/>Incremental] --> S3
        A3[Atlas PITR<br/>Point-in-Time Recovery] --> S3
    end

    subgraph "Restore Scene"
        R1[Accidental Data Deletion] --> R2[mongorestore]
        R3[Entire database lost] --> R2
        R4[A specific point in time] --> R5[oplogReplay]
        R2 --> R6[✅ Data Recovery]
        R5 --> R6
    end

    style R6 fill:#d4edda

graph TB
    subgraph "Backup Strategy"
        A1[Daily Full Backup<br/>mongodump] --> S3[(S3/OSS<br/>Object Storage)]
        A2[oplog Continuous<br/>Incremental] --> S3
        A3[Atlas PITR<br/>Point-in-Time Recovery] --> S3
    end

    subgraph "Restore Scene"
        R1[Accidental Data Deletion] --> R2[mongorestore]
        R3[Entire database lost] --> R2
        R4[A specific point in time] --> R5[oplogReplay]
        R2 --> R6[✅ Data Recovery]
        R5 --> R6
    end

    style R6 fill:#d4edda

2. Backup lógico com o mongodump

Explicação do conceito: o mongodump é a ferramenta oficial de backup lógico do MongoDB — ele lê os dados das coleções e os exporta para arquivos BSON/JSON. Um backup lógico “exporta dados” em vez de “copiar arquivos”, de modo que pode ser restaurado entre diferentes versões e plataformas, mas o backup de bancos de dados grandes é relativamente lento.

Como funciona: o mongodump se conecta ao MongoDB, lê os dados coleção por coleção e documento por documento, serializa-os no formato BSON e os grava no disco. Ele oferece suporte à compactação gzip, à filtragem condicional e à inclusão do oplog (para PITR). As coleções não são bloqueadas durante o backup (backup a quente), mas o backup de coleções grandes pode afetar o desempenho.

Backup lógico x backup físico:

Conceitos de RPO/RTO:

# === Back up the entire database ===
mongodump --uri="mongodb://localhost:27017/shopdb" --out=/backup/2026-07-01

# === Back Up a Specified Set ===
mongodump --uri="mongodb://localhost:27017/shopdb" --collection=users --out=/backup/users

# === Compressed Backup ===
mongodump --uri="mongodb://localhost:27017" --gzip --archive=/backup/shopdb.gz

# === Back up metadata only ===
mongodump --uri="mongodb://localhost:27017" --db=shopdb --collection=users --query='{"role":"admin"}'

Parâmetros principais do mongodump:

3. Recuperação com o mongorestore

Visão geral do conceito: o mongorestore é o equivalente ao mongodump — ele importa arquivos de backup em BSON/JSON para o MongoDB. Ele oferece suporte à restauração completa, à restauração seletiva, à PITR (restauração em um ponto no tempo) e a outros modos.

Como funciona: mongorestore lê a partir de um diretório de backup ou arquivo compactado e insere documentos, uma coleção por vez. A opção --drop primeiro exclui as coleções existentes e, em seguida, as restaura (modo de sobrescrita). Quando usada em conjunto com --oplogReplay, ela reproduz o oplog para realizar uma recuperação em um ponto específico no tempo.

Comparação entre os modos de recuperação:

# === Restore the entire backup ===
mongorestore --uri="mongodb://localhost:27017" /backup/2026-07-01

# === Restore a Specified Database ===
mongorestore --uri="mongodb://localhost:27017" /backup/2026-07-01/shopdb

# === Restore gzip Compressed Backup ===
mongorestore --uri="mongodb://localhost:27017" --gzip --archive=/backup/shopdb.gz

# === Restore and overwrite existing data ===
mongorestore --uri="mongodb://localhost:27017" --drop /backup/2026-07-01

Análise dos pontos-chave:

1. --drop Isso excluirá primeiro a coleção e, em seguida, a restaurará; use com cautela em ambientes de produção (os novos dados adicionados após o backup podem ser perdidos).
2. A inserção de dados no mongorestore aciona a reconstrução do índice, o que retarda a restauração de coleções grandes.
3. Ao restaurar em um banco de dados existente, um conflito _id fará com que documentos duplicados sejam ignorados; use --drop para evitar esse conflito.

4. Estratégia de backup

Explicação do conceito: As estratégias de backup são fundamentais para as operações e a manutenção — elas determinam o RPO (perda máxima de dados) e o RTO (tempo máximo de recuperação). Diferentes cenários de negócios exigem diferentes frequências de backup, políticas de retenção e planos de recuperação.

Comparação de estratégias de backup:

Processo de seleção da estratégia de backup:

graph TB
    A{Business Type?} -->|Non-critical<br/>Log/Cache| B[Daily Total<br/>RPO=24h]
    A -->|General Business<br/>User/Order| C{Data volume?}
    A -->|Core Business<br/>Finance/Payment| D[oplogContinuous<br/>RPO<1s]
    C -->|< 100GB| E[Daily Total+<br/>oplog PITR]
    C -->|> 100GB| F[File Snapshot+<br/>oplogContinuous]

    style D fill:#d4edda
    style B fill:#fff3cd

graph TB
    A{Business Type?} -->|Non-critical<br/>Log/Cache| B[Daily Total<br/>RPO=24h]
    A -->|General Business<br/>User/Order| C{Data volume?}
    A -->|Core Business<br/>Finance/Payment| D[oplogContinuous<br/>RPO<1s]
    C -->|< 100GB| E[Daily Total+<br/>oplog PITR]
    C -->|> 100GB| F[File Snapshot+<br/>oplogContinuous]

    style D fill:#d4edda
    style B fill:#fff3cd

Princípio da PITR (Recuperação em um Momento Específico): Primeiro, restaure o backup completo; em seguida, reproduza as entradas do oplog desde o momento do backup até o momento alvo, conseguindo assim uma recuperação em um momento específico com precisão de segundos.

sequenceDiagram
    participant Full as Full Backup
    participant Oplog as oplog Incremental
    participant Target as Target Date

    Note over Full: Backup Time T0
    Full->>Oplog: RestoreT0Full Data Set

    Note over Oplog: T0 → T1 betweenoplog

    loop Replayoplog
        Oplog->>Target: Replay write operations one by one
    end

    Note over Target: Restore to a Specific Point in Time T1

sequenceDiagram
    participant Full as Full Backup
    participant Oplog as oplog Incremental
    participant Target as Target Date

    Note over Full: Backup Time T0
    Full->>Oplog: RestoreT0Full Data Set

    Note over Oplog: T0 → T1 betweenoplog

    loop Replayoplog
        Oplog->>Target: Replay write operations one by one
    end

    Note over Target: Restore to a Specific Point in Time T1

▶ Exemplo 1: Recuperação prática em um ponto no tempo (PITR)

# ShopHub Accidentally deleted 2026-07-01 10:00-10:30 Order Data，Need to revert to 10:00 Status

# 1. Restore the full backup from the previous day
mongorestore --uri="mongodb://localhost:27017/shopdb_recovery" --drop /backup/2026-06-30/shopdb

# 2. Replay oplog By the target date
mongorestore --uri="mongodb://localhost:27017/shopdb_recovery" --oplogReplay --oplogLimit=1750604400 /backup/2026-06-30/oplog.bson

# 3. Verify the restored data
mongosh --port 27017 shopdb_recovery --eval 'db.orders.count()'

# 4. Export the recovered data and import it into the production environment
mongodump --uri="mongodb://localhost:27017/shopdb_recovery" --collection=orders --query='{"createdAt":{"$gte":{"$date":"2026-07-01T10:00:00Z"},"$lt":{"$date":"2026-07-01T10:30:00Z"}}}' --out=/recovery/orders
mongorestore --uri="mongodb://localhost:27017/shopdb" /recovery/orders

5. Usuários e autenticação

Visão geral do conceito: A segurança é a primeira linha de defesa do MongoDB em implantações em produção. O SCRAM (Salted Challenge Response Authentication Mechanism) é o mecanismo de autenticação padrão do MongoDB, enquanto o RBAC (Role-Based Access Control) controla as permissões com base em funções. O princípio do privilégio mínimo é fundamental para a segurança — cada usuário recebe apenas os privilégios mínimos necessários para realizar suas tarefas.

Como funciona a autenticação SCRAM: O cliente envia um nome de usuário, e o servidor retorna um salt aleatório e o número de iterações. O cliente realiza várias operações de hash usando a senha e o salt para gerar uma prova, e o servidor verifica se a prova corresponde ao hash armazenado. A senha nunca é transmitida em texto simples pela rede.

sequenceDiagram
    participant C as Client
    participant S as MongoDBServer

    C->>S: 1. Username
    S-->>C: 2. salt + iterationCount + storedKey
    C->>C: 3. password + salt → PBKDF2 → clientKey → storedKey
    C->>S: 4. clientProof(Digital Signature)
    S->>S: 5. Verification clientProof
    S-->>C: 6. Authentication Successful ✅ / Failure ❌

    Note over C,S: Passwords are never transmitted over the network

sequenceDiagram
    participant C as Client
    participant S as MongoDBServer

    C->>S: 1. Username
    S-->>C: 2. salt + iterationCount + storedKey
    C->>C: 3. password + salt → PBKDF2 → clientKey → storedKey
    C->>S: 4. clientProof(Digital Signature)
    S->>S: 5. Verification clientProof
    S-->>C: 6. Authentication Successful ✅ / Failure ❌

    Note over C,S: Passwords are never transmitted over the network

Modelo de permissão RBAC:

(1) Certificação SCRAM

// === Create an Administrator User ===
db.createUser({
  user: 'admin',
  pwd: 'SecurePass123!',
  roles: [
    { role: 'userAdminAnyDatabase', db: 'admin' },
    { role: 'readWriteAnyDatabase', db: 'admin' }
  ]
});

// === Create an Application User ===
db.createUser({
  user: 'app_user',
  pwd: 'AppPass456!',
  roles: [{ role: 'readWrite', db: 'shopdb' }]
});

// === Enable Authentication(mongod Startup Parameters)===
mongod --auth --bind_ip_all

(2) Funções RBAC

Princípio do privilégio mínimo:

// === Custom Characters ===
db.createRole({
  role: 'orderManager',
  privileges: [
    { resource: { db: 'shopdb', collection: 'orders' }, actions: ['find', 'insert', 'update'] },
    { resource: { db: 'shopdb', collection: 'products' }, actions: ['find'] }
  ],
  roles: []
});

// === Authorization ===
db.grantRolesToUser('app_user', [{ role: 'orderManager', db: 'shopdb' }]);

▶ Exemplo 2: Configuração de RBAC com o princípio do privilégio mínimo

// TechCorp:Assign the minimum necessary permissions to different teams
// 1. Application Service Account(Read-write only shopdb)
db.createUser({
  user: 'app_service',
  pwd: 'AppSecurePass!',
  roles: [{ role: 'readWrite', db: 'shopdb' }]
});

// 2. Backup Service Account(Backup-only permissions)
db.createUser({
  user: 'backup_service',
  pwd: 'BackupSecurePass!',
  roles: [
    { role: 'backup', db: 'admin' },
    { role: 'readAnyDatabase', db: 'admin' }
  ]
});

// 3. Data Analytics Team(Read-only + Specific Set)
db.createRole({
  role: 'analyticsReader',
  privileges: [
    { resource: { db: 'shopdb', collection: 'orders' }, actions: ['find'] },
    { resource: { db: 'shopdb', collection: 'products' }, actions: ['find'] }
  ],
  roles: []
});
db.createUser({
  user: 'analyst',
  pwd: 'AnalystPass!',
  roles: [{ role: 'analyticsReader', db: 'shopdb' }]
});

// 4. Verify Permissions
db.auth('analyst', 'AnalystPass!');
db.orders.find({}); // ✅ Can be read
db.orders.insertOne({}); // ❌ Insufficient permissions

6. Criptografia TLS/SSL

Explicação do conceito: A criptografia TLS/SSL protege as comunicações de rede do MongoDB — impedindo ataques do tipo “man-in-the-middle”, interceptação de dados e adulteração. O TLS deve estar habilitado em ambientes de produção, especialmente para comunicações entre data centers ou entre nuvens.

Como funciona: O TLS verifica a identidade do servidor por meio de certificados e estabelece uma conexão criptografada. O MongoDB oferece suporte à autenticação por certificado X.509 (como alternativa ao SCRAM), e o TLS mútuo (mTLS) verifica as identidades tanto do cliente quanto do servidor.

Níveis de criptografia:

# === Start mongod with SSL ===
mongod --tlsMode requireTLS --tlsCertificateKeyFile /etc/ssl/mongodb.pem

# === Client Connection ===
mongosh "mongodb://localhost:27017/shopdb?ssl=true&sslCertificateKeyFile=/etc/ssl/client.pem"

Parâmetros de configuração do TLS:

Análise dos pontos-chave:

1. Os clusters auto-hospedados podem usar certificados autoassinados; o TLS está habilitado por padrão no Atlas.
2. O mTLS (Mutual TLS) permite a autenticação baseada em certificado como alternativa à autenticação baseada em senha.
3. O TLS aumenta a latência da conexão em cerca de 5 a 10%, mas é essencial para a segurança dos dados.

7. Operações e monitoramento

Explicação do conceito: O monitoramento de operações funciona como um “painel de integridade” para implantações de produção do MongoDB — utilizando ferramentas como serverStatus, dbStats e análise de consultas lentas para monitorar a integridade do banco de dados em tempo real e detectar e prevenir problemas prontamente.

Sistema de monitoramento:

(1) status do servidor

Principais indicadores:

db.serverStatus();
// {
//   host: 'mongo1',
//   version: '7.0.5',
//   process: 'mongod',
//   uptime: 864000,
//   connections: { current: 150, available: 83860 },
//   opcounters: {
//     insert: 1234567,
//     query: 9876543,
//     update: 234567,
//     delete: 12345
//   },
//   mem: { resident: 1024, virtual: 4096 },
//   ...
// }

(2) Estatísticas do banco de dados

db.stats();
// {
//   db: 'shopdb',
//   collections: 10,
//   objects: 1000000,
//   dataSize: 524288000,
//   storageSize: 268435456,
//   indexes: 20,
//   indexSize: 52428800
// }

(3) Análise de consultas lentas

Explicação do conceito: Consultas lentas são o principal indicador de problemas de desempenho no MongoDB. O processo padrão para otimização de desempenho envolve o uso do Profiler para registrar consultas que excedam um determinado limite e, em seguida, analisar seus planos de execução e o uso de índices.

// === Enable the slow query log(>100ms)===
db.setProfilingLevel(2, { slowms: 100 });

// === View Slow Queries ===
db.system.profile.find({ millis: { $gt: 100 } })
  .sort({ ts: -1 })
  .limit(10);

(4) Estatísticas de uso do índice

db.products.aggregate([{ $indexStats: {} }]);
// Identify unused indexes

Recomendações para o monitoramento da configuração de alertas:

8. Comandos comuns de operação e manutenção

Visão geral do conceito: As operações e a manutenção diárias envolvem o gerenciamento das operações correntes, transações de longa duração, manutenção de índices, compactação de coleções e outras questões. O MongoDB oferece um conjunto de comandos operacionais para ajudar os administradores de banco de dados a diagnosticar e resolver rapidamente problemas em ambiente de produção.

Referência rápida para comandos de operação e manutenção:

// === Current Operation ===
db.currentOp({ "op": "query" });

// === Kill a process ===
db.killOp(opId);

// === Compressed Sets ===
db.runCommand({ compact: 'products' });

// === Rebuild Index ===
db.products.reIndex();

// === View Link ===
db.serverStatus().connections;

Diretrizes de Operação e Manutenção:

Procedimento de resolução de problemas de emergência:

1. db.currentOp() Encontrou uma operação demorada
2. db.killOp(opId) Eliminar a operação problemática
3. db.serverStatus().connections Verifique o número de conexões
4. Se o número de conexões atingir a capacidade máxima, considere reduzir temporariamente o tamanho do pool de conexões do aplicativo.
5. Use o Profiler para analisar a causa raiz posteriormente e adicione índices ou otimize as consultas

▶ Exemplo: Política de backup completa + configuração de segurança RBAC

# === 1. Daily Automatic Backup Script(backup-daily.sh)===
#!/bin/bash
set -e

DATE=$(date +%Y%m%d)
BACKUP_DIR=/backup/mongodb/$DATE
RETENTION_DAYS=7

# 1.1 Full Backup(gzip Compression)
mongodump   --uri="mongodb://backup_user:SecurePass@mongo1:27017,mongo2:27017,mongo3:27017/shopdb?replicaSet=rs0"   --gzip   --archive=$BACKUP_DIR.gz   --oplog  # Includes oplog，Support PITR

# 1.2 Upload to S3
aws s3 cp $BACKUP_DIR.gz s3://my-bucket/mongodb-backups/$DATE/

# 1.3 Cleanup 7 Local backup from X days ago
find /backup/mongodb/ -name "*.gz" -mtime +$RETENTION_DAYS -delete

# 1.4 Record Backup Logs
echo "[$(date)] Backup completed: $BACKUP_DIR.gz ($(du -h $BACKUP_DIR.gz | cut -f1))" >> /var/log/mongodb-backup.log

# 1.5 Add to crontab (Daily at 2 AM)
# 0 2 * * * /usr/local/bin/backup-daily.sh

# === 2. Recovery Drill ===
# 2.1 View Available Backups
ls -lh /backup/mongodb/

# 2.2 Restore to the test environment
mongorestore   --uri="mongodb://localhost:27017/shopdb_test"   --gzip   --archive=/backup/mongodb/20260701.gz   --drop  # Overwrite existing data

# 2.3 PITR Restore to a Specific Point in Time
mongorestore   --uri="mongodb://localhost:27017"   --gzip   --archive=/backup/mongodb/20260701.gz   --oplogReplay   --pointInTime=2026-07-01T10:30:00

// === 3. Enable Authentication + Create RBAC User ===
// 3.1 Create an Administrator User(The first must)
db.createUser({
  user: 'root',
  pwd: 'RootSecurePass!',
  roles: [{ role: 'root', db: 'admin' }]
});

// 3.2 Create a User Dedicated to Backups(Least Privilege)
db.createUser({
  user: 'backup_user',
  pwd: 'BackupPass!',
  roles: [
    { role: 'backup', db: 'admin' },
    { role: 'readAnyDatabase', db: 'admin' }
  ]
});

// 3.3 Create an Application User(Reading and Writing shopdb)
db.createUser({
  user: 'app_user',
  pwd: 'AppPass!',
  roles: [{ role: 'readWrite', db: 'shopdb' }]
});

// 3.4 Create a read-only analysis user
db.createUser({
  user: 'analytics_user',
  pwd: 'AnalyticsPass!',
  roles: [{ role: 'read', db: 'shopdb' }]
});

// 3.5 Enable TLS/SSL(mongod Startup Parameters)
// mongod --tlsMode requireTLS --tlsCertificateKeyFile /etc/ssl/mongodb.pem --auth

// === 4. Monitoring Alerts ===
// Enable the slow query log
db.setProfilingLevel(2, { slowms: 100 });

// View Slow Queries Top 10
db.system.profile.find({ millis: { $gt: 100 } })
  .sort({ ts: -1 })
  .limit(10)
  .forEach(p => print(`[${p.ts}] ${p.command.find}: ${p.millis}ms`));

// Monitor Connection Count
const stats = db.serverStatus();
print(`Active connections: ${stats.connections.current}/${stats.connections.available}`);
// Alert Thresholds:current > 1000 → Email Alerts

// === 5. Automated Inspection Script ===
function dailyHealthCheck() {
  print('=== MongoDB Daily Health Check ===');

  // 5.1 Dungeon Collection Status
  const rsStatus = rs.status();
  const primary = rsStatus.members.find(m => m.stateStr === 'PRIMARY');
  print(`Primary: ${primary.name}`);

  // 5.2 oplog Window(Avoid Overwriting)
  const oplogWindow = primary.optimeDate ? (Date.now() - primary.optimeDate.getTime()) / 1000 : 0;
  print(`Oplog window: ${Math.floor(oplogWindow / 3600)} hours`);
  if (oplogWindow > 24 * 3600) print('⚠️  WARNING: oplog window > 24h');

  // 5.3 Index Usage Rate
  const indexes = db.products.aggregate([{ $indexStats: {} }]).toArray();
  const unused = indexes.filter(i => i.accesses.ops === 0);
  print(`Unused indexes: ${unused.length}`);
  if (unused.length > 0) {
    unused.forEach(i => print(`  - ${i.name}`));
  }
}

dailyHealthCheck();

Resultado: Backups diários automáticos com retenção de 7 dias; controle de acesso de usuários RBAC em três níveis; monitoramento e alertas para a detecção oportuna de problemas de desempenho.

❓ Perguntas Frequentes

P: O mongodump é um backup a quente? R: Sim, o mongodump não requer interrupção do serviço. No entanto, fazer backup de coleções grandes pode afetar o desempenho; por isso, recomenda-se executá-lo fora dos horários de pico.

P: O RBAC afeta o desempenho? R: Praticamente não há impacto. O RBAC verifica as permissões na memória.

P: Como a produção é monitorada? R: Use o MongoDB Atlas (que inclui monitoramento integrado) ou o Prometheus + mongo_exporter (hospedado localmente).

📖 Resumo

• backup lógico com mongodump/mongorestore
• Estratégia de backup: backup completo diário + backup contínuo do oplog + PITR do Atlas
• Certificação SCRAM + Permissões baseadas em funções (RBAC)
• Criptografia TLS/SSL
• Monitoramento: status do servidor / estatísticas do banco de dados / consultas lentas / $indexStats
• Comandos de operações: currentOp / killOp / compact / reIndex

📝 Exercícios

1. Exercício básico (⭐): Faça backup do banco de dados shopdb usando mongodump e, em seguida, restaure-o usando mongorestore.
2. Exercício básico (⭐): Crie os usuários “admin” e “app_user” e conceda permissões a eles.
3. Exercício avançado (⭐⭐): Implemente um script de backup diário (cron + mongodump + compactação + exclusão de dados com mais de 7 dias).
4. Exercício avançado (⭐⭐): Ative a análise de consultas lentas e identifique as 10 consultas mais lentas.
5. Desafio (⭐⭐⭐): Concluir o plano de operações e manutenção (script de backup + permissões de usuário + TLS + monitoramento e alertas).

Equipe Técnica Web-Tutorial

Uma plataforma de tutoriais mantida por diversos desenvolvedores. Cada tutorial é escrito e revisado por profissionais da área correspondente. Trabalhamos para manter nosso conteúdo preciso e confiável — se encontrar algum problema, avise-nos.

Sobre Nós