MongoDB · Backup & Recuperação

Percona Backup
for MongoDB

Guia operacional para backup e recuperação de replica sets e sharded clusters MongoDB com o PBM: da instalação ao restore. Cada passo vem com o motivo, o comando e o ponto de atenção, e cada tópico termina com os links da documentação oficial. Os exemplos de storage cobrem MinIO (S3 compatível) e filesystem.

16 tópicos

PBM 2.x (documentação 2.16.0)

Linux: Debian/Ubuntu e RHEL

Recursos gerais

01Os nomes em MAIUSCULAS_COM_UNDERSCORE são placeholders (URI, senha, nome do backup, data): substitua antes de copiar qualquer comando

02Parâmetros e padrões mudam entre versões: confirme com pbm version e troque /latest/ pela sua versão no endereço da documentação (por exemplo, /2.15.0/)

03O PBM não funciona em instâncias standalone, pois precisa do oplog: para testes, converta o standalone em um replica set de um nó

04Backup físico e incremental existem só no Percona Server for MongoDB (PSMDB); em MongoDB Community e Enterprise, use backup lógico + PITR

Documentação do PBM Comandos pbm Release notes GitHub

Fundamentos e Preparação

Arquitetura do PBM, instalação e configuração do storage

Visão geral e arquiteturaBásico

pbm-agent, CLI, storage remoto e coleções de controle

O PBM é composto por três peças. Entender o papel de cada uma evita a maior parte dos erros de operação.

pbm-agent

Serviço (systemd) que roda em cada nó mongod (inclusive config servers de um sharded cluster). Conecta no mongod local, escuta comandos e executa backup, restore e o fatiamento de oplog do PITR.

pbm (CLI)

Ferramenta de linha de comando. Não faz o trabalho pesado: grava um comando no banco, e os agents o executam. Pode rodar em qualquer host com acesso ao cluster.

Storage remoto

Onde ficam os dados do backup, os metadados e os chunks de oplog do PITR: S3/MinIO, GCS, Azure Blob, OCI, OSS ou filesystem (NFS). É a fonte da verdade do histórico de backups.

Coleções de controle

No banco admin o PBM mantém coleções como pbmBackups, pbmRestores, pbmAgents, pbmConfig e pbmLock, entre outras. Elas guardam estado e catálogo.

Fluxo de um backuppbm backup grava o comando em admin, os agents competem pelo lock, o nó eleito (por prioridade, preferindo secundários) lê os dados, comprime e envia ao storage, e o metadado do backup é gravado ao final. Por isso o agent precisa enxergar tanto o MongoDB quanto o storage.

Só funciona com oplogO PBM não funciona em instâncias standalone: precisa do oplog para garantir consistência. Para testes, converta o standalone em um replica set de um nó.

Como o PBM funciona Arquitetura pbm-agent PBM CLI Coleções de controle Deployments suportados

Instalação e preparaçãoBásico

Pacote, usuário e role, URI do agent e validação com pbm status

Execute os passos abaixo em todos os nós do replica set (e em todos os shards e config servers, se for sharded).

Instalar o pacote Usa o repositório oficial da Percona. O pacote instala o binário pbm, o pbm-agent e a unit do systemd.

wget https://repo.percona.com/apt/percona-release_latest.$(lsb_release -sc)_all.deb
sudo dpkg -i percona-release_latest.$(lsb_release -sc)_all.deb
sudo apt update
sudo percona-release enable pbm release
sudo apt install -y percona-backup-mongodb
pbm version

sudo yum install -y https://repo.percona.com/yum/percona-release-latest.noarch.rpm
sudo percona-release enable pbm release
sudo yum install -y percona-backup-mongodb
pbm version

Mesma versão em todos os nósMantenha o pbm-agent na mesma versão em todos os nós e a CLI compatível. Versões misturadas causam comportamento imprevisível em backup e restore.

Criar o usuário e a role do PBM no MongoDB O PBM precisa ler dados, gravar nas coleções de controle e, no restore, recriar tudo. A documentação oficial usa uma role customizada com anyAction em anyResource. Rode no primary (em sharded cluster, crie também em cada shard e no config server).

db.getSiblingDB("admin").createRole({
  role: "pbmAnyAction",
  privileges: [
    { resource: { anyResource: true }, actions: [ "anyAction" ] }
  ],
  roles: []
});

db.getSiblingDB("admin").createUser({
  user: "pbmuser",
  pwd: "SENHA_FORTE",
  roles: [
    { db: "admin", role: "readWrite", collection: "" },
    { db: "admin", role: "backup" },
    { db: "admin", role: "clusterMonitor" },
    { db: "admin", role: "restore" },
    { db: "admin", role: "pbmAnyAction" }
  ]
});

Configurar a conexão do agent O agent lê a variável PBM_MONGODB_URI do arquivo de ambiente do serviço. A URI deve apontar para o mongod local (localhost), nunca para o replica set inteiro. Caracteres especiais na senha precisam de URL-encode (@ vira %40).
/etc/default/pbm-agent (Debian) ou /etc/sysconfig/pbm-agent (RHEL)
```
PBM_MONGODB_URI="mongodb://pbmuser:SENHA_FORTE@localhost:27017/?authSource=admin&replicaSet=NOME_DO_RS"
```
Shell
```
sudo chmod 600 /etc/default/pbm-agent
sudo chown root:root /etc/default/pbm-agent
```
Se o cluster usa keyFile, ele precisa ser idêntico em todos os nós. Divergência de keyFile é causa clássica de agent que não autentica. Para não deixar a senha em arquivo de ambiente, a documentação descreve o uso de credenciais do systemd.

Subir o serviço do agent

sudo systemctl enable --now pbm-agent
sudo systemctl status pbm-agent
sudo journalctl -u pbm-agent -n 50 --no-pager

Configurar a CLI em um host de administração A CLI precisa da URI do cluster (aqui sim, com todos os membros) para gravar comandos. Duas formas: variável de ambiente ou a flag --mongodb-uri.
Shell
```
export PBM_MONGODB_URI="mongodb://pbmuser:SENHA_FORTE@no1:27017,no2:27017,no3:27017/?authSource=admin&replicaSet=NOME_DO_RS"
pbm status
```
sudo apaga a variávelAo rodar sudo pbm ... o ambiente do usuário não é repassado e o pbm falha por falta de URI. Use sudo -E pbm ... ou --mongodb-uri. Em cron, carregue a variável explicitamente (veja Executar backups).
Configurar o storage e validar O storage é configurado uma única vez e vale para o cluster todo. Veja a próxima seção. Depois valide que todos os agents aparecem com status OK:
Shell
```
pbm status
```
Na saída, confira a seção Cluster (todos os nós [OK]) e as seções PITR e Backups.

Detalhes e exemplos por tópico

Cada bloco abaixo resume o que a página oficial cobre, traz exemplos para testar no seu ambiente e termina com o link da documentação.

Requisitos de sistema

O PBM roda em Linux e exige MongoDB em replica set (ou sharded cluster): ele depende do oplog, então standalone não é suportado. O pbm-agent precisa ser instalado em cada nó mongod. Antes de instalar, confira a versão do MongoDB, a arquitetura do host, o espaço em disco para logs e se o nó enxerga o storage de destino.

mongod --version
uname -m                      # x86_64 ou aarch64
df -h /var/log                # espaço para logs do agent
curl -sI https://minio.exemplo.com.br:9000 | head -1   # o nó alcança o storage?

rs.status().set
rs.status().members.map(m => m.name + " " + m.stateStr)

Documentação oficial: Requisitos de sistema

Instalar pelos repositórios

O repositório da Percona entrega o pbm, o pbm-agent e a unit do systemd num único pacote. O percona-release habilita o canal; use release para versões estáveis. Em ambientes sem acesso à internet, é possível baixar o pacote por outro host e instalá-lo localmente, mantendo a mesma versão em todos os nós.

# Debian / Ubuntu
apt-cache policy percona-backup-mongodb

# RHEL / Rocky / Alma
yum --showduplicates list percona-backup-mongodb

pbm version
systemctl cat pbm-agent | head -20

Documentação oficial: Instalar pelos repositórios

Initial setup

A página de setup inicial amarra a ordem correta: criar o usuário e a role, definir a URI do agent, subir o pbm-agent em todos os nós, configurar o storage e validar com pbm status. Em sharded cluster repita a criação do usuário em cada shard e no config server, e rode um pbm-agent em cada nó de todos eles.

systemctl is-active pbm-agent                  # active
grep PBM_MONGODB_URI /etc/default/pbm-agent | sed "s/:[^:@]*@/:***@/"   # URI sem expor a senha

export PBM_MONGODB_URI="mongodb://pbmuser:SENHA_FORTE@no1:27017,no2:27017,no3:27017/?authSource=admin&replicaSet=NOME_DO_RS"
pbm status

Documentação oficial: Initial setup

Autenticação no MongoDB

O agent se autentica no mongod local com a URI de PBM_MONGODB_URI. Os erros mais comuns são authSource errado, replicaSet incorreto e keyFile diferente entre os nós. Caracteres especiais na senha precisam de URL-encode: @ vira %40 e / vira %2F.

mongosh "mongodb://pbmuser:SENHA_FORTE@localhost:27017/?authSource=admin&replicaSet=NOME_DO_RS" --eval "db.runCommand({ ping: 1 })"

python3 -c "import urllib.parse; print(urllib.parse.quote('P@ss/word', safe=''))"
# P%40ss%2Fword

sha256sum /etc/mongod.keyfile    # o hash deve ser idêntico em todos os nós

Documentação oficial: Autenticação no MongoDB

Roles do usuário PBM

