Description:

According to the technical feedback, some people mistakenly deleted the online mongodb table data in the morning, the user has feedback to the customer service, now it is necessary to restore the data to the user.

The first step is to determine the schema of the database for deleted data

1.1, Single point:
If there is a backup, start an instance and import the backup data to the new instance
Find out if the new instance has deleted data, export the data using mongodump, then import to the source deleted data instance, and recover the data.
See below this chapter for details: 2.2 backup and 2.5 recovery
Single-node mongodb does not have the concept of oplog, data will be lost without backup, and replica set architecture is used where possible in formal environments.

1.2. Replica sets:
1.2.1. You can use a delay node, a PRIMARY node, one of two SECONDARY s as a delay node.
For example, if we delay the node by 8 hours, we delete the data within 8 hours to discover and restore (to ensure that the oplog is not overwritten)
1.2.2, Full + Incremental: Choose full day + hour incremental oplog backup, or full day + day incremental oplog backup, depending on the amount and importance of data.

1.3, Fragmented Cluster
A fragmented cluster is also made up of multiple replica sets, which can be backed up in accordance with the replica set backup strategy

2. Replica Set Schema Simulated Error Delete:

We use full backup + oplog incremental backup
2.1. We insert 1000 pieces of data: for (var i=0; i<1000; i++) {db.user.save ({"userid": i})}

[root@10-1-1-159 ~]# /data/mongodb3.6.9/bin/mongo  10.1.1.159:27020
rs02:PRIMARY> use jia_test
switched to db jia_test
rs02:PRIMARY> for (var i=0;i<1000;i++){ db.user.save({"userid":i})  }
rs02:PRIMARY> db.user.count()
1000
rs02:PRIMARY> db.user.find()
{ "_id" : ObjectId("5e69f820ce1bb2285a21a343"), "userid" : 0 }
{ "_id" : ObjectId("5e69f820ce1bb2285a21a344"), "userid" : 1 }
{ "_id" : ObjectId("5e69f820ce1bb2285a21a345"), "userid" : 2 }
{ "_id" : ObjectId("5e69f820ce1bb2285a21a346"), "userid" : 3 }

2.2. Let's make a full backup:

[root@10-1-1-159 ~]# /data/mongodb3.6.9/bin/mongodump -h 10.1.1.159:27020 -d jia_test -o /root/
2020-03-12T16:52:37.418+0800    writing jia_test.user to
2020-03-12T16:52:37.421+0800    done dumping jia_test.user (1000 documents)

2.3. Case 1:
If we delete it a few hours after the backup, it's too easy to simply import the data into a new instance and retrieve it.
This is only possible if we have a backup.
2.4. We continue with the second scenario

Let's continue inserting data:

[root@10-1-1-159 ~]# /data/mongodb3.6.9/bin/mongo  10.1.1.159:27020
rs02:PRIMARY> use jia_test
rs02:PRIMARY> db.user.insert({"userid" :1000})
WriteResult({ "nInserted" : 1 })
rs02:PRIMARY> db.user.insert({"userid" :1001})
WriteResult({ "nInserted" : 1 })
rs02:PRIMARY> db.user.insert({"userid" :1002})           
WriteResult({ "nInserted" : 1 })
rs02:PRIMARY> db.user.insert({"userid" :1003})          
WriteResult({ "nInserted" : 1 })
rs02:PRIMARY> db.user.insert({"userid" :1004})
WriteResult({ "nInserted" : 1 })
rs02:PRIMARY> db.user.insert({"userid" :1005})           #1. We inserted three more data         
WriteResult({ "nInserted" : 1 })
rs02:PRIMARY> db.user.remove({"userid" :1003})           #2. We deleted a piece of data       
WriteResult({ "nRemoved" : 1 })
rs02:PRIMARY> db.user.insert({"userid" :1006})            #3. We insert another piece of data    
WriteResult({ "nInserted" : 1 })
rs02:PRIMARY>

Let's recover"userid" :1003 For this data, we need to revert to the moment before deletion, that is, to the execution db.user.remove({"userid" :1003})Before this point in time.

2.5,We create a new instance of the replica set to import the full backup

