（一）MongoDB恢復概述
對於任何資料庫，如果要將資料庫恢復到過去的任意時間點，否需要有過去某個時間點的全備+全備之後的重做日誌。
接下來根據瑞麗航空的情況進行概述：
全備：每天晚上都會進行備份；
重做日誌備份：MongoDB只有開啟主從複製或者副本集時才會開啟重做日誌，主從複製存放在local資料庫下的“oplog.$main”集合中，複製集的日誌存放在local資料庫下的oplog.rs集合中，該集合是一個上限集合，當達到固定大小時，最老的記錄會被自動覆蓋。因此需要注意，MongoDB的重做日誌並不會一直儲存著，能否恢復到故障點，完全取決於日誌是否完整。
（二）基礎環境
本次測試備份恢復使用的是MongoDB 4.2版本副本集環境，副本集配置如下：
rstest:PRIMARY> rs.config() { "_id" : "rstest", "version" : 2, "protocolVersion" : NumberLong(1), "writeConcernMajorityJournalDefault" : true, "members" : [ { "_id" : 0, "host" : "192.168.10.41:27017", "arbiterOnly" : false, "buildIndexes" : true, "hidden" : false, "priority" : 3, "tags" : { }, "slaveDelay" : NumberLong(0), "votes" : 1 }, { "_id" : 1, "host" : "192.168.10.42:27017", "arbiterOnly" : false, "buildIndexes" : true, "hidden" : false, "priority" : 2, "tags" : { }, "slaveDelay" : NumberLong(0), "votes" : 1 }, { "_id" : 2, "host" : "192.168.10.43:27017", "arbiterOnly" : false, "buildIndexes" : true, "hidden" : false, "priority" : 1, "tags" : { }, "slaveDelay" : NumberLong(0), "votes" : 1 } ], "settings" : { "chainingAllowed" : true, "heartbeatIntervalMillis" : 2000, "heartbeatTimeoutSecs" : 10, "electionTimeoutMillis" : 10000, "catchUpTimeoutMillis" : -1, "catchUpTakeoverDelayMillis" : 30000, "getLastErrorModes" : { }, "getLastErrorDefaults" : { "w" : 1, "wtimeout" : 0 }, "replicaSetId" : ObjectId("5f32312d4911b68cdaac02a6") } } rstest:PRIMARY>
（三）確認日誌儲存情況
oplog是一個上限集合，當資料量達到一定大小後，MongoDB會自動清理oplog日誌資訊，為了保證恢復能夠正常進行，需要確認日誌的時間是否符合還原需求。簡單來說，oplog應該儲存著自上一次備份以來的所有日誌。可以使用下面方法來確認最早的oplog。
方法：檢視主從複製資訊
在主節點檢視日誌資訊，可以看到oplog日誌大小，因為oplog是一個固定大小的集合，所以還可以看到日誌的開始、結束時間、oplog的時間差等。
rstest:PRIMARY> db.printReplicationInfo() configured oplog size: 1687.392822265625MB log length start to end: 246186secs (68.39hrs) oplog first event time: Tue Aug 11 2020 13:48:29 GMT+0800 (CST) oplog last event time: Fri Aug 14 2020 10:11:35 GMT+0800 (CST) now: Fri Aug 14 2020 10:11:36 GMT+0800 (CST)
（四）模擬將MongoDB恢復到任意時間點
（4.1）案例一：將整個例項恢復到某個時間點
（4.1.1）故障場景描述
業務人員發現多個MongoDB資料庫均存在資料錯誤的情況，需要將全部資料恢復到過去的某個時刻。
（4.1.2）資料恢復方法描述
只要確定了恢復時間點，就可以使用完全備份+oplog備份，將資料恢復到過去的某個時刻。
（4.1.3）恢復過程
STEP1：模擬業務正常執行，資料正常進入MongoDB資料庫
use db1 db.db1test.insert({id:1,name:'a'}) db.db1test.insert({id:2,name:'b'}) use db2 db.db2test.insert({id:11,name:'aa'}) db.db2test.insert({id:22,name:'bb'})
STEP2：執行完整備份
mongodump --authenticationDatabase admin -ulijiaman -plijiaman -o /root/backup/full
STEP3：再次模擬業務正常執行，資料正常進入MongoDB資料庫
use db1 db.db1test.insert({id:3,name:'c'}) use db2 db.db2test.insert({id:33,name:'cc'})
最終資料如下：
rstest:PRIMARY> use db1 switched to db db1 rstest:PRIMARY> db.db1test.find() { "_id" : ObjectId("5f35f4ed09eccc387e65cd86"), "id" : 1, "name" : "a" } { "_id" : ObjectId("5f35f4ed09eccc387e65cd87"), "id" : 2, "name" : "b" } { "_id" : ObjectId("5f35f57409eccc387e65cd8a"), "id" : 3, "name" : "c" } rstest:PRIMARY> use db2 switched to db db2 rstest:PRIMARY> db.db2test.find() { "_id" : ObjectId("5f35f4ed09eccc387e65cd88"), "id" : 11, "name" : "aa" } { "_id" : ObjectId("5f35f4ee09eccc387e65cd89"), "id" : 22, "name" : "bb" } { "_id" : ObjectId("5f35f57509eccc387e65cd8b"), "id" : 33, "name" : "cc" }
STEP4：模擬資料誤操作
# db1的db1test集合id增加100 use db1 db.db1test.update({},{$inc:{"id":100}},{multi:true}) # db2的db2test集合被刪除 use db2 db.db2test.drop()
錯誤執行之後的結果：
rstest:PRIMARY> use db1 switched to db db1 rstest:PRIMARY> db.db1test.find() { "_id" : ObjectId("5f35f4ed09eccc387e65cd86"), "id" : 101, "name" : "a" } { "_id" : ObjectId("5f35f4ed09eccc387e65cd87"), "id" : 102, "name" : "b" } { "_id" : ObjectId("5f35f57409eccc387e65cd8a"), "id" : 103, "name" : "c" } rstest:PRIMARY> use db2 switched to db db2 rstest:PRIMARY> db.db2test.find() rstest:PRIMARY>
要求把所有資料庫的資料恢復到STEP4之前的狀態。
STEP5：停止業務，不再往資料庫寫資料
STEP6：備份日誌。可以備份部分日誌，也可以備份全部日誌
mongodump --authenticationDatabase admin -ulijiaman -plijiaman -d local -c oplog.rs -o /root/backup/oplog/
STEP7：確認資料異常時間點，對oplog集合進行分析
use local db.oplog.rs.find( { $and : [ {"ns" : /db1/}, {"op" : "u" } ] } ).sort({ts:1})
查詢結果如下，可以確認，開始對db1.db1test集合更新的時間為Timestamp(1597371835, 2)
/* 1 */ { "ts" : Timestamp(1597371835, 2), "t" : NumberLong(7), "h" : NumberLong(0), "v" : 2, "op" : "u", "ns" : "db1.db1test", "ui" : UUID("b3566a31-f6c1-4052-82a9-90f70728c41c"), "o2" : { "_id" : ObjectId("5f35f4ed09eccc387e65cd86") }, "wall" : ISODate("2020-08-14T02:23:55.576Z"), "o" : { "$v" : 1, "$set" : { "id" : 101.0 } } } /* 2 */ { "ts" : Timestamp(1597371835, 3), "t" : NumberLong(7), "h" : NumberLong(0), "v" : 2, "op" : "u", "ns" : "db1.db1test", "ui" : UUID("b3566a31-f6c1-4052-82a9-90f70728c41c"), "o2" : { "_id" : ObjectId("5f35f4ed09eccc387e65cd87") }, "wall" : ISODate("2020-08-14T02:23:55.578Z"), "o" : { "$v" : 1, "$set" : { "id" : 102.0 } } } /* 3 */ { "ts" : Timestamp(1597371835, 4), "t" : NumberLong(7), "h" : NumberLong(0), "v" : 2, "op" : "u", "ns" : "db1.db1test", "ui" : UUID("b3566a31-f6c1-4052-82a9-90f70728c41c"), "o2" : { "_id" : ObjectId("5f35f57409eccc387e65cd8a") }, "wall" : ISODate("2020-08-14T02:23:55.578Z"), "o" : { "$v" : 1, "$set" : { "id" : 103.0 } } }
STEP8：執行完全備份的恢復
需要注意，考慮是否需要使用"--drop"選項，如果不用該選項，會保留集合中當前的資料，如果使用了drop選項，在匯入集合時會先刪除集合。這裡使用該選項
mongorestore --authenticationDatabase admin -ulijiaman -plijiaman --port=27017 --drop /root/backup/full/確認全量恢復的資料，已經恢復回來
rstest:PRIMARY> use db1 switched to db db1 rstest:PRIMARY> db.db1test.find() { "_id" : ObjectId("5f35f4ed09eccc387e65cd86"), "id" : 1, "name" : "a" } { "_id" : ObjectId("5f35f4ed09eccc387e65cd87"), "id" : 2, "name" : "b" } rstest:PRIMARY> use db2 switched to db db2 rstest:PRIMARY> db.db2test.find() { "_id" : ObjectId("5f35f4ed09eccc387e65cd88"), "id" : 11, "name" : "aa" } { "_id" : ObjectId("5f35f4ee09eccc387e65cd89"), "id" : 22, "name" : "bb" } rstest:PRIMARY>
STEP9：使用oplog執行增量恢復
在恢復oplog之前，需要對其格式進行處理，否則會報錯
[root@node1 local]# mongorestore --authenticationDatabase admin -ulijiaman -plijiaman --port=27017 --oplogReplay --oplogLimit "1597371835:2" /root/backup/oplog/local 2020-08-14T10:44:45.120+0800 preparing collections to restore from 2020-08-14T10:44:45.120+0800 don't know what to do with file "/root/backup/oplog/local/oplog.rs.bson", skipping... 2020-08-14T10:44:45.120+0800 don't know what to do with file "/root/backup/oplog/local/oplog.rs.metadata.json", skipping... 2020-08-14T10:44:45.120+0800 Failed: no oplog file to replay; make sure you run mongodump with --oplog 2020-08-14T10:44:45.120+0800 0 document(s) restored successfully. 0 document(s) failed to restore.
需要把oplog.rs.metadata.json 檔案刪除，把oplog.rs.bson名字改為oplog.bson
[root@node1 local]# ls oplog.rs.bson oplog.rs.metadata.json [root@node1 local]# pwd /root/backup/oplog/local [root@node1 local]# rm -rf oplog.rs.metadata.json [root@node1 local]# mv oplog.rs.bson oplog.bson [root@node1 local]# ls oplog.bson
最後執行oplog增量恢復即可
# 許可權有問題，lijiaman使用者具有root角色 mongorestore --authenticationDatabase admin -ulijiaman -plijiaman --port=27017 --oplogReplay --oplogLimit "1597371835:2" /root/backup/oplog/local # 執行成功 [root@node1 local]# mongorestore --authenticationDatabase admin -uroot2 -p123456 --port=27017 --oplogReplay --oplogLimit "1597371835:2" /root/backup/oplog/local
關於恢復許可權，在MongoDB2.7也有相同的問題，見上一篇文件。
STEP10：確認資料恢復情況，發現資料以及恢復到了STEP4之前的狀態
rstest:PRIMARY> use db1 switched to db db1 rstest:PRIMARY> db.db1test.find() { "_id" : ObjectId("5f35f4ed09eccc387e65cd86"), "id" : 1, "name" : "a" } { "_id" : ObjectId("5f35f4ed09eccc387e65cd87"), "id" : 2, "name" : "b" } { "_id" : ObjectId("5f35f57409eccc387e65cd8a"), "id" : 3, "name" : "c" } rstest:PRIMARY> rstest:PRIMARY> use db2 switched to db db2 rstest:PRIMARY> db.db2test.find() { "_id" : ObjectId("5f35f4ed09eccc387e65cd88"), "id" : 11, "name" : "aa" } { "_id" : ObjectId("5f35f4ee09eccc387e65cd89"), "id" : 22, "name" : "bb" } { "_id" : ObjectId("5f35f57509eccc387e65cd8b"), "id" : 33, "name" : "cc" } rstest:PRIMARY>
至此恢復結束。
（4.2）案例二：誤刪除某個DB，對單個DB進行恢復
通常，每個DB承載不同的業務，相互之間沒有關係，如果出現故障，往往會表現在某個DB上，因此，如果出現故障，只對相應的DB進行恢復，那將減小對業務的影響。
（4.2.1）故障場景描述
假設業務執行過程中，資料庫db3被人誤刪除了，我們需要對db3進行恢復，並且不能影響到其它的DB業務。
（4.2.2）資料恢復方法描述
可以在當前例項上進行恢復，也可以新啟動一個mongod例項，用於資料恢復，我們採用新的mongod例項來恢復資料。
1.首先新啟動一個mongod例項；
2.將已有的完全備份恢復到新的例項上；
3.備份oplog，只備份db3的oplog，其它資料庫的不備份；
4.使用oplog將資料庫恢復到刪除之前；
5.檢查db3資料庫的資料，確認是否恢復回來；
6.如果第5步沒有問題，mongodump匯出db3資料庫，然後倒入到生產環境中。
（4.2.3）恢復過程
STEP1：模擬業務正常執行，資料正常進入MongoDB資料庫
use db3 db.db3test.insert({id:111,name:'aaa'}) db.db3test.insert({id:222,name:'bbb'}) db.db3test.insert({id:333,name:'ccc'})
STEP2：執行完整備份
mongodump --authenticationDatabase admin -ulijiaman -plijiaman -o /root/backup/full
STEP3：再次模擬業務正常執行，資料正常進入MongoDB資料庫
use db3 db.db3test.insert({id:444,name:'ddd'}) db.db3test.insert({id:555,name:'eee'}) db.db3test.insert({id:666,name:'fff'})
最終資料如下：
rstest:PRIMARY> db.db3test.find() { "_id" : ObjectId("5f35fff809eccc387e65cd8c"), "id" : 111, "name" : "aaa" } { "_id" : ObjectId("5f35fff809eccc387e65cd8d"), "id" : 222, "name" : "bbb" } { "_id" : ObjectId("5f35fff909eccc387e65cd8e"), "id" : 333, "name" : "ccc" } { "_id" : ObjectId("5f3600b309eccc387e65cd8f"), "id" : 444, "name" : "ddd" } { "_id" : ObjectId("5f3600b309eccc387e65cd90"), "id" : 555, "name" : "eee" } { "_id" : ObjectId("5f3600b409eccc387e65cd91"), "id" : 666, "name" : "fff" } rstest:PRIMARY>
STEP4：模擬資料誤操作
rstest:PRIMARY> db db3 rstest:PRIMARY> rstest:PRIMARY> rstest:PRIMARY> db.dropDatabase() { "dropped" : "db3", "ok" : 1, "$clusterTime" : { "clusterTime" : Timestamp(1597374734, 2), "signature" : { "hash" : BinData(0,"0uoicASFK0ppoNhIEuURwElt7Qk="), "keyId" : NumberLong("6859599294731649027") } }, "operationTime" : Timestamp(1597374734, 2) } rstest:PRIMARY>
接下來執行恢復操作。
STEP5：在發現誤操作之後，首先應該備份oplog，這裡只涉及到db3資料庫，只要備份db3的oplog即可，這樣可以加快備份恢復速度
mongodump --authenticationDatabase admin -ulijiaman -plijiaman -d local -c oplog.rs -q '{"ns":{"$regex":"db3"}}' -o /root/backup/oplog/
STEP6：先執行完全恢復
mongorestore --authenticationDatabase admin -ulijiaman -plijiaman --port=27017 -d db3 /root/backup/full/db3執行恢復後，db3資料已經恢復到了全備時的狀態
rstest:PRIMARY> show dbs admin 0.000GB config 0.000GB db1 0.000GB db2 0.000GB db3 0.000GB lijiamandb 0.000GB local 0.002GB maxiangqian 0.000GB rstest:PRIMARY> rstest:PRIMARY> use db3 switched to db db3 rstest:PRIMARY> show collections db3test rstest:PRIMARY> db.db3test.find() { "_id" : ObjectId("5f35fff809eccc387e65cd8c"), "id" : 111, "name" : "aaa" } { "_id" : ObjectId("5f35fff809eccc387e65cd8d"), "id" : 222, "name" : "bbb" } { "_id" : ObjectId("5f35fff909eccc387e65cd8e"), "id" : 333, "name" : "ccc" }
STEP7：使用oplog恢復到drop操作之前
先確認drop db3資料庫的時間點：Timestamp(1597374734, 2)
use local db.oplog.rs.find( { $and : [ {"ns" : {"$regex":"db3"}}, {"op" : "c"}, {"o" : {"dropDatabase":1}} ] } ).sort({ts:1})
結果如下
/* 1 */ { "ts" : Timestamp(1597374734, 2), "t" : NumberLong(7), "h" : NumberLong(0), "v" : 2, "op" : "c", "ns" : "db3.$cmd", "wall" : ISODate("2020-08-14T03:12:14.206Z"), "o" : { "dropDatabase" : 1 } }
執行增量恢復：
# 先處理oplog，刪除檔案oplog.rs.metadata.json，修改oplog.rs.bson為oplog.bson [root@node1 local]# pwd /root/backup/oplog/local [root@node1 local]# ls oplog.rs.bson oplog.rs.metadata.json [root@node1 local]# rm -rf oplog.rs.metadata.json [root@node1 local]# mv oplog.rs.bson oplog.bson [root@node1 local]# ls oplog.bson # 執行恢復 mongorestore --authenticationDatabase admin -ulijiaman -plijiaman --port=27017 --oplogReplay --oplogLimit "1597374734:1" /root/backup/oplog/local
特別注意：這裡發現，oplogLimit引數，在MongoDB 2.7版本中不包含後面的時間點，在4.2裡面包含後面的時間點。如果我使用時間Timestamp(1597374734, 2)來作為恢復點，則發現資料庫恢復完成又被刪除了。
檢查資料是否已經恢復，可以確認，資料已經恢復回來
rstest:PRIMARY> db.db3test.find() { "_id" : ObjectId("5f35fff809eccc387e65cd8c"), "id" : 111, "name" : "aaa" } { "_id" : ObjectId("5f35fff809eccc387e65cd8d"), "id" : 222, "name" : "bbb" } { "_id" : ObjectId("5f35fff909eccc387e65cd8e"), "id" : 333, "name" : "ccc" } { "_id" : ObjectId("5f3600b309eccc387e65cd8f"), "id" : 444, "name" : "ddd" } { "_id" : ObjectId("5f3600b309eccc387e65cd90"), "id" : 555, "name" : "eee" } { "_id" : ObjectId("5f3600b409eccc387e65cd91"), "id" : 666, "name" : "fff" }
（4.3）案例三：誤操作某個集合，對單個集合進行恢復
（4.3.1）故障場景描述
業務人員執行誤刪操DBA對資料進行恢復，詳細過程如下：
T1~T2：業務正常執行，資料正常進入資料庫
T2：使用mongodump執行資料庫完全備份
T2~T4：業務正常執行，資料正常進入資料庫
T4：使用者誤刪除資料
T4~T6：業務還在執行，但是已經出現問題，如此時還能正常插入資料，但是查詢、更新、刪除資料存在找不到資料的錯誤
T6：DBA介入資料恢復
（4.3.2）資料恢復方法描述
可以在當前例項上進行恢復，也可以新啟動一個mongod例項，用於資料恢復，我們在上一個例子中已經使用新建mongod例項的方式來恢復資料，本次實驗我們直接在生產例項上進行恢復。
1.執行完全恢復，使用完全備份，將資料庫恢復到T2時刻；
2.找到T4時刻故障之前的時間，從而確定T2~T4之間的oplog日誌。結合T2時刻的全備+ T2~T4之間的oplog日誌，實現資料恢復；（備註：這裡不需要去確認T2之後的日誌開始時間，在使用oplog恢復資料時，是通過唯一編號“_id”來運算元據的，oplog可能從全備份之前的任意時間開始，但是並不影響資料的正確性）。
3.找到T4時刻故障之後的時間，備份oplog。
4.使用oplog，實現T4~T6時間段的恢復。
（4.3.3）恢復過程
STEP1：模擬業務正常執行，資料正常進入MongoDB資料庫
use db4 db.db4test.insert({id:1111,name:'aaaa'}) db.db4test.insert({id:2222,name:'bbbb'}) db.db4test.insert({id:3333,name:'cccc'})
STEP2：執行完整備份
mongodump --authenticationDatabase admin -ulijiaman -plijiaman -o /root/backup/full
STEP3：再次模擬業務正常執行，資料正常進入MongoDB資料庫
use db4 db.db4test.insert({id:4444,name:'dddd'}) db.db4test.insert({id:5555,name:'eeee'}) db.db4test.insert({id:6666,name:'ffff'})
最終資料如下：
rstest:PRIMARY> db.db4test.find() { "_id" : ObjectId("5f36267a09eccc387e65cd92"), "id" : 1111, "name" : "aaaa" } { "_id" : ObjectId("5f36267a09eccc387e65cd93"), "id" : 2222, "name" : "bbbb" } { "_id" : ObjectId("5f36267b09eccc387e65cd94"), "id" : 3333, "name" : "cccc" } { "_id" : ObjectId("5f3628c809eccc387e65cd95"), "id" : 4444, "name" : "dddd" } { "_id" : ObjectId("5f3628c809eccc387e65cd96"), "id" : 5555, "name" : "eeee" } { "_id" : ObjectId("5f3628c909eccc387e65cd97"), "id" : 6666, "name" : "ffff" } rstest:PRIMARY>
STEP4：模擬資料誤操作，刪除2條資料
rstest:PRIMARY> db.db4test.remove({id:{$gt:4444}})
WriteResult({ "nRemoved" : 2 })
rstest:PRIMARY> db.db4test.find()
{ "_id" : ObjectId("5f36267a09eccc387e65cd92"), "id" : 1111, "name" : "aaaa" }
{ "_id" : ObjectId("5f36267a09eccc387e65cd93"), "id" : 2222, "name" : "bbbb" }
{ "_id" : ObjectId("5f36267b09eccc387e65cd94"), "id" : 3333, "name" : "cccc" }
{ "_id" : ObjectId("5f3628c809eccc387e65cd95"), "id" : 4444, "name" : "dddd" }STEP5：再次模擬業務正常執行，資料正常進入MongoDB資料庫
use db4 db.db4test.insert({id:7777,name:'gggg'}) db.db4test.insert({id:8888,name:'hhhh'}) db.db4test.insert({id:9999,name:'kkkk'})
最終資料如下：
rstest:PRIMARY> db.db4test.find() { "_id" : ObjectId("5f36267a09eccc387e65cd92"), "id" : 1111, "name" : "aaaa" } { "_id" : ObjectId("5f36267a09eccc387e65cd93"), "id" : 2222, "name" : "bbbb" } { "_id" : ObjectId("5f36267b09eccc387e65cd94"), "id" : 3333, "name" : "cccc" } { "_id" : ObjectId("5f3628c809eccc387e65cd95"), "id" : 4444, "name" : "dddd" } { "_id" : ObjectId("5f3639a009eccc387e65cd98"), "id" : 7777, "name" : "gggg" } { "_id" : ObjectId("5f3639a009eccc387e65cd99"), "id" : 8888, "name" : "hhhh" } { "_id" : ObjectId("5f3639a109eccc387e65cd9a"), "id" : 9999, "name" : "kkkk" }
此時，我們發現id為5555和6666的資料是被誤刪除的，需要恢復回來,並且要保留執行刪除命令之後的資料。
STEP6：在發現誤操作之後，首先應該備份oplog，這裡只涉及到db4.db4test集合，只要備份該集合的oplog即可，這樣可以加快備份恢復速度
mongodump --authenticationDatabase admin -ulijiaman -plijiaman -d local -c 'oplog.rs' -q '{"ns":"db4.db4test"}' -o /root/backup/oplog/
STEP7：對該集合執行完全恢復操作
mongorestore --authenticationDatabase admin -ulijiaman -plijiaman --port=27017 -d db4 -c db4test /root/backup/full/db4/db4test.bsonSTEP8：使用oplog，對該集合執行增量恢復操作
先檢視對db4.db4test集合執行刪除的開始時間Timestamp(1597389188, 1)
use local db.oplog.rs.find( { $and : [ {"ns" : /db4.db4test/}, {"op" : "d" } ] } ).sort({ts:1}) /* 1 */ { "ts" : Timestamp(1597389188, 1), "t" : NumberLong(7), "h" : NumberLong(0), "v" : 2, "op" : "d", "ns" : "db4.db4test", "ui" : UUID("75507280-3f74-4c17-a3f7-46ce7087c08a"), "wall" : ISODate("2020-08-14T07:13:08.162Z"), "o" : { "_id" : ObjectId("5f3628c809eccc387e65cd96") } } /* 2 */ { "ts" : Timestamp(1597389188, 2), "t" : NumberLong(7), "h" : NumberLong(0), "v" : 2, "op" : "d", "ns" : "db4.db4test", "ui" : UUID("75507280-3f74-4c17-a3f7-46ce7087c08a"), "wall" : ISODate("2020-08-14T07:13:08.162Z"), "o" : { "_id" : ObjectId("5f3628c909eccc387e65cd97") } }
執行增量恢復：
# 先處理oplog，刪除檔案oplog.rs.metadata.json，修改oplog.rs.bson為oplog.bson [root@mongo1 local]# pwd /root/backup/oplog/local [root@mongo1 local]# rm -rf oplog.rs.metadata.json [root@mongo1 local]# mv oplog.rs.bson oplog.bson [root@mongo1 local]# ls oplog.bson # 執行恢復 mongorestore --authenticationDatabase admin -ulijiaman -plijiaman --port=27017 --oplogReplay --oplogLimit "1597389188:1" /root/backup/oplog/local
STEP9：檢視資料是否恢復，確認已經完全恢復回來
rstest:PRIMARY> db.db4test.find() { "_id" : ObjectId("5f36267a09eccc387e65cd92"), "id" : 1111, "name" : "aaaa" } { "_id" : ObjectId("5f36267a09eccc387e65cd93"), "id" : 2222, "name" : "bbbb" } { "_id" : ObjectId("5f36267b09eccc387e65cd94"), "id" : 3333, "name" : "cccc" } { "_id" : ObjectId("5f3628c809eccc387e65cd95"), "id" : 4444, "name" : "dddd" } { "_id" : ObjectId("5f3639a009eccc387e65cd98"), "id" : 7777, "name" : "gggg" } { "_id" : ObjectId("5f3639a009eccc387e65cd99"), "id" : 8888, "name" : "hhhh" } { "_id" : ObjectId("5f3639a109eccc387e65cd9a"), "id" : 9999, "name" : "kkkk" } { "_id" : ObjectId("5f3628c809eccc387e65cd96"), "id" : 5555, "name" : "eeee" } { "_id" : ObjectId("5f3628c909eccc387e65cd97"), "id" : 6666, "name" : "ffff" }
【完】