O usuário do PBM combina as roles nativas readWrite, backup, clusterMonitor e restore com a role customizada pbmAnyAction, que concede anyAction em anyResource. Isso é necessário porque o restore recria coleções, índices, usuários e roles. Em sharded cluster, o usuário precisa existir em cada shard e no config server.

db.getSiblingDB("admin").getUser("pbmuser")
db.getSiblingDB("admin").getRole("pbmAnyAction", { showPrivileges: true })

db.getSiblingDB("admin").grantRolesToUser("pbmuser", [ { role: "restore", db: "admin" } ])

Documentação oficial: Roles do usuário PBM

Credenciais com systemd

Por padrão a URI (com a senha) fica em /etc/default/pbm-agent. Como alternativa, a documentação descreve usar o mecanismo de credenciais do systemd para não deixar a senha em um arquivo de ambiente comum. O desenho exato do drop-in depende da sua versão do systemd e do PBM: siga a página oficial e valide com os comandos abaixo.

ls -l /etc/default/pbm-agent        # -rw------- root root
ps -eo args | grep [p]bm-agent       # a senha não deve aparecer na linha de comando
systemctl show pbm-agent -p EnvironmentFiles

Documentação oficial: Credenciais com systemd

Iniciar o pbm-agent

O agent é um serviço systemd que deve rodar em todos os nós. Depois de mudar a URI ou o keyFile, reinicie o serviço. Para depurar problemas de conexão, o agent também pode ser executado em primeiro plano com a URI na linha de comando (pare o serviço antes).

sudo systemctl enable --now pbm-agent
sudo systemctl status pbm-agent
sudo journalctl -u pbm-agent -n 50 --no-pager

for h in no1 no2 no3; do
  ssh "$h" "sudo systemctl enable --now pbm-agent"
done
pbm status

sudo systemctl stop pbm-agent
pbm-agent --mongodb-uri "mongodb://pbmuser:SENHA_FORTE@localhost:27017/?authSource=admin"

Documentação oficial: Iniciar o pbm-agent

Upgrade do PBM

Atualize o pbm-agent em todos os nós e a CLI na mesma versão. Leia as release notes antes, teste em homologação e não atualize com um backup ou restore em andamento (confira com pbm status). Depois do upgrade, reinicie o agent e valide o cluster.

pbm status                              # nada em execução?
sudo apt update
sudo apt install --only-upgrade percona-backup-mongodb
sudo systemctl restart pbm-agent
pbm version
pbm status

sudo yum update percona-backup-mongodb
sudo systemctl restart pbm-agent
pbm version

Documentação oficial: Upgrade do PBM

Storage: visão geral e comandosBásico

Arquivo YAML, pbm config e aprendizados de campo

O PBM guarda os backups, os metadados e as fatias de oplog do PITR em um storage remoto, configurado uma única vez para o cluster todo. A configuração fica em um arquivo YAML aplicado com pbm config --file: o PBM a grava no banco (coleção pbmConfig), e por isso ela vale para todos os agents sem precisar copiar o arquivo para cada nó.

Bucket dedicadoA documentação pede que o PBM tenha um bucket exclusivo para os arquivos de backup. Dentro dele, use um prefix diferente por cluster.

Tipos de storage suportados

type	Quando usar	Observação
minio	MinIO e object storages S3 compatíveis fora da AWS (ex.: provedores nacionais de object storage).	Passos e opções na próxima etapa. Aceita `secure`, `forcePathStyle` e `endpointMap`.
s3	AWS S3 e compatíveis que exijam recursos de S3 (SSE-KMS, classe de armazenamento).	Também funciona com MinIO, mas com nomes de opção diferentes (`endpointUrl` em vez de `endpoint`).
filesystem	Diretório local ou NFS montado em todos os nós.	O PBM não confere se a montagem existe: veja a etapa de filesystem.
gcs, azure, oss, oci	Google Cloud Storage, Azure Blob, Alibaba OSS e Oracle Cloud.	Não são detalhados neste guia; use os links da documentação oficial abaixo.

Fluxo para configurar qualquer storage

Preparar o destino Crie o bucket (ou o diretório compartilhado) e um usuário com permissão restrita a ele. O PBM não cria o bucket.
Escrever o YAML Defina storage e, se quiser, backup, pitr e restore no mesmo arquivo. Proteja-o: ele contém credenciais.
Shell
```
chmod 600 /etc/pbm-config.yaml
```

Aplicar e conferir

pbm config --file /etc/pbm-config.yaml
pbm config --list      # confirma o que ficou gravado
pbm status             # agents OK e storage acessível

Validar com um backup de teste Rode um backup pequeno e confira que o objeto apareceu no storage antes de depender dele.
Shell
```
pbm backup --type=logical --wait
pbm list
```

Comandos de configuração

Objetivo	Comando
Aplicar um arquivo completo	`pbm config --file /etc/pbm-config.yaml`
Ver a config ativa	`pbm config --list`
Alterar uma chave	`pbm config --set pitr.oplogSpanMin=30`
Recarregar o catálogo a partir do storage	`pbm config --force-resync`

Aprendizados de campo com a config YAML

restore: {} deve estar na raiz do arquivo. Aninhado em backup: a config é rejeitada ou ignorada.
backup.priority (mapa de pesos por nó) só pode ser aplicado via --file, não via --set.
Trocar o storage não migra os backups antigos. Após apontar para um bucket ou diretório já populado, rode --force-resync para o PBM reconstruir o catálogo.
O arquivo contém credenciais: permissão 600, fora de repositório git.

Detalhes e exemplos por tópico

Cada bloco resume o que a página oficial cobre, traz exemplos e termina com o link da documentação.

Configurar o storage remoto

O passo a passo oficial: escrever o YAML, aplicá-lo com pbm config --file e conferir com pbm config --list. A config é gravada no banco, então vale para todos os agents. Também é possível alterar uma única chave com --set, sem reenviar o arquivo inteiro.

pbm config --file /etc/pbm-config.yaml
pbm config --set storage.minio.prefix=NOME_DO_RS/producao
pbm config --list

pbm config --force-resync
pbm list

Documentação oficial: Configurar o storage remoto

Visão geral dos storages

Resume os tipos aceitos e as regras comuns: bucket exclusivo para o PBM, um prefixo por cluster e a mesma config para todos os nós. O type escolhe qual bloco é lido; os demais são ignorados. Abaixo, o esqueleto mínimo dos dois tipos mais usados neste guia.

storage:
  type: minio
  minio:
    endpoint: minio.exemplo.com.br:9000
    bucket: pbm-backups
    prefix: NOME_DO_RS/producao
    region: us-east-1
    secure: true
    forcePathStyle: true
    credentials:
      access-key-id: "ACCESS_KEY"
      secret-access-key: "SECRET_KEY"

storage:
  type: filesystem
  filesystem:
    path: /backup/pbm

Documentação oficial: Visão geral dos storages

MinIO e S3 compatíveis

O tipo minio atende o MinIO e outros object storages S3 compatíveis. Pontos de atenção: secure é false por padrão (defina true se houver TLS), forcePathStyle também (defina true sem DNS wildcard) e a region deve ser explícita. Os detalhes de cada opção e um exemplo de produção completo estão na etapa "Storage: MinIO e S3 compatíveis".

mc alias set minio https://minio.exemplo.com.br:9000 ACCESS_KEY SECRET_KEY
mc ls minio/pbm-backups
mc ls --recursive minio/pbm-backups/NOME_DO_RS/producao | head

curl -v https://minio.exemplo.com.br:9000/minio/health/live

Documentação oficial: MinIO e S3 compatíveis

Filesystem

Com type: filesystem o PBM grava em um diretório. Em cluster, ele precisa ser o mesmo caminho, compartilhado e montado em todos os nós. O PBM não verifica se é um ponto de montagem: se o NFS cair, o backup pode ir parar no disco local sem erro. Detalhes na etapa "Storage: filesystem (NFS)".

for h in no1 no2 no3; do
  echo "== $h"
  ssh "$h" "findmnt /backup/pbm && ls -ld /backup/pbm"
done

ssh no1 "ls /backup/pbm | head"
ssh no2 "ls /backup/pbm | head"

Documentação oficial: Filesystem

AWS S3

O tipo s3 atende o AWS S3 e compatíveis que precisem de recursos como criptografia no servidor (SSE-KMS ou SSE-C) e classe de armazenamento. Em instâncias EC2 é possível usar uma IAM role em vez de chaves no YAML; confirme os detalhes na página oficial. A política mínima abaixo é a mesma lógica usada para o MinIO.

storage:
  type: s3
  s3:
    region: sa-east-1
    bucket: pbm-backups-exemplo
    prefix: NOME_DO_RS/producao
    credentials:
      access-key-id: "ACCESS_KEY"
      secret-access-key: "SECRET_KEY"
    serverSideEncryption:
      sseAlgorithm: aws:kms
      kmsKeyID: "ARN_OU_ID_DA_CHAVE"

{
  "Version": "2012-10-17",
  "Statement": [
    { "Effect": "Allow",
      "Action": [ "s3:ListBucket", "s3:GetBucketLocation", "s3:ListBucketMultipartUploads" ],
      "Resource": "arn:aws:s3:::pbm-backups-exemplo" },
    { "Effect": "Allow",
      "Action": [ "s3:GetObject", "s3:PutObject", "s3:DeleteObject", "s3:AbortMultipartUpload", "s3:ListMultipartUploadParts" ],
      "Resource": "arn:aws:s3:::pbm-backups-exemplo/*" }
  ]
}

Documentação oficial: AWS S3

Opções de storage (referência)

