Restore point-in-time com replay do oplog (voltar para antes de um drop/delete indevido)

Comando

# 1) Full backup + oplog written during the backup (whole instance, from a replica set member):
mongodump --uri="mongodb://admin@mongo2:27017/?authSource=admin&readPreference=secondary" --oplog --gzip --out=/backup/full
# 2) Find the time of the bad operation (mongosh): db.getSiblingDB("local").oplog.rs.find({ "o.drop": "musteri" }).sort({ $natural: -1 }).limit(1)
# 3) Dump the oplog after the backup (t: start time of the full backup, epoch seconds):
mongodump --uri="mongodb://admin@mongo2:27017/?authSource=admin" --db=local --collection=oplog.rs --query='{"ts":{"$gte":{"$timestamp":{"t":1791400000,"i":1}}}}' --out=/backup/oplog
# 4) Restore the full backup together with its own oplog:
mongorestore --uri="mongodb://admin@target:27017/?authSource=admin" --gzip --oplogReplay /backup/full
# 5) Replay the oplog up to the bad operation (oplogLimit is exclusive):
mkdir /backup/pitr && mv /backup/oplog/local/oplog.rs.bson /backup/pitr/oplog.bson
mongorestore --uri="mongodb://admin@target:27017/?authSource=admin" --oplogReplay --oplogLimit=1791403600:1 /backup/pitr

O que faz

Torna o backup completo consistente com --oplog e depois aplica o oplog acumulado após o backup até o timestamp da operação indevida (drop, delete em massa), trazendo os dados de volta àquele momento.

Quando usar

Quando uma collection foi removida por engano ou um update/delete em massa com defeito rodou e você precisa do último estado antes do dano.

Atenção

Restaure em um destino separado, não no sistema ativo, e mova os dados necessários após a verificação. O oplog desde o início do backup até a operação indevida ainda precisa estar dentro da janela do oplog; operações que saíram da janela não podem ser recuperadas. --oplog só funciona com um dump completo da instância (não pode ser combinado com --db). PITR consistente com mongodump não é possível em um cluster shardado; é necessário um snapshot de file system ou um produto de backup.