团队从MySQL迁移到MongoDB之后，备份方案也得跟着换。不少人的做法是直接一个mongodump定时任务搞定，觉得这就够了。直到有天真需要恢复的时候才发现：mongodump只能恢复到备份那一刻的数据，中间的变更全丢了。要补上这段缺口，oplog是关键。
mongodump全量备份的正确姿势
mongodump的基本用法很简单：mongodump --host=localhost --port=27017 --out=/backup/mongo_$(date +%Y%m%d)。但有几个参数必须加上才能保证备份质量。
第一，加--oplog参数。这个参数会记录备份期间的oplog操作，保证备份期间的数据一致性，相当于MySQL的--single-transaction。对于副本集环境，这个参数是必须的。
第二，加--gzip参数压缩输出，能省掉一半以上的磁盘空间。备份文件体积直接关系到数据迁移备份的传输效率。
第三，备份完成后用mongorestore --drop在测试环境验证一次。备份文件没验证过，等于没有备份。
用oplog实现任意时间点恢复
假设全量备份是凌晨三点做的，下午两点有人误删了一个collection。只靠mongodump恢复，从三点到两点之间的所有数据变更都会丢失。这时候oplog就派上用场了。
oplog记录了MongoDB副本集的所有写操作，类似于MySQL的binlog。恢复思路是：先用mongodump恢复到凌晨三点的状态，然后从oplog中找到误删操作之前的时间戳，回放这段oplog。
具体操作：先导出oplog到本地文件mongodump --host=localhost --port=27017 -d local -c oplog.rs --out=/backup/oplog_temp，然后用mongorestore --oplogReplay --oplogLimit=时间戳:序号回放到指定位置。oplogLimit参数指定恢复到哪条oplog为止，通过这条参数精确控制恢复终点。
备份策略建议
给个实战中验证过的方案：每天凌晨一次mongodump全量备份加--oplog参数，同时持续保留oplog至少48小时。这样即使全量备份当天发生误操作，也能恢复到误操作前任意一秒的数据状态。
oplog的大小在副本集初始化时设定，默认偏小。建议根据写入量调整到至少能覆盖24小时的oplog数据。用rs.printReplicationInfo()查看当前oplog能覆盖的时间范围，不够就通过rs.reconfig()扩大。
MongoDB的备份方案核心就是全量加增量这套组合拳。把mongodump和oplog配合好，数据迁移备份的可靠性就有了基本保障。