Tabela completa de opções de todos os tipos, com padrões e a versão em que cada uma surgiu. É a página para consultar antes de ajustar qualquer chave. Regra prática: rode primeiro com os padrões, meça tempo e uso de CPU e mude uma opção por vez.

pbm config --set storage.minio.partSize=67108864
pbm config --set storage.minio.retryer.numMaxRetries=10
pbm config --list | grep -A3 partSize

time pbm backup --type=logical --wait
pbm describe-backup NOME_DO_BACKUP

Documentação oficial: Opções de storage (referência)

Múltiplos endpoints

Use endpointMap quando os agents enxergam o mesmo storage por caminhos de rede diferentes, por exemplo um MinIO acessado por endereços distintos em cada datacenter. A chave é o host:porta do nó MongoDB (como aparece no replica set) e o valor é o endpoint que aquele nó deve usar. Nós fora do mapa usam o endpoint principal. Disponível a partir da 2.8.0.

storage:
  type: minio
  minio:
    endpoint: minio.exemplo.com.br:9000
    endpointMap:
      "mongodb-app-1.exemplo.com.br:27017": "minio-dc1.exemplo.com.br:9000"
      "mongodb-app-2.exemplo.com.br:27017": "minio-dc2.exemplo.com.br:9000"
    bucket: pbm-backups
    region: us-east-1
    secure: true
    forcePathStyle: true
    credentials:
      access-key-id: "ACCESS_KEY"
      secret-access-key: "SECRET_KEY"

Documentação oficial: Múltiplos endpoints

Arquivos grandes (split/merge)

O PBM divide arquivos acima de maxObjSizeGB (padrão 5018) em partes e as junta de volta no restore. Reduzir esse valor ajuda quando o storage ou um proxy limita o tamanho de objeto, e deixa o reenvio mais barato após falhas em coleções de centenas de GB.

storage:
  type: minio
  minio:
    # ... demais opções ...
    maxObjSizeGB: 50
    partSize: 67108864

mc ls --recursive --summarize minio/pbm-backups/NOME_DO_RS/producao | tail -5

Documentação oficial: Arquivos grandes (split/merge)

Config em cluster

A configuração é guardada no próprio cluster e vale para todos os agents: aplique uma vez, de qualquer host com a CLI, e não copie o YAML para cada nó. Em sharded cluster, a CLI deve apontar para a URI indicada na documentação do seu tipo de deployment. Para ver o que está em uso, consulte o pbm status e o pbm config --list.

pbm config --file /etc/pbm-config.yaml
pbm config --list
pbm status

db.getSiblingDB("admin").pbmConfig.find().pretty()

Documentação oficial: Config em cluster

Storage: MinIO e S3 compatíveisIntermediário

Bucket, política mínima, YAML e cada opção do bloco minio

Preparar o MinIO: bucket, usuário e política mínima Crie um bucket só para o PBM e um usuário com permissão restrita a ele. A sintaxe do mc muda entre releases do MinIO; confirme com mc admin --help.

mc alias set minio https://minio.exemplo.com.br:9000 ADMIN_KEY ADMIN_SECRET
mc mb minio/pbm-backups
mc admin user add minio pbmuser SENHA_FORTE_DO_MINIO
mc admin policy create minio pbm-rw /tmp/pbm-policy.json
mc admin policy attach minio pbm-rw --user pbmuser

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [ "s3:ListBucket", "s3:GetBucketLocation", "s3:ListBucketMultipartUploads" ],
      "Resource": [ "arn:aws:s3:::pbm-backups" ]
    },
    {
      "Effect": "Allow",
      "Action": [ "s3:GetObject", "s3:PutObject", "s3:DeleteObject",
                  "s3:AbortMultipartUpload", "s3:ListMultipartUploadParts" ],
      "Resource": [ "arn:aws:s3:::pbm-backups/*" ]
    }
  ]
}

Escrever o YAML do PBM

storage:
  type: minio
  minio:
    endpoint: minio.exemplo.com.br:9000
    bucket: pbm-backups
    prefix: NOME_DO_RS/producao
    region: us-east-1
    secure: true
    insecureSkipTLSVerify: false
    forcePathStyle: true
    credentials:
      access-key-id: "ACCESS_KEY"
      secret-access-key: "SECRET_KEY"
    partSize: 33554432
    retryer:
      numMaxRetries: 10
    maxObjSizeGB: 5018
    debugTrace: false

backup:
  compression: s2
  numParallelCollections: 16

pitr:
  enabled: false
  oplogSpanMin: 60
  compression: s2

restore: {}

Aplicar e validar
Shell
```
chmod 600 /etc/pbm-config.yaml
pbm config --file /etc/pbm-config.yaml
pbm config --list
pbm status
```
Faça um backup de teste e confira o objeto no bucket (mc ls --recursive minio/pbm-backups/NOME_DO_RS/producao).

Exemplo completo de produção (dados mascarados)

Arquivo real de um cluster com coleções muito grandes, com endpoint, bucket, chaves e hostnames trocados por valores fictícios. Ele mostra como as decisões de capacidade entram no YAML: partes de upload maiores, objetos limitados a 50 GB, poucas coleções em paralelo para poupar memória e PITR com fatias de 30 minutos.

storage:
  type: minio
  minio:
    endpoint: "object.exemplo.com.br"
    region: "REGIAO"
    bucket: "mongodb-backup-APP"
    prefix: ""
    credentials:
      access-key-id: "ACCESS_KEY_EXEMPLO"
      secret-access-key: "SECRET_KEY_EXEMPLO"
    secure: true
    forcePathStyle: true
    insecureSkipTLSVerify: false
    partSize: 67108864            # 64 MB por parte do upload multipart
    maxObjSizeGB: 50              # quebra a coleção grande (~354 GB) em objetos menores
    retryer:
      numMaxRetries: 10
pitr:
  enabled: true
  oplogSpanMin: 30                # uma fatia de oplog a cada 30 minutos
  compression: s2
  compressionLevel: 5
backup:
  oplogSpanMin: 0
  compression: s2
  numParallelCollections: 2       # reduzido de 4 para 2: menos pressão de memória e cache no nó de origem
  # priority:                     # descomente para poupar ou preferir nós (aplicar com --file)
  #   "mongodb-app-1.exemplo.com.br:27017": 0.1
  #   "mongodb-app-2.exemplo.com.br:27017": 0.1
  #   "mongodb-app-3.exemplo.com.br:27017": 10
restore: {}

Por que cada escolha

Chave	Valor	Motivo
prefix	`""`	Bucket dedicado a um único cluster, então os dados ficam na raiz. Com vários clusters no mesmo bucket, use um prefixo por cluster.
secure + forcePathStyle	`true`	Endpoint com TLS e sem DNS wildcard para `bucket.endpoint`: sem estas duas chaves o PBM falaria HTTP e usaria virtual-hosted.
partSize	`67108864`	Partes de 64 MB reduzem o número de requisições em backups de centenas de GB (o padrão é 10 MB).
maxObjSizeGB	`50`	Uma única coleção de ~354 GB seria um objeto gigante. Limitar a 50 GB gera objetos menores, mais fáceis de reenviar em caso de falha e compatíveis com limites de proxy.
retryer.numMaxRetries	`10`	Tolera falhas transitórias de rede durante uploads longos.
pitr.oplogSpanMin	`30`	Equilíbrio entre perda potencial (RPO de até 30 min) e quantidade de objetos de oplog no bucket.
pitr.compressionLevel	`5`	Nível do algoritmo `s2` para as fatias: mais compressão com um pouco mais de CPU.
numParallelCollections	`2`	Menos coleções lidas em paralelo, menos memória e cache do WiredTiger usados no nó que faz o backup (padrão: metade das CPUs).
priority (comentado)	pesos	Pesos baixos poupam os dois primeiros nós e o peso 10 faz o terceiro ser o executor preferido do backup.

Nunca publique chaves reaisChaves de acesso coladas em chat, ticket ou repositório devem ser consideradas vazadas: gere novas no object storage e mantenha o YAML com chmod 600.

Cada opção do bloco minio

Opção	O que faz	Padrão / recomendação
endpoint	Endereço do servidor MinIO (URL ou IP:porta). Obrigatório.	Ex.: `minio.exemplo.com.br:9000`.
endpointMap	Mapa host:porta do nó → endpoint. Permite que agents atrás de redes diferentes usem endpoints diferentes para o mesmo storage (disponível desde a 2.8.0).	Só se houver mais de um caminho de rede para o mesmo MinIO.
bucket	Nome do bucket. Obrigatório. O PBM não o cria.	Bucket exclusivo do PBM.
prefix	Caminho dentro do bucket. Sem prefixo, os dados vão para a raiz.	Um prefixo por cluster/ambiente. Nunca dois clusters no mesmo prefixo.
region	Região do bucket. Se omitida, o PBM usa `us-east-1`.	Defina sempre. Em campo, a falta de região explícita contribuiu para timeouts de TLS sob upload concorrente.
secure	Usa HTTPS (`true`) ou HTTP (`false`) entre PBM e storage.	Padrão false. Em MinIO com TLS, defina `true`.
insecureSkipTLSVerify	Desativa a validação do certificado (certificado autoassinado).	Padrão false. Evite: prefira instalar a CA no host. Risco de man-in-the-middle.
forcePathStyle	Força acesso path-style (`https://endpoint/bucket`) em vez de virtual-hosted (`https://bucket.endpoint`).	Padrão false neste tipo. Sem DNS wildcard no MinIO, defina `true`.
credentials.access-key-id / secret-access-key	Chaves de acesso. Obrigatórias.	Usuário MinIO dedicado, com política restrita ao bucket.
credentials.session-token	Token para credenciais temporárias.	Normalmente vazio.
credentials.signature-ver	Versão da assinatura (`V2` ou `V4`).	Padrão `V4`. `V2` só para storages antigos.
partSize	Tamanho (bytes) de cada parte do upload multipart.	Padrão 10 MB. Em backups grandes e links bons, 32 a 64 MB reduz requisições.
retryer.numMaxRetries	Máximo de tentativas de upload após falha. Zero desativa.	Padrão 10.
maxObjSizeGB	Tamanho máximo de arquivo no storage. Arquivos maiores são divididos em partes.	Padrão 5018. Reduza se houver limite no MinIO ou em proxy.
debugTrace	Se `true`, escreve o trace HTTP no `pbm logs`.	Padrão false. Use só para diagnóstico: gera muito log.

