mongodb备份oplog_瞧一瞧！这儿实现了MongoDB的增量备份与还原（含部署代码）

一 需求描述

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

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

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

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

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

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

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

灾难恢复能力等级

RTO

RPO

1

2天以上

1天至7天

2

24小时以后

1天至7天

3

12小时以上

数小时至1天

4

数小时至2天

数小时至1天

5

数分钟至2天

0至30分钟

6

数分钟

0

随着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

Use oplog for taking a point-in-time snapshot

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

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

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

参数

参数说明

oplogReplay

replay oplog for point-in-time restore

oplogLimit

only include oplog entries before the provided Timestamp

oplogFile

oplog file to use for replay of oplog

仔细观察oplogReplay参数下的还原过程，我们发现，是先还原数据库文件，再重放还原oplog.bson种的数据。这就启发了我们，如果还原路径下，只有oplog.bson文件，没有数据库备份文件，是不是只进行重放还原操作。如此，如果oplog.bson中记录都是上次备份后的变化操作(op log)，还原oplog.bson就可以实现了增量还原。考虑到副本集的变化操作(op log)保存在oplog.rs集合中，只要连续从oplog.rs导出操作的相关数据进行备份，就可以实现增量备份。

即理论上，从oplog.rs导出的数据完全可以替代mongodump过程中产生的oplog.bson，进行增量还原。

实际生产中经过多次验证，也是完全可以。

-----具体原理及验证内容还可参考本人博客 --https://www.cnblogs.com/xuliuzai/p/9832333.html

三 代码实现【重点推荐】

在容灾体系建设中，既有全库的完整备份也有增量备份。下面是我们的实现代码，因为MongoDB多是在Linux系统下部署，所以这些备份代码都是通过shell语言实现。这些代码大家只要稍微改动，调整部分参数，即可部署应用。

1. 实现完整(全库)备份的代码

#!/bin/bash

sourcepath='/data/mongodb/mongobin344/bin'targetpath='/data/mongodb_back/bkXXX_2XXXX'nowtime=$(date "+%Y%m%d")

start()

{

${sourcepath}/mongodump --host 172.XXX.XXX.XXX --port 2XXXX -u 用户名-p "密码" --oplog --gzip --authenticationDatabase "admin" --out ${targetpath}/${nowtime}

}

execute()

{echo "================================ $(date) bakXXX 2XXXX mongodb back start ${nowtime}========="startif [ $? -eq 0]then

echo "The MongoDB BackUp Successfully!"

else "The MongoDB BackUp Failure"

fi}if [ ! -d "${targetpath}/${nowtime}/"]then

mkdir ${targetpath}/${nowtime}fiexecute

baktime=$(date -d '-3 days' "+%Y%m%d")if [ -d "${targetpath}/${baktime}/"]then

rm -rf "${targetpath}/${baktime}/"

echo "=======${targetpath}/${baktime}/===删除完毕=="

fi

echo "================================ $(date) bakXXX 2XXXX mongodb back end ${nowtime}========="

代码说明：

1.完整备份的脚本，通过crontab触发执行，每天执行一次。

2.备份完整后，会将三天前的备份文件自动删除。

3.sourcepath 定义了MongoDB 运行程序所在路径；targetpath定义了归档文件存放的文件夹(请提前创建)。

2. 实现增量备份的代码

#

# Thisfileis used by cron to Backup the