1. MongoDB备份方式
数据库备份，可以防止因为数据库因为误删除，或是由于人为操作失误而导致的数据损失。在生产系统中，一量重要数据被删，其结果可以是很严重的。因此在平时，需要注意对数据的保护，及时备份。并且需要定时检查备份的成效。若出现备份恢复失败，尽早排查，尽快修复。
一般而言，数据库备份分以下几种，结合MongoDB，简述一下这里所使用的方案
物理备份
热物理
经方式在数据库运行过程中，对数据库的物理文件进行拷贝。一般来说，此方式对数据库的影响较小，也是比较要取的方法。比如在MySQL运行过程中，使用xtrabackup进行备份。MongoDB企业版提供此功能，但社区版本并不支持。而Percona MongoDB 版本则支持MongoDB的在线热备份。
冷备份
若MongoDB部署为主从数据库，则可以考虑对从库进行shutdown ,然后对数据进行拷贝。此方式优点在于备份效率高，恢复容易。但缺点也比较明显，需要停掉一从库。若果在生产上使用此方案，可能还需要考虑将此节点先隐藏。以免对生产造成影响
主机层面备份
使用磁盘快照等功能，对数据库进行备份。此方案在此不作讨论。
逻辑备份
逻辑备份指将数据按特定的方式导出，在恢复时，再将相关数据写入，以此方式进行备份。比如MySQL使用mysqldump将数据按SQL语句方式导出，然后恢复时将数据重新导入。而MongoDB也有mongodump工具，可以对数据进行逻辑备份。mongodump备份出的数据是bson文件，可以用mongorestore进行恢复。
指定表的逻辑备份
因为mongodump可以指定特定的库表进行备份，因此可以根据业务重要程度及备份资源状况等对特定数据进行备份。
我们生产环境并没有使用Percona 版本MongoDB，也没有使用企业版，因此并不能对其进行在线热备
此处我们使用逻辑备份。
逻辑备份方案概述
使用pbm(Percona Backup for MongoDB)
优点：能对MongoDB备份进行统一管理，能进行增量备份；能通过简单命令对数据进行恢复
缺点：备份数据只能跟数据库服务器主一主机；需要往admin写入备份相关信息；备份文件不能进行统一管理。
基于以上特点，此处并没有使用pbm进行备份
官网https://www.percona.com/doc/percona-backup-mongodb/index.html
MongoDB Consistent Backups
此处通过脚本，使MongoDB备份具有一致性。保持一致性的意义在于，可以将整个集群恢复在某一时刻。但鉴于目前生产上的MongoDB集群基本上用于存放日志型数据，而副本集并不需要此特性（因为只有一分片）。因此此工具后来也弃用了。
https://www.percona.com/blog/2016/07/25/mongodb-consistent-backups/
自实现mongodump + oplog备份
最后一种方案，将MongoDB实例数据通过mongodump备份，并且通过程序代码将oplog实时备份下来（类似于MySQL的binlog server）当需要进行数据恢复时，可以通过mongodump进行的全备 + 收集的oplog进行恢复，可将数据恢复至某一时间点，生产环境使用此方案。下面将详述此方案
备份流程
流程图如下：
1. 判断集群架构：是副本集还是分片集群；
2. 判断后台每个副本集是否有oplog收集后台子进程；
3. 若没有，则fork后台守护子进程，不断监听收集每个副本集产生的oplog；
4. 主进程通过mongodump对全库进行导出；
5. 导出完成后，主进程退出，oplog监听子进程仍然在不断进行
6. 每次备份会收集相关的备份成功与否信息，通过钉钉进行告警，通知数据库管理员
相关oplog收集关键模块
> https://github.com/ssesse/oplog_server
收集效果：
全备:
增备：
用于实现类似于MySQL binlog server的效果
数据恢复
通过mongorestore对mongodump导出来的数据进行恢复。然后通过 --oplogReplay 将数据恢复 ，通过--oplogLimit 将数据限定恢复在特定时间 。
/opt/mongodb27001/bin/mongorestore --oplogReplay --oplogLimit /data/tmpo
