How can I do a point-in-time restore for a replica set using the oplog? and How can I do a point-in-time restore to recover an accidentally dropped collection using standard MongoDB command line tools and the replica set oplog?

on
This article explains how to do a point-in-time restore for a replica set using standard MongoDB command line tools. Point-in-time restore for a sharded cluster is beyond the scope of this article.
If you are using the backup services of MongoDB Cloud Manager or MongoDB Ops Manager, stored snapshots and custom point-in-time snapshots can be instead be managed via the respective web interface or API.

Scope/Limitations

This procedure will help you restore data from a collection in a replica set deployment up to a point-in-time before an undesired operation such as a collection drop. Data will be restored into a separate mongod deployment for recovery.
Restoring documents to the production system is outside the scope of this article. As always, if you have any questions please raise a support issue for assistance and clarification.

Requirements

Point-in-time restore is only possible via the oplog. Therefore, a standalone mongod deployment cannot perform a point-in-time restore due to the lack of an oplog collection.
The prerequisites for a point-in-time restore are:
  • a recent copy of the backup (let's say the backup is X hours old).
  • an oplog that holds more than X hours worth of data.
  • a separate standalone mongod for data recovery
If you have configured your replica set members with different oplog sizes, please use the replica set node with the largest oplog size.
Example 1: the most recent backup is 52 hours old, but there exists an oplog that holds 75 hours worth of data. In this situation, a point-in-time restore can be performed.
Example 2: the most recent backup is 100 hours old, but there exists an oplog that holds 75 hours worth of data. In this situation, a point-in-time restore cannot be performed, since there is a 25-hour discrepancy between the latest backup and the earliest oplog time.

Procedure

The following scenario assumes that a collection was accidentally dropped, and you would like to restore the database to the point before the collection was dropped.

1. Restore the most recent full backup into a standalone mongod

This standalone mongod will be used to safely perform the point-in-time restore to a backup copy of the data rather than applying changes directly to a production environment. To begin, restore the most recent backup (using any supported restoration method) into this data recovery mongod.

2. Create a mongodump of the oplog collection from the production replica set

For example:
> mongodump -d local -c oplog.rs -o oplogD

3. Move the oplog dump to its own directory and rename it to oplog.bson

For example:
> mkdir oplogR
> mv oplogD/local/oplog.rs.bson oplogR/oplog.bson

4. Find the undesired operation in the dumped oplog

There are two methods that can be used to find the undesired operation:
  1. Query the oplog collection on the original server using db.oplog.rs.find()
  2. Use the bsondump command-line tool to dump the contents of the file oplogR/oplog.bson and find the offending operation in the dumped contents.
Once the undesired operation is found, take note of its timestamp in the ts field. For example:
{
  "ts": Timestamp(1361497305, 2789),
  "t": NumberLong("1"),
  "h": NumberLong("-5184637519800765530"),
  "v": 2,
  "op": "c",
  "ns": "test.$cmd",
  "o": {
    "drop": "coll"
  }
}
The oplog entry shown above represents a db.collection.drop() command. In this case, the collection coll was dropped from the test database.

5. Replay the oplog up to the point of the undesired operation

The mongorestore command has two options, one called --oplogReplay and the other called --oplogLimit. These two options allows mongorestore to replay an oplog up to a specified point.
The command would be similar to the following:
> mongorestore -h host --port NNNN --oplogReplay --oplogLimit 1361497305:2789 oplogR
This command will restore each operation from the oplog.bson file in oplogR directory, where the parameter --oplogLimit 1361497305:2789specifies that the replay will stop just before the collection drop() command was issued.

6. The dropped collection has now been restored to the state before it was dropped.

Assuming there were no errors, you should now have the dropped collection restored in your standalone mongod. You can optionally copy the restored documents back to your production system.

Comments

Post a Comment