[root@10-1-1-159 ~]# /data/mongodb3.6.9/bin/mongorestore -h 10.1.1.77:27010 -d jia_test /root/jia_test/
2020-03-12T17:03:27.054+0800    the --db and --collection args should only be used when restoring from a BSON file. Other uses are deprecated and will not exist in the future; use --nsInclude instead
2020-03-12T17:03:27.055+0800    building a list of collections to restore from /root/jia_test dir
2020-03-12T17:03:27.056+0800    reading metadata for jia_test.user from /root/jia_test/user.metadata.json
2020-03-12T17:03:27.074+0800    restoring jia_test.user from /root/jia_test/user.bson
2020-03-12T17:03:27.099+0800    no indexes to restore
2020-03-12T17:03:27.099+0800    finished restoring jia_test.user (1000 documents)
2020-03-12T17:03:27.099+0800    done
/data/mongodb3.6.9/bin/mongo 10.1.1.77:27010
rs02:PRIMARY> db.user.count()
1000
rs02:PRIMARY>

2.6. Export oplog log:

### First, let's look at when a delete operation was performed, and when a data instance was connected to the delete operation
[root@10-1-1-159 ~]# /data/mongodb3.6.9/bin/mongo  10.1.1.159:27020
rs02:PRIMARY> use local
switched to db local
rs02:PRIMARY> db.oplog.rs.find({"op":"d","ns":"jia_test.user"})                                               #op is an operation, d is a deletion, ns namespace is a table of a library, oplogs log explanation is described in oplog
{ "ts" : Timestamp(1584003536, 1), "t" : NumberLong(1), "h" : NumberLong("5476681688775461425"), "v" : 2, "op" : "d", "ns" : "jia_test.user", "ui" : UUID("2527737e-eeea-415b-95de-061b6615a23c"), "wall" : ISODate("2020-03-12T08:58:56.056Z"), "o" : { "_id" : ObjectId("5e69f9b02e42450b5489dd4f") } }
rs02:PRIMARY>

Known: Our full backup time: 2020-03-12T16:52:37.421+0800 done dumping jia_test.user (1000 documents)

The deletion time also knows that we need to convert the successful time of the full backup so that we get the time stamp.

Try to make the backup time ten minutes earlier so that our logs are not missing and import duplicates are automatically overwritten.

We got two timestamps:

Export oplog log log for deleted data instances (greater than backup time and less than deletion time)

 [root@10-1-1-159 ~]# /data/mongodb3.6.9/bin/mongodump -h  10.1.1.159:27020 -d local -c oplog.rs -q '{ts:{$gt:Timestamp(1584002557, 1),$lt: Timestamp(1584003536, 1)},"ns":{"$regex":"jia_test.user"}}' -o .

2.7, oplog import to new instance:

 [root@10-1-1-159 ~]# /data/mongodb3.6.9/bin/mongorestore -h 10.1.1.77:27010 –oplogReplay local/oplog.rs.bson

2.8. Connect to a new recovery instance to view:

[root@10-1-1-77 ~]# /data/mongodb3.6.9/bin/mongo 10.1.1.77:27010
rs02:PRIMARY> use jia_test
switched to db jia_test
rs02:PRIMARY> db.user.count()
1006
rs02:PRIMARY> db.user.find({"userid":1003})                                                    #View 1003 data present             
{ "_id" : ObjectId("5e69f9b02e42450b5489dd4f"), "userid" : 1003 }
rs02:PRIMARY> db.user.find({"userid":1006})                                                     #View 1006 data does not exist because it was inserted after deletion, and the time we recovered was before deletion.
rs02:PRIMARY>

2.9, Old Instance View:

[root@10-1-1-159 ~]# /data/mongodb3.6.9/bin/mongo  10.1.1.159:27020
rs02:PRIMARY> use jia_test
switched to db jia_test
rs02:PRIMARY> db.user.count()
1006
rs02:PRIMARY> db.user.find({"userid" :1003})                                                #1003 data does not exist
rs02:PRIMARY> db.user.find({"userid" :1006})                                               #1006 data exists, delete anything that you write again                                   
{ "_id" : ObjectId("5e69f9d42e42450b5489dd52"), "userid" : 1006 }  
rs02:PRIMARY>

2.10 We export the new instance data and import it into the online formal environment.

Warm Tip: For Mongodb's formal business, at least use a replica set, not a single point, data must have a backup.

Earlier, a company lost hundreds of millions of dollars by deleting data.

Data not backed up Operations and Maintenance two lines of tears