Alternativa: type: s3 apontando para o MinIO

O tipo s3 também funciona com MinIO. Os nomes das opções mudam em relação ao bloco minio:

storage:
  type: s3
  s3:
    endpointUrl: https://minio.exemplo.com.br:9000
    region: us-east-1
    bucket: pbm-backups
    prefix: NOME_DO_RS/producao
    forcePathStyle: true
    credentials:
      access-key-id: "ACCESS_KEY"
      secret-access-key: "SECRET_KEY"
    uploadPartSize: 33554432
    retryer:
      numMaxRetries: 5
      minRetryDelay: 100ms
      maxRetryDelay: 5m

Em type: s3	Diferença
endpointUrl	Equivale ao `endpoint` do bloco minio (aqui com esquema, `https://`). Obrigatório para MinIO. O esquema define HTTP/HTTPS: não existe `secure`.
endpointUrlMap	Equivale ao `endpointMap`.
forcePathStyle	Padrão true (o inverso do bloco minio).
uploadPartSize / maxUploadParts	Parte do multipart (padrão 10 MB) e limite de partes (padrão 10.000). O PBM aumenta a parte automaticamente quando o arquivo excede o limite.
retryer.numMaxRetries / minRetryDelay / maxRetryDelay	Tentativas (padrão 3) e backoff (padrão 30ms a 5m).
serverSideEncryption.*	`sseAlgorithm: aws:kms` com `kmsKeyID`, ou SSE-C com `sseCustomerAlgorithm: AES256` e `sseCustomerKey`. Perder a chave significa perder o backup.
storageClass	Classe de armazenamento (STANDARD, GLACIER...). Específico de AWS S3.
debugLogLevels	Níveis de log do SDK (`Signing`, `Retries`, `Request`, `Response` e as versões `WithBody`). As variantes com corpo podem expor credenciais: use só temporariamente.

MinIO e S3 compatíveisReferência do tipo minio: endpoint, secure, forcePathStyle, partSize, retryer e demais opções, com exemplos de YAML. AWS S3Referência do tipo s3 (AWS e compatíveis): credenciais, criptografia no servidor, classe de armazenamento e retries. Opções de storage (referência)Tabela completa de opções de storage de todos os tipos, com valores padrão e a versão em que cada opção surgiu. Múltiplos endpointsComo mapear nós para endpoints diferentes quando os agents enxergam o mesmo storage por redes distintas (endpointMap). Arquivos grandes (split/merge)Como o PBM divide arquivos grandes em partes (maxObjSizeGB) e as junta no restore, útil para coleções de centenas de GB.

Storage: filesystem (NFS)Intermediário

Diretório compartilhado, montagem obrigatória e permissões

Com type: filesystem o PBM grava os backups em um diretório. Para um cluster, o diretório precisa ser o mesmo caminho, compartilhado e montado em todos os nós (todos os pbm-agent). Em sharded cluster, isso vale para os nós de todos os shards e config servers.

O PBM não verifica se o diretório está montadoEle trata o caminho como um diretório comum. Se a montagem NFS falhar e o diretório existir vazio, o backup é gravado no disco local do nó, sem erro. Amarre o agent à montagem (passo 2) e monitore o pbm status.

Preparar o compartilhamento NFS No servidor NFS, exporte um diretório só para os nós MongoDB. No cliente, monte em todos os nós com o mesmo caminho.
Servidor: /etc/exports
```
/srv/pbm-backups  10.0.0.0/24(rw,sync,no_subtree_check)
```
Cada nó MongoDB: /etc/fstab
```
nfs.exemplo.com.br:/srv/pbm-backups  /backup/pbm  nfs4  rw,hard,noatime,_netdev  0  0
```
Shell
```
sudo mkdir -p /backup/pbm
sudo mount -a
df -h /backup/pbm
```
Não use o mesmo disco do dbPath: backup e dados disputariam I/O e um disco cheio derrubaria o mongod.
Dar permissão ao usuário do pbm-agent e amarrar o serviço à montagem Descubra com qual usuário o agent roda e garanta leitura e escrita. Em NFS, o UID/GID desse usuário deve ser igual em todos os nós, senão aparecem erros de permissão em alguns nós.
Shell
```
systemctl cat pbm-agent | grep -i '^User='
sudo chown -R mongod:mongod /backup/pbm        # ajuste para o usuário encontrado
sudo -u mongod touch /backup/pbm/.teste && sudo -u mongod rm /backup/pbm/.teste
```
sudo systemctl edit pbm-agent
```
[Unit]
RequiresMountsFor=/backup/pbm
```
Shell
```
sudo systemctl daemon-reload
sudo systemctl restart pbm-agent
```

Escrever o YAML do PBM

storage:
  type: filesystem
  filesystem:
    path: /backup/pbm
    maxObjSizeGB: 5018

backup:
  compression: s2

pitr:
  enabled: false
  oplogSpanMin: 60

restore: {}

Aplicar e validar

pbm config --file /etc/pbm-config.yaml
pbm config --list
pbm status
pbm backup --type=logical --wait
ls -lh /backup/pbm

Confira, em outro nó, que o mesmo conteúdo aparece em /backup/pbm.

Opção	O que faz	Observação
storage.type: filesystem	Seleciona o armazenamento em diretório.	Obrigatório.
filesystem.path	Caminho do diretório de backup. Obrigatório.	Igual em todos os nós; montado antes do agent subir.
filesystem.maxObjSizeGB	Tamanho máximo de arquivo (padrão 5018). Arquivos maiores são divididos.	Reduza se o NFS ou o sistema de arquivos limitar o tamanho.

FilesystemComo usar um diretório local ou NFS como storage: exigência de mesmo caminho em todos os nós, permissões e limitações. Opções de storage (referência)Tabela completa de opções de storage de todos os tipos, com valores padrão e a versão em que cada opção surgiu. Configurar o storage remotoPasso a passo oficial para definir o storage remoto com pbm config --file, incluindo como o arquivo YAML é gravado no banco e aplicado a todos os agents.

Backup

Escolher o tipo certo, executar, automatizar e reter

Tipos: lógico, físico e incrementalBásico

Matriz de suporte por edição, RTO e quando usar cada um

A escolha do tipo define o tempo de restore (RTO), o impacto no cluster, o que você consegue restaurar e quais edições do MongoDB são suportadas.

Característica	Lógico	Físico	Incremental (físico)
Como funciona	Lê os documentos via protocolo do MongoDB e envia comprimido ao storage.	Copia os arquivos do `dbPath` (WiredTiger) para o storage.	Um backup físico base completo, seguido de backups que enviam só os blocos alterados.
Edições suportadas	Percona Server (PSMDB), MongoDB Community e Enterprise.	Somente PSMDB (4.2.15-16, 4.4.6-8 e superiores, 5.0.x, 6.0.x e superiores). Community e Enterprise: não suportado.	Somente PSMDB (a partir de 4.2.24-24, 4.4.18-18, 5.0.2-1, 6.0.2-1).
Restore seletivo (db/coleção)	Sim.	Não. Sempre o dataset inteiro.	Não.
Velocidade do backup	Proporcional ao volume lógico. Mais lento em bases grandes.	Rápido: copia arquivos.	Muito rápido após a base: só o delta.
Velocidade do restore	Lenta em bases grandes: reinsere documentos e reconstrói todos os índices.	Muito mais rápida: devolve os arquivos, sem reinserir nem reindexar.	Igual ao físico, mais o tempo de aplicar a cadeia base + incrementais.
Impacto no nó durante o backup	Leitura intensa (cache e CPU). Execute em secundário.	Leitura sequencial de disco, menos CPU.	Menor ainda.
mongod durante o restore	Permanece online.	É parado e reiniciado; há janela de indisponibilidade e passos manuais após o fim.	Idem físico.
Portabilidade	Alta: tolera mudanças de versão maior e menor, útil em migração.	Baixa: a versão do PSMDB no backup e no restore deve ser da mesma versão maior.	Baixa.
Base para PITR	Sim (todas as edições).	Sim, somente PSMDB. Veja PITR com backup físico.	Sim, somente PSMDB.

Quando usar cada um

Use lógico quando

Precisa restaurar só um banco ou coleção.
Está em MongoDB Community ou Enterprise (única opção de base com PITR).
O dataset é pequeno ou médio e o RTO tolera horas.
Vai migrar entre versões, topologias ou ambientes diferentes.
Quer manter o mongod no ar durante o restore.

Use físico quando

Está em PSMDB e o dataset é grande (a documentação recomenda a partir de cerca de 100 GB).
O restore lógico ficaria inviável pelo tempo de reconstrução de índices.
Vai restaurar o cluster inteiro, na mesma versão maior.
Aceita a janela de parada do mongod no restore.

Use incremental quando

