Point-in-time restore with oplog replay (return to before a bad drop/delete)

Command

# 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

What it does

Makes the full backup consistent with --oplog, then replays the oplog accumulated after the backup up to the timestamp of the bad operation (drop, bulk delete), bringing the data back to that moment.

When to use it

When a collection was dropped by mistake or a faulty bulk update/delete ran and you need the last state before the damage.

Caution

Restore to a separate target, not the live system, and move the needed data after verification. The oplog from the start of the backup to the bad operation must still be within the oplog window; operations that fell out of the window cannot be recovered. --oplog only works with a full instance dump (it cannot be combined with --db). Consistent PITR with mongodump is not possible on a sharded cluster; a file system snapshot or a backup product is required.