mongorestore --drop revert possible ?

159 views
Skip to first unread message

Daniel Wijnands

unread,
May 6, 2015, 11:33:23 PM5/6/15
to mongod...@googlegroups.com
Hi 

My hostfile got screwed up so i restored the wrong data to a production database 
The production database is a replica set of 4 machines. 

I restored data with mongorestore --drop 

Is is possible to revert the data to a point in time with the journal. 
I have a backup and a logging wich i could use to do a restore but that would be a lot of work. 

Just wanted to ask if there is a shortcut  :) 

Kind regards daniel

Stephen Steneker

unread,
May 7, 2015, 1:54:02 AM5/7/15
to mongod...@googlegroups.com, dan...@itxl.nl
On Thursday, 7 May 2015 13:33:23 UTC+10, Daniel Wijnands wrote:
My hostfile got screwed up so i restored the wrong data to a production database 
The production database is a replica set of 4 machines. 

I restored data with mongorestore --drop 

Is is possible to revert the data to a point in time with the journal. 

Hi Daniel,

The MongoDB journal is for automatic recovery of data to a consistent state if mongod is unexpectedly shutdown: http://docs.mongodb.org/manual/core/journaling/.

Perhaps you are thinking of the operation log (oplog), which is used for replication? The oplog on its own is generally not useful for restoring missing data unless you happen to have done a full mongorestore/mongoimport of the data which is fully present in the current oplog. The oplog is a capped collection which means that the space is reused over time and you should only expect to find recent inserted documents and incremental changes to existing documents.


I have a backup and a logging wich i could use to do a restore but that would be a lot of work. 

Restoring from a backup is likely the best approach. How old is your last full backup?

You might be able to use a combination of restoring from backup and then replaying oplog changes up to the point in time where you did the accidental collection drop. This approach would assume that your oplog still has a point in common with the most recent full backup.

For an example of oplog replay, see Asya's answer on this question: http://stackoverflow.com/questions/15444920/modify-and-replay-mongodb-oplog.

Another option to consider in future would be adding a delayed secondary to your replica set: http://docs.mongodb.org/manual/tutorial/configure-a-delayed-replica-set-member/. With a delayed secondary the collection drop would not have been applied immediately so you would have opportunity to isolate the delayed secondary and copy the data.

Regards,
Stephen

Reply all
Reply to author
Forward
0 new messages