一 需求描述

我们知道数据是公司的重要资产，业务的系统化、信息化就是数字化。数据高效的存储与查询是系统完善和优化的方向，而数据库的稳定性、可靠性是实现的基础。高可用和RPO（RecoveryPointObjective，复原点目标，指能容忍的最大数据丢失量）是衡量一个数据库优劣的重要指标。作为一个DBA，搭建数据库可靠性体系时，一定会要考虑对数据库进行容灾备份。例如，SQL Server类型的数据库，我们一定会部署作业，定期进行完整备份、差异备份和日志备份；MySQL 数据库同样如此，也是定期进行完整备份、binlog备份等。

可能很多公司的DBA认为自己的数据库已采用了新的高可用方案，是多结点冗余了，不再需要冗余备份了，例如SQL Server 的AlwaysOn，MySQL的MHA。可是，我们还是要强调两点。

1.墨菲定律：如果有两种或两种以上的方式去做某件事情，而其中一种选择方式将导致灾难，则必定有人会做出这种选择。

过往无数的惨痛教训说明，将损失放大的原因就是备份数据也损坏了（大家不重视，实际上很可能就没做）。

2.容灾备份不仅仅可以解决物理故障，还可以将一些其它误操作回滚，将数据的损害降至最低。

数据容灾备份是为数据的灾难恢复加固了最后一道保障墙。

国务院信息化工作办公室领导编制的《重要信息系统灾难恢复指南》也对灾难恢复能力等级做了详细划分。

随着MongoDB使用的越来越普及，存储的数据越来越重要，对其进行定期备份很有必要。现在业内普遍流行的做法是每天定时进行一次全库备份，出故障时，进行全库还原。但是一天一次的备份，很难保证恢复后的数据时效性，RPO较差，会有几个小时的数据丢失。例如，每天5点进行完整备份，如果故障点是晚上20:00,那么就会丢失15个小时的数据。对比上面的“灾难恢复能力等级“”列表，会发现，我们的灾难能力等级比较低。

如果每小时做一次全部备份，那么对存储空间的要求较高，还有就是对性能也会有影响。所以，探究Mongodb的增量备还与原很有必要！！！

二 原理说明

关系型数据库，例如MySQL ,SQL Server 都有事务日志（或bin log），会将数据库的DML 、DDL、DCL等操作记录在事务文件中,可以通过日志备份来搭建增量容灾还原体系。MongoDB没有此类机制和数据文件，难以实现。但是MongoDB副本集有通过oplog（位于local数据库oplog.rs集合中） 实现节点间的同步，此集合记录了整个mongod实例在一段时间内的所有变更（插入/更新/删除）操作。基于此，是否可以考虑通过oplog.rs集合的备份还原来实现实例的增量备份与增量还原。

查看mongodb备份命令Mongodump，其中有一个相关参数oplog。

Mongodump 中--oplog参数

该参数的主要作用是在导出库集合数据的同时生成一个oplog.bson文件，里面存放了开始进行dump到dump结束之间所有的op log 操作。

注意：--oplog选项只对全库导出有效。

相应的 Mongorestore 中与 Oplog 相关的参数