Tem PSMDB e um dataset grande com baixa taxa de mudança.
Quer reduzir a janela de backup, o tráfego de rede e o uso de storage.
Aceita uma cadeia base + incrementais mais longa no restore.

Sempre combine com PITR quando

O RPO precisa ser de minutos, não de horas.
Há risco de erro humano (DROP, update em massa) que exija voltar a um instante exato.

Em MongoDB CommunitySem backup físico e sem incremental, a estratégia é: um backup lógico completo periódico + PITR com fatias de oplog. As fatias de oplog fazem o papel de "incremental".

Observação: PITR com backup físico em datasets grandesÉ possível, mas só em Percona Server for MongoDB. Os detalhes, os limites e o passo a passo estão na seção PITR com backup físico.

Regra de bolso para o RTOMeça. Faça um restore de teste em ambiente separado e cronometre. O restore lógico de bases grandes costuma levar muito mais tempo que o backup, porque os índices são reconstruídos.

Tipos de backup e restore Lógico Físico Incremental Seletivo Baseado em snapshot Limitações conhecidas Backups em sharded clusters

Executar backupsBásico

Comandos, flags, passo a passo manual e agendamento com cron

Comandos principais

pbm backup
pbm backup --type=logical --compression=s2 --wait

pbm backup --type=physical --compression=s2 --wait

# primeira vez: cria a base
pbm backup --type=incremental --base --wait

# execuções seguintes: só o que mudou
pbm backup --type=incremental --wait

# todas as coleções de um banco
pbm backup --type=logical --ns="vendas.*"

# bancos/coleções específicos
pbm backup --type=logical --ns="vendas.pedidos,vendas.clientes,rh.*"

Opções úteis

Flag	Efeito
--type	`logical` (padrão), `physical`, `incremental`.
--base	Com `incremental`, força um novo backup base (início de uma nova cadeia).
--compression	`s2` (padrão), `gzip`, `pgzip`, `snappy`, `lz4`, `zstd` ou `none`. `s2` é o melhor equilíbrio; `zstd` comprime mais com mais CPU.
--compression-level	Nível do algoritmo escolhido.
--ns	Namespaces para backup seletivo (somente lógico).
--wait	Bloqueia até terminar e imprime o resultado. Ótimo em scripts.
--profile	Usa um perfil de storage alternativo (quando configurado) em vez do principal.

Passo a passo de um backup manual

Conferir a saúde do cluster
Shell
```
pbm status
```
Todos os agents [OK] e nenhuma operação em andamento em Currently running.

Disparar o backup

pbm backup --type=logical --compression=s2 --wait

Acompanhar (se não usou --wait)
Shell
```
pbm status
pbm logs -t 50 -e backup
```
Confirmar o resultado
Shell
```
pbm list
pbm describe-backup NOME_DO_BACKUP
```
O backup só vale se o status for done. O nome do backup é um timestamp UTC, por exemplo 2026-10-03T05:00:12Z.

Automatizar com cron

O cron não tem o seu ambiente. Carregue a URI de um arquivo protegido e chame o pbm pelo caminho absoluto.

PBM_MONGODB_URI="mongodb://pbmuser:SENHA_FORTE@no1:27017,no2:27017,no3:27017/?authSource=admin&replicaSet=NOME_DO_RS"

#!/bin/bash
set -a
. /etc/pbm-cli.env
set +a
/usr/bin/pbm backup --type=logical --compression=s2 --wait >> /var/log/pbm-backup.log 2>&1

0 2 * * 6 root /usr/local/bin/pbm-backup.sh

Estratégia típica sem incrementalUm backup lógico completo semanal, mais PITR ativo com fatias de oplog de 10 a 60 minutos. O backup completo é a "base" e o PITR cobre o intervalo entre bases.

Backup lógico Backup físico Backup incremental Backup seletivo Compressão Agendar backups Prioridade de nós Opções de backup Comandos pbm

Monitoramento, logs e retençãoIntermediário

Acompanhar operações e limpar backups e chunks de PITR

Objetivo	Comando
Visão geral (agents, operação, backups, PITR)	`pbm status`
Listar backups e janelas de PITR	`pbm list`
Listar restores executados	`pbm list --restore`
Detalhes de um backup (tipo, tamanho, nós, namespaces)	`pbm describe-backup NOME`
Detalhes de um restore	`pbm describe-restore NOME_DO_RESTORE`
Logs filtrados	`pbm logs -t 100 -e backup -s D` (`-e`: evento, `-s`: severidade, `-n`: nó)
Cancelar um backup em andamento	`pbm cancel-backup`

Retenção e limpeza

# remover um backup específico
pbm delete-backup NOME_DO_BACKUP --yes

# remover backups mais antigos que uma data (UTC)
pbm delete-backup --older-than="2026-09-01T00:00:00" --yes

# remover só os chunks de PITR antigos
pbm delete-pitr --older-than="2026-09-20T00:00:00" --yes

# limpeza geral conforme a política informada
pbm cleanup --older-than="2026-09-01T00:00:00" --yes

Ordem de remoçãoAo apagar o backup base, os chunks de PITR que dependem dele deixam de ter utilidade. Mantenha sempre pelo menos um backup válido anterior à janela de PITR que você quer poder restaurar. Em incremental, não apague elos do meio da cadeia.

Listar backups Detalhes de um backup Logs Progresso do restore Cancelar backup Excluir backups Ciclo de vida dos backups Verificar status

Recuperação

PITR, restores e cenários reais de recuperação

PITR: restauração para um ponto no tempoIntermediário

Fatias de oplog sobre um snapshot base

O PITR (Point-in-Time Recovery) grava continuamente o oplog em fatias no storage. Para voltar a um instante, o PBM restaura o último backup completo anterior a ele (o snapshot base) e reaplica o oplog até o horário pedido.

PITR não substitui o backup completoSem um snapshot base, as fatias de oplog sozinhas não restauram nada (a exceção é o modo oplog-only, descrito na seção de PITR com backup físico). O PITR cobre o intervalo entre dois backups e reduz o RPO.

Observação: base do PITRA partir do PBM 2.3.0 o snapshot base pode ser lógico, físico ou incremental, e o PBM escolhe automaticamente o mais recente anterior ao horário pedido. Em MongoDB Community, a base só pode ser lógica. Veja PITR com backup físico.

Habilitar o PITR, passo a passo

Ter um backup completo recente O PITR começa a valer a partir de um snapshot. Se não existir, o PBM reporta erro de oplog insuficiente.
Shell
```
pbm backup --type=logical --wait
```
Ativar e definir o tamanho da fatia
Shell
```
pbm config --set pitr.enabled=true
pbm config --set pitr.oplogSpanMin=10
pbm config --set pitr.compression=s2
```
oplogSpanMin é o intervalo, em minutos, de cada fatia (padrão 10). Fatias menores reduzem a perda potencial, mas geram mais objetos no storage.
Verificar
Shell
```
pbm status
pbm list
```
Em PITR chunks deve aparecer o intervalo coberto. Em pbm list, a linha PITR <on> mostra as janelas restauráveis.
Desativar (quando necessário)
Shell
```
pbm config --set pitr.enabled=false
```

Opções do bloco pitr

Opção	Função
pitr.enabled	Liga/desliga o fatiamento contínuo do oplog.
pitr.oplogSpanMin	Duração de cada fatia em minutos.
pitr.compression / compressionLevel	Compressão das fatias.
pitr.priority	Pesos por nó para escolher qual nó faz o fatiamento (mesma lógica do `backup.priority`).
pitr.oplogOnly	Fatia o oplog sem exigir snapshot base, para uso com `pbm oplog-replay`. Confira a disponibilidade na página de opções do PITR da sua versão.

Horário em UTCO parâmetro --time do restore é interpretado em UTC, no formato AAAA-MM-DDTHH:MM:SS. Se o incidente foi às 15:30 no horário de Brasília (UTC-3), o horário a informar é 18:30. Para voltar antes do erro, peça um instante ligeiramente anterior (por exemplo, 1 minuto).

Erros comuns do PITR

oplog has insufficient range: não há snapshot base cobrindo o início das fatias (ou o oplog circular passou do ponto). Rode um novo pbm backup.
Depois de um restore, o PBM desativa o PITR. Reative e faça um novo backup, porque o histórico anterior ao restore não é mais uma linha do tempo contínua.
Lacunas nas fatias (nó lento, storage fora do ar) interrompem a janela restaurável: acompanhe pbm status.

PITR: visão geral PITR a partir de backup lógico PITR a partir de backup físico PITR a partir de backup seletivo Opções de PITR Replay de oplog

RestoreIntermediário

Base inteira, ponto no tempo e restore seletivo, lógico e físico

O restore é sempre iniciado pela CLI e executado pelos agents. Em todos os casos: tenha um backup recente antes de restaurar (o restore sobrescreve dados) e pare as aplicações que escrevem no banco.

Confirmação no restoreDesde o PBM 2.14.0 o restore pede confirmação antes de executar. Em scripts, acrescente -y (ou --yes) para pular o prompt.

Antes de qualquer restore

pbm status: agents OK e nada em execução.
Defina o objetivo: dataset completo, um banco, uma coleção ou um instante exato.
Confirme que o backup escolhido está em done com pbm describe-backup.
Avise os times e coloque a aplicação em manutenção.

1. Restaurar a base inteira (backup lógico)

Escolher o backup

pbm list
pbm describe-backup NOME_DO_BACKUP

Parar as aplicações Bloqueie as escritas para que ninguém grave durante o restore.
Executar
Shell
```
pbm restore NOME_DO_BACKUP --wait
```
O mongod continua online. Os dados dos namespaces presentes no backup são sobrescritos; teste antes em homologação o comportamento para namespaces que existem apenas no destino.

