方案1：通过备份集恢复
如果对 MongoDB 做了全量备份 + 增量备份，那么可以通过备份集及来恢复数据。备份可以是多种形式，比如
- 通过 mongodump 等工具，对数据库产生的逻辑备份
- 拷贝 dbpath 目录产生的物理备份
- 文件系统、卷管理等产生的快照等
从这里其实也可以看出一个问题，就是「部署了多节点的复制集，为什么还需要做数据备份？」；遇到误删数据库这种问题，dropDatabase 命令也会同步到所有的备节点，导致所有节点的数据都被删除。
方案2：通过 oplog 恢复
如果部署的是 MongoDB 复制集，这时还有一线希望，可以通过 oplog 来尽可能的恢复数据；MongoDB 复制集的每一条修改操作都会记录一条 oplog，所以当数据库被误删后，可以通过重放现有的oplog来「尽可能的恢复数据」。前不久遇到的一个用户，运气非常好，数据库是最近才创建的，所有的操作都还保留在oplog里，所以用户通过oplog把所有误删的数据都找回了。
通过 oplog 恢复数据的流程非常简单，只需要把oplog集合通过mongodump导出，然后通过mongorestore 的 oplogReplay 模式重放一下。
Step1: 导出 oplog 集合
mongodump -d local -c oplog.rs -d -o backupdir
Step2: 拷贝oplog集合的数据
mkdir new_backupdir
cp backupdir/local/oplog.rs.bson new_backupdir/oplog.bson
Step3: 重放oplog
mongorestore --oplogReplay new_backupdir
方案3：通过分析数据文件恢复
MongoDB 以 bson 的格式存储数据，所以只要 dropDatbase 或 dropCollection 后ß，对应的物理数据没有从磁盘删除，就有希望恢复，但从 MongoDB 引擎的特性看，能恢复的可能性较小。
| 引擎 | mmapv1 | wiredTiger |
| dropDatabase | 数据文件立即会被删除 | 数据文件立即会被删除 |
| dropCollection | 不会立即从磁盘删除，空间会被复用 | 数据文件立即会被删除 |
从上表的描述可以看出，如果使用 mmapv1 存储引擎，dropCollection 是不会立即删除数据文件的，这种情况下，可通过分析数据文件李的bson文档来恢复数据；而其他场景的误删，数据文件会立即从磁盘删除，无法通过这种方法恢复。
总结
最后，强烈建议大家在使用 MonogDB 数据库存储重要数据时，一定要部署复制集，并做数据备份。通常2类用户不做数据备份
- 没爱过；使用 MongoDB 存储不重要的数据，丢了也无所谓；（但即使是这样，实际数据被误删时，用户还是想尽可能的恢复数据，而不是丢了「无所谓」）
- 爱过，但伤得不够深；使用 MongoDB 存储了重要的数据，但从未出过问题，于是抱着侥幸心理不对数据进行备份。不要等待受伤了再做备份，有备无患。