Restauration à un instant donné avec rejeu de l'oplog (revenir avant un drop/delete erroné)

Commande

# 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

Ce que fait la commande

Rend la sauvegarde complète cohérente avec --oplog, puis rejoue l'oplog accumulé après la sauvegarde jusqu'à l'horodatage de l'opération erronée (drop, suppression massive), ramenant les données à ce moment.

Quand l'utiliser

Quand une collection a été supprimée par erreur ou qu'un update/delete massif défectueux a été exécuté et qu'il faut le dernier état avant les dégâts.

Attention

Restaurez vers une cible séparée, pas le système en production, et déplacez les données nécessaires après vérification. L'oplog depuis le début de la sauvegarde jusqu'à l'opération erronée doit encore être dans la fenêtre de l'oplog ; les opérations sorties de la fenêtre ne peuvent pas être récupérées. --oplog ne fonctionne qu'avec un dump complet de l'instance (il ne peut pas être combiné avec --db). Une PITR cohérente avec mongodump n'est pas possible sur un cluster shardé ; un snapshot du système de fichiers ou un produit de sauvegarde est nécessaire.