Acompanhar (se não usou --wait)

pbm logs -t 100 -e restore
pbm describe-restore NOME_DO_RESTORE

Validar Compare contagens de documentos, índices e uma amostra de dados críticos. Usuários e roles voltam junto com o dataset completo.
Normalizar o ambiente
Shell
```
pbm config --set pitr.enabled=true
pbm backup --type=logical --wait
```
Novo backup completo cria uma base válida após o restore. Só então libere a aplicação.

2. Restaurar a base inteira (backup físico, somente PSMDB)

Escolher o backup físico e planejar a janela de indisponibilidade.
Shell
```
pbm list
pbm describe-backup NOME_DO_BACKUP
```
Preparar o cluster Pare as aplicações. Em sharded cluster, pare o balancer e todos os mongos. Desative o PITR: restore e fatiamento de oplog não podem rodar juntos.
Shell
```
pbm config --set pitr.enabled=false
```
Executar a partir de um host com a CLI
Shell
```
pbm restore NOME_DO_BACKUP -y
```
O PBM para o mongod, restaura os arquivos e usa uma instância temporária durante o processo. O agent precisa de permissão no dbPath. O restore físico deixa o banco parado ao final.
Acompanhar Como o mongod está parado, passe o arquivo de config.
Shell
```
pbm describe-restore NOME_DO_RESTORE -c /etc/pbm-config.yaml
```
Reiniciar os serviços ao final Em todos os nós, suba o mongod e depois reinicie o pbm-agent. Em sharded cluster, religue também balancer e mongos.
Shell
```
sudo systemctl start mongod
sudo systemctl restart pbm-agent
```
Ressincronizar o catálogo do PBM
Shell
```
pbm config --force-resync
pbm status
```

Validar, fazer um novo backup e ativar o PITR.

pbm backup --type=physical --wait
pbm config --set pitr.enabled=true

CompatibilidadeO restore físico exige o mesmo tipo de servidor (PSMDB) e a mesma versão maior do backup. Em caso de dúvida, teste em um ambiente idêntico antes. Se o restore for interrompido, consulte a página oficial de restores físicos parcialmente concluídos.

3. Restaurar até um ponto no tempo (PITR)

Use quando o erro aconteceu entre dois backups (por exemplo, um dropDatabase às 14:07) e você precisa voltar ao instante imediatamente anterior.

Ver as janelas restauráveis
Shell
```
pbm list
```
Em PITR, os intervalos mostram os instantes que podem ser alcançados. O horário alvo precisa estar dentro de um deles.
Converter o horário para UTC e subtrair uma margem de segurança.
Parar as aplicações.
Executar o restore
Shell
```
pbm restore --time="2026-10-03T17:06:00" --wait
```
O PBM escolhe automaticamente o snapshot base mais recente anterior ao horário. Para forçar um base específico (o horário precisa ser posterior ao backup escolhido):
Shell
```
pbm restore --time="2026-10-03T17:06:00" --base-snapshot=NOME_DO_BACKUP --wait
```
Validar os dados no ponto restaurado.

Reativar o PITR e criar um novo backup base.

pbm config --set pitr.enabled=true
pbm backup --type=logical --wait

Quando o snapshot escolhido é físico (PSMDB), o fluxo é o da seção PITR com backup físico: mongod parado, reinício manual e --force-resync.

4. Restaurar só um banco ou uma coleção (seletivo)

Disponível a partir de backups lógicos. Pode ser feito de um backup completo ou de um backup seletivo que contenha os namespaces.

pbm restore NOME_DO_BACKUP --ns="vendas.*" --wait

pbm restore NOME_DO_BACKUP --ns="vendas.pedidos" --wait

pbm restore NOME_DO_BACKUP --ns="vendas.pedidos,vendas.clientes" --wait

pbm restore NOME_DO_BACKUP --ns-from="vendas.pedidos" --ns-to="vendas_recuperado.pedidos" --wait

pbm restore NOME_DO_BACKUP --ns="vendas.*" --with-users-and-roles --wait

Prefira clonar antes de sobrescreverQuando não tiver certeza do que foi perdido, restaure com --ns-from / --ns-to para um banco temporário, compare e só então copie os documentos necessários para o original. É a opção mais segura em produção.

Restore lógico Restore físico Restore incremental Restore seletivo Restore em novo ambiente Restore em cluster com nome diferente Opções de restore Limitações conhecidas

PITR com backup físico em datasets grandesAvançado

Somente PSMDB: compatibilidade, RTO e passo a passo

Observação: resposta curtaDá para usar, com uma condição: só em Percona Server for MongoDB (PSMDB). O restore PITR automatizado a partir de backup físico existe desde o PBM 2.2.0, e desde a 2.3.0 qualquer tipo de base (lógica, física ou incremental) é aceito. Na tabela oficial de tipos de backup, o backup físico aparece como não suportado em MongoDB Community e Enterprise, e o PITR nessas edições é somente lógico. Se o seu cluster é MongoDB Community, esta seção não se aplica diretamente: veja as alternativas no final.

Compatibilidade

Combinação	PSMDB	MongoDB Community / Enterprise
PITR + base lógica	Sim	Sim
PITR + base física	Sim (automatizado desde a 2.2.0)	Não: backup físico não é suportado
PITR + base incremental	Sim (qualquer base desde a 2.3.0)	Não: incremental não é suportado

O que muda quando o dataset é grande

O fatiamento não para durante o backup físico. Num backup lógico o PITR é desativado antes e reativado depois; no físico ele continua gravando fatias em paralelo. Se o snapshot leva horas, todo o oplog desse período fica salvo.
RTO = restore dos arquivos + replay do oplog. O restore físico é muito mais rápido que o lógico (a Percona cita 5 vezes em um dataset de 600 GB), mas o replay soma tempo proporcional ao volume de oplog entre o instante do snapshot e o horário alvo. Para limitar o replay, faça bases mais frequentes (por exemplo, incrementais).
Há janela de indisponibilidade. O mongod é parado, o balancer e os mongos precisam estar parados e não pode haver escrita durante o restore.
O horário alvo precisa estar dentro de uma janela contínua (veja pbm list) e depois do restore_to_time do snapshot escolhido.
Mesma versão maior do PSMDB no backup e no restore.
Sharded cluster: o PITR grava só em coleções que já existem. Se você criar uma coleção shardada nova, faça um novo backup para que ela entre nos próximos restores.
Desde o PBM 2.14.0 o replay é aplicado em todos os nós de cada replica set, e os membros podem ser iniciados em qualquer ordem. Antes, só o primary recebia o replay e era preciso iniciar o antigo primary primeiro. O restore também passou a pedir confirmação (-y ou --yes pula).

Passo a passo: restore PITR a partir de backup físico

Confirmar pré-condições Existe um snapshot completo e há fatias de oplog cobrindo o horário alvo.
Shell
```
pbm status
pbm list
```
Preparar o cluster Pare o balancer e os mongos (sharded), bloqueie as escritas e desative o PITR, já que restore e fatiamento de oplog são operações incompatíveis.
Shell
```
pbm config --set pitr.enabled=false
```
Executar o restore até o horário (UTC) O PBM escolhe a base mais recente anterior ao horário (física, incremental ou lógica) e reaplica o oplog.
Shell
```
pbm restore --time="2026-10-03T17:06:00" -y
```
Antes da 2.3.0, inclua --base-snapshot=NOME_DO_BACKUP.
Acompanhar sem interromper Não rode outros comandos do PBM durante o restore. Como o mongod está parado, informe o arquivo de config para ler o storage.
Shell
```
pbm describe-restore NOME_DO_RESTORE -c /etc/pbm-config.yaml
```

Passos pós-restore Ao fim, o PBM deixa o banco parado. Reinicie na ordem abaixo.

# em todos os nós
sudo systemctl restart mongod
sudo systemctl restart pbm-agent

# ressincronizar o catálogo com o storage
pbm config --force-resync

# sharded: religar balancer e mongos

Criar uma nova base e religar o PITR A linha do tempo do oplog mudou com o restore. Sem um novo backup, o PITR não tem de onde partir.
Shell
```
pbm backup --type=physical --wait
pbm config --set pitr.enabled=true
```

Recomendações de projeto para datasets grandes (PSMDB)

Sugestões de engenharia derivadas do comportamento descrito acima, não regras da documentação.

Base frequente. Um desenho comum é um incremental diário (--base semanal) com PITR em fatias de 10 minutos: o replay fica limitado a, no máximo, um dia de oplog.
Dimensione o oplog. Ele precisa cobrir a duração do backup físico e o intervalo de fatiamento com folga. Verifique com rs.printReplicationInfo() no mongosh.
Planeje o storage do PITR. Fatias acumulam rápido em bases com muita escrita: defina a retenção com pbm delete-pitr e alinhe com a retenção das bases.
Cronometre o restore. Meça o tempo total (arquivos + replay) em um ambiente de teste a cada trimestre; é esse número que define o seu RTO real.

Se o seu cluster é MongoDB Community e o dataset é grande

Lógico + PITR. É a combinação suportada. O restore é mais lento (reinserção e reconstrução de índices), então compense com bases lógicas mais frequentes e meça o RTO.
Snapshot de storage (LVM, EBS, SAN) + oplog-only. A documentação descreve o replay de oplog por cima de qualquer backup, inclusive snapshots de storage, com fatias salvas sem snapshot base obrigatório e aplicadas com pbm oplog-replay. Valide a disponibilidade do modo oplog-only na sua versão e teste o procedimento completo antes de depender dele.
Shell
```
pbm config --set pitr.oplogOnly=true
pbm config --set pitr.enabled=true

# restore: restaurar o snapshot do storage, subir o mongod e então
pbm oplog-replay --start="2026-10-03T02:00:00" --end="2026-10-03T17:06:00"
```
Migrar para PSMDB. Se o RTO de bases grandes é um requisito de negócio, avalie o PSMDB: ele habilita backup físico, incremental e PITR sobre base física.

PITR a partir de backup físico PITR: visão geral Backup físico (visão geral) Restore físico Tipos de backup (matriz de edições) Replay de oplog Opções de PITR Release notes 2.14.0 Restores físicos parciais

Cenários práticosAvançado

Outro nome, DROP acidental, migração entre clusters e prioridade de nós

Restaurar uma collection ou um banco com outro nome na mesma instância

Use quando você precisa dos dados de um backup sem tocar nos dados atuais: comparar antes de decidir, recuperar registros apagados ou validar um backup. O PBM restaura a collection ao lado da original, com os mesmos dados e índices, e a original fica intacta. Exemplo: restaurar vendas.pedidos como vendas.pedidos_recuperado.

Regras do restore com outro nome

Só em backup lógico (completo ou seletivo). Não existe em backup físico.
O PBM remapeia uma collection por restore, e o nome de origem e o de destino não podem ser iguais.
Use um nome de destino que ainda não existe. A documentação não descreve o comportamento quando o destino já existe.
Não há flag para renomear um banco inteiro de uma vez. Para um banco, repita o restore collection a collection (script abaixo).

Escolher o backup e confirmar que ele contém a collection
Shell
```
pbm list
pbm describe-backup NOME_DO_BACKUP
```
Para voltar a um instante exato, em vez de um backup, use a variante com --time do passo 2 (as fatias de PITR precisam cobrir o horário).
Restaurar com outro nome
mesmo banco, collection com novo nome
```
pbm restore NOME_DO_BACKUP --ns-from="vendas.pedidos" --ns-to="vendas.pedidos_recuperado" --wait
```
outro banco, mesmo nome de collection
```
pbm restore NOME_DO_BACKUP --ns-from="vendas.pedidos" --ns-to="vendas_recuperado.pedidos" --wait
```
até um instante exato (UTC), com as fatias de PITR
```
pbm restore --time="2026-10-03T17:06:00" --ns-from="vendas.pedidos" --ns-to="vendas.pedidos_recuperado" --wait
```
A aplicação segue usando vendas.pedidos normalmente. Garanta espaço em disco para uma cópia da collection e considere a carga da reconstrução dos índices no nó.

Conferir o resultado

use vendas
db.pedidos.countDocuments()
db.pedidos_recuperado.countDocuments()
db.pedidos_recuperado.getIndexes()

// exemplo: documentos que existem no backup e sumiram da original
db.pedidos_recuperado.aggregate([
  { $lookup: { from: "pedidos", localField: "_id", foreignField: "_id", as: "atual" } },
  { $match: { atual: { $size: 0 } } },
  { $count: "faltando_na_original" }
])

Decidir o destino dos dados recuperados
Recuperar só alguns documentos: copie da collection recuperada para a original (por exemplo, com $merge), sem sobrescrever o que já existe:
mongosh
```
db.pedidos_recuperado.aggregate([
  { $match: { /* filtro dos documentos a recuperar */ } },
  { $merge: { into: "pedidos", on: "_id", whenMatched: "keepExisting", whenNotMatched: "insert" } }
])
```
Substituir a original inteira pela recuperada: pare a escrita, renomeie com dropTarget e reinicie a aplicação. Isso apaga a collection atual: faça um backup antes.
mongosh
```
// mesmo banco
db.pedidos_recuperado.renameCollection("pedidos", true)

// de outro banco (replica set não shardado)
db.adminCommand({ renameCollection: "vendas_recuperado.pedidos", to: "vendas.pedidos", dropTarget: true })
```
Em sharded cluster, renameCollection tem restrições (não renomeia collection shardada, nem entre bancos): prefira copiar com $merge ou mongodump/mongorestore.
Limpar Quando terminar, remova a cópia temporária para liberar espaço.
mongosh
```
db.pedidos_recuperado.drop()
```

Banco inteiro com outro nome (collection a collection)

Como o PBM remapeia uma collection por restore, rode um laço que restaura cada collection do banco de origem para o banco de destino. O --wait faz cada restore terminar antes do próximo.

#!/bin/bash
set -euo pipefail
set -a; . /etc/pbm-cli.env; set +a      # PBM_MONGODB_URI

BACKUP="NOME_DO_BACKUP"
DB_ORIGEM="vendas"
DB_DESTINO="vendas_recuperado"

# lista as collections do banco de origem (exclui views e collections de sistema)
COLLS=$(mongosh "$PBM_MONGODB_URI" --quiet --eval \
  'db.getSiblingDB("'"$DB_ORIGEM"'").getCollectionInfos({type:"collection"}).map(c=>c.name).filter(n=>!n.startsWith("system.")).join("\n")')

for C in $COLLS; do
  echo "Restaurando $DB_ORIGEM.$C -> $DB_DESTINO.$C"
  pbm restore "$BACKUP" --ns-from="$DB_ORIGEM.$C" --ns-to="$DB_DESTINO.$C" --wait
done

Limitações do laço

O backup precisa conter o banco de origem inteiro (backup completo ou seletivo que o inclua).
Views não são restauradas por este caminho: recrie-as no banco de destino.
Para um banco muito grande, um cluster de apoio com mongodump/mongorestore --nsFrom/--nsTo (cenário abaixo) costuma ser mais prático.

Prefira o nome novo ao sobrescreverRestaurar com outro nome é a forma mais segura de usar um backup em produção: nada é sobrescrito até você conferir os dados.

Recuperar uma coleção em um instante exato

A documentação tem uma página própria para PITR a partir de backup seletivo; confira os requisitos nela (link ao final da seção). Se a sua versão não atende, ou se você prefere não tocar na produção, use um cluster de apoio:

Suba um replica set temporário, com pbm-agent na mesma versão e acesso somente leitura ao storage.
Aplique o mesmo bloco storage e rode pbm config --force-resync para ele enxergar o catálogo.
Restaure o instante desejado no cluster temporário: pbm restore --time="..." --wait.

Exporte só a coleção necessária e importe na produção:

mongodump --uri="mongodb://TEMP:27017" --db=vendas --collection=pedidos --archive=/tmp/pedidos.archive
mongorestore --uri="mongodb://PROD:27017" --archive=/tmp/pedidos.archive --nsFrom="vendas.pedidos" --nsTo="vendas_recuperado.pedidos"

Compare e mescle na coleção original.

Nunca ative PITR nem rode backup no cluster de apoioSe ele aponta para o mesmo bucket/prefixo da produção, ele escreveria nas mesmas pastas. Use credenciais de leitura e mantenha pitr.enabled=false.

Recuperar de um DROP acidental (banco ou coleção)

Anote o horário aproximado do erro (UTC) e pare a escrita imediatamente.
Confirme a janela com pbm list.
Se só uma parte foi afetada: restaure o ponto anterior ao erro em um banco temporário (clonagem) ou use o cluster de apoio.
Se toda a base foi afetada: pbm restore --time="..." --wait.
Reative o PITR e faça um novo backup.

Migração entre datacenters ou clusters (reaproveitando o histórico)

Copie o bucket ou diretório inteiro (incluindo o diretório de PITR) para o storage de destino.
No destino, instale o PBM na mesma versão, aplique o storage apontando para a cópia e rode pbm config --force-resync. O PBM reconstrói o catálogo a partir do storage.
Se os nomes dos replica sets forem diferentes, use o remapeamento no restore:
Shell
```
pbm restore NOME_DO_BACKUP --replset-remapping="rsDestino=rsOrigem" --wait
```
Se pbm list vier vazio mesmo com os arquivos presentes, o catálogo não foi carregado: rode o --force-resync.

Não rode pbm backup no destino enquanto ele aponta para o storage da origemVocê misturaria dois clusters no mesmo catálogo. Troque para um prefixo ou diretório próprio antes de voltar a fazer backups.

Trocar o storage de NFS (filesystem) para MinIO/S3

Crie o bucket e o usuário no MinIO.
Edite o YAML: troque o bloco storage (de filesystem para minio), mantenha o restante e confira o restore: {} na raiz.
pbm config --file /etc/pbm-config.yaml
Faça um backup completo imediatamente: o novo storage começa vazio.
Mantenha o storage antigo até vencer o período de retenção desejado.

Dar preferência a um nó para o backup (ou poupar um nó)

Use backup.priority no arquivo YAML (e pitr.priority para o fatiamento). Pesos maiores têm preferência; valores baixos poupam o nó. Aplique com --file. Em backup incremental, ao mudar a prioridade faça um novo backup base para manter a continuidade.

backup:
  priority:
    "no1.exemplo.com:27017": 0.5
    "no2.exemplo.com:27017": 2.0
    "no3.exemplo.com:27017": 1.0

Restore seletivo (inclui outro nome) Restore em novo ambiente Remapeamento de replica set PITR a partir de backup seletivo Replay de oplog Prioridade de nós Múltiplos storages Alterar número de membros

Operação e Referência

Consulta rápida, diagnóstico e ajuste fino

Cheat sheet de comandosBásico

Os comandos pbm mais usados em uma tabela

Tarefa	Comando
Estado geral	`pbm status`
Listar backups e PITR	`pbm list`
Backup lógico	`pbm backup --type=logical --wait`
Backup físico (PSMDB)	`pbm backup --type=physical --wait`
Incremental (PSMDB): base / seguintes	`pbm backup --type=incremental --base` / `pbm backup --type=incremental`
Backup seletivo	`pbm backup --ns="db.*"`
Restaurar tudo	`pbm restore NOME --wait`
Restaurar até um instante (UTC)	`pbm restore --time="2026-10-03T17:06:00" --wait`
Restore sem prompt (2.14.0+)	`pbm restore NOME -y`
Restaurar um banco / coleção	`pbm restore NOME --ns="db.*"` / `--ns="db.col"`
Restaurar com outro nome	`pbm restore NOME --ns-from="db.col" --ns-to="db2.col"`
Restaurar com outro nome até um instante (UTC)	`pbm restore --time="..." --ns-from="db.col" --ns-to="db.col_novo"`
Replay de oplog em intervalo arbitrário	`pbm oplog-replay --start="..." --end="..."`
Ligar / desligar PITR	`pbm config --set pitr.enabled=true` / `false`
Ver config	`pbm config --list`
Aplicar config	`pbm config --file /etc/pbm-config.yaml`
Ressincronizar catálogo	`pbm config --force-resync`
Detalhes de backup / restore	`pbm describe-backup NOME` / `pbm describe-restore NOME [-c arquivo.yaml]`
Logs	`pbm logs -t 100 -e backup`
Cancelar backup	`pbm cancel-backup`
Apagar backups / PITR antigos	`pbm delete-backup --older-than="DATA" -y` / `pbm delete-pitr --older-than="DATA" -y`
Versão	`pbm version`

Referência de comandos pbm PBM CLI

Referências oficiaisBásico

Documentação do PBM, MinIO e MongoDB (versão 2.16.0)

Todos os links apontam para a versão mais recente (/latest/, hoje a 2.16.0). Para a versão instalada, troque latest pelo número, por exemplo 2.15.0.

Documentação do Percona Backup for MongoDBPágina inicial e índice completo. Instalar pelos repositóriosPacotes e repositórios. Initial setupUsuário, roles, URI e agents. Configurar o storage remotoPasso a passo de configuração. MinIO e S3 compatíveisTipo minio, TLS e retries. FilesystemDiretório local ou NFS. Opções de storageTodas as opções de s3, minio, filesystem e demais. Tipos de backup e restoreMatriz de suporte por edição do MongoDB. Backup lógico / físico / incrementalExecução de cada tipo (veja o menu Backup and restore). Restore lógico, físico e seletivoProcedimentos de restore. PITR: visão geralConceito, requisitos e janelas. PITR a partir de backup físicoRestore PITR sobre base física. Replay de oplogOplog sobre qualquer backup, inclusive snapshots. Comandos pbmReferência de todos os comandos e flags. Opções de backup, restore e PITRVeja também as páginas irmãs de restore e PITR. Troubleshooting e FAQDiagnóstico e perguntas frequentes. Release notesO que mudou por versão (leia antes de atualizar). Repositório no GitHubcódigo, issues e releases. Documentação do MinIObuckets, políticas de acesso, TLS e versionamento. MongoDB: replica set oplogbase conceitual do PITR.

TroubleshootingIntermediário

Sintomas, causas prováveis e ações

Sintoma	Causa provável	Ação
`pbm status` sem agents ou com agent em erro	URI do agent errada, usuário sem permissão, `authSource`/`replicaSet` incorretos, `keyFile` divergente.	Confira `/etc/default/pbm-agent` e `journalctl -u pbm-agent`. Teste a URI com `mongosh` no próprio nó.
`pbm` sob sudo diz que falta a URI	Variável de ambiente não é herdada.	`sudo -E pbm ...` ou `--mongodb-uri`.
Falha de conexão com MinIO que usa HTTPS	No bloco `minio`, `secure` é `false` por padrão: o PBM fala HTTP com a porta TLS.	Defina `secure: true`.
Bucket não encontrado ou 403 em URL `bucket.endpoint`	Sem DNS wildcard, o acesso virtual-hosted falha. No bloco `minio`, `forcePathStyle` é `false` por padrão.	Defina `forcePathStyle: true`.
Timeout de TLS handshake no upload para MinIO	Falta de `region` explícita (consulta de localização em cada conexão) sob alta concorrência de upload.	Defina `region`. Ajuste `partSize` e `retryer`.
`x509: certificate signed by unknown authority`	Certificado autoassinado ou CA não confiada.	Instale a CA no sistema. Só como último recurso, `insecureSkipTLSVerify: true`.
Backup em filesystem "funciona" mas o NFS está vazio	Montagem NFS falhou e o PBM gravou no disco local, pois não valida a montagem.	Verifique `df -h` do caminho em todos os nós, use `RequiresMountsFor` no agent e limpe o diretório local indevido.
Permissão negada em alguns nós (filesystem)	UID/GID do usuário do agent diferente entre os nós, ou export NFS restritivo.	Padronize o UID/GID do usuário do agent e revise o export.
`oplog has insufficient range` no PITR	Sem snapshot base cobrindo o início das fatias.	Novo `pbm backup`; depois confirme `pbm status`.
`pbm list` vazio após trocar/copiar o storage	Catálogo no banco não reflete o conteúdo do storage.	`pbm config --force-resync`.
`connection refused` em `localhost:27017` no meio do backup	mongod reiniciou (frequentemente OOM-kill por cache do WiredTiger grande demais).	Verifique `dmesg` e `journalctl`. Reduza `wiredTigerCacheSizeGB` e use `backup.priority` para poupar o nó afetado.
`wait for tmp users and roles replication: run out of time`	Backup muito longo com nó instável ou replicação atrasada.	Resolva a instabilidade do nó (memória/disco/rede); só depois pense em aumentar timeouts.
Config YAML aplicada mas ignorada	Indentação errada (por exemplo, `restore: {}` dentro de `backup:`).	Valide com `pbm config --list` e corrija a estrutura.
Nova operação não inicia	Outra operação (ou lock órfão) em andamento.	`pbm status`; se um backup travado, `pbm cancel-backup`.

Primeiros comandos de diagnósticopbm status, pbm logs -t 200 -s E, journalctl -u pbm-agent -n 200, pbm config --list. Para abrir chamado, a documentação descreve como gerar um relatório de diagnóstico do PBM (link abaixo).

Diagnosticar o PBM Verificar status Relatório de diagnóstico Restores físicos parciais FAQ Logs do agent em arquivo

Configuração avançada de backup e restoreAvançado

Paralelismo, timeouts e ajustes por chave

Chave	O que controla
backup.compression / compressionLevel	Algoritmo e nível padrão dos backups (podem ser sobrescritos por flag).
backup.numParallelCollections	Quantas coleções são lidas em paralelo. O padrão é metade das CPUs. Aumentar acelera, mas eleva carga no nó.
backup.priority	Mapa host:peso para eleger o nó executor.
backup.timeouts.startingStatus	Tempo, em segundos, que o PBM espera os nós assumirem o comando antes de falhar o início do backup. Ajuda em clusters lentos, mas não corrige falhas de causa raiz.
restore.batchSize	Tamanho do lote de documentos inseridos no restore lógico.
restore.numInsertionWorkers	Workers de inserção por coleção no restore lógico.
restore.numDownloadWorkers / downloadChunkMb / maxDownloadBufferMb	Paralelismo e memória do download do storage durante o restore.
restore.mongodLocation / mongodLocationMap	Caminho do binário `mongod` usado no restore físico, global ou por nó.

A lista completa e os padrões por versão estão nas páginas de opções oficiais abaixo. Meça antes de otimizar: rode primeiro com os padrões, registre tempos e CPU, e só então ajuste um parâmetro por vez.

Config em clusterComo a configuração é guardada no cluster e aplicada a todos os agents, e o que muda em sharded clusters. Opções de backup Opções de restore Opções de PITR Opções de log Opções do pbm-agent Configuração via pipelines

Percona Backupfor MongoDB

Fundamentos e Preparação

pbm-agent

pbm (CLI)

Storage remoto

Coleções de controle

Detalhes e exemplos por tópico

Requisitos de sistema

Instalar pelos repositórios

Initial setup

Autenticação no MongoDB

Roles do usuário PBM

Credenciais com systemd

Iniciar o pbm-agent

Upgrade do PBM

Tipos de storage suportados

Fluxo para configurar qualquer storage

Comandos de configuração

Detalhes e exemplos por tópico

Configurar o storage remoto

Visão geral dos storages

MinIO e S3 compatíveis

Filesystem

AWS S3

Opções de storage (referência)

Múltiplos endpoints

Arquivos grandes (split/merge)

Config em cluster

Exemplo completo de produção (dados mascarados)

Por que cada escolha

Cada opção do bloco minio

Alternativa: type: s3 apontando para o MinIO

Backup

Quando usar cada um

Use lógico quando

Use físico quando

Use incremental quando

Sempre combine com PITR quando

Comandos principais

Opções úteis

Passo a passo de um backup manual

Automatizar com cron

Retenção e limpeza

Recuperação

Habilitar o PITR, passo a passo

Opções do bloco pitr

Antes de qualquer restore

1. Restaurar a base inteira (backup lógico)

2. Restaurar a base inteira (backup físico, somente PSMDB)

3. Restaurar até um ponto no tempo (PITR)

4. Restaurar só um banco ou uma coleção (seletivo)

Compatibilidade

O que muda quando o dataset é grande

Passo a passo: restore PITR a partir de backup físico

Recomendações de projeto para datasets grandes (PSMDB)

Se o seu cluster é MongoDB Community e o dataset é grande

Banco inteiro com outro nome (collection a collection)

Operação e Referência

Percona Backup
for MongoDB