自管理部署的备份方法
在生产中部署 MongoDB 时，您应该制定在数据丢失事件发生时捕获和恢复备份的策略。
本页介绍了自管理部署的备份方法。
要详细学习；了解MongoDB Atlas中托管的部署的备份方法，请参阅备份、恢复和存档数据。
使用 MongoDB Cloud Manager 或 Ops Manager 进行备份
MongoDB Cloud Manager 是一项适用于 MongoDB 的托管备份、监控和自动化服务。MongoDB Cloud Manager 支持从图形用户界面备份和恢复 MongoDB 副本集和分片集群。
MongoDB Cloud Manager
MongoDB Cloud Manager 支持备份和恢复 MongoDB 部署。
MongoDB Cloud Manager 通过读取 MongoDB 部署中的 oplog 数据来持续备份 MongoDB 副本集和分片集群。MongoDB Cloud Manager 按设定时间间隔创建数据快照，还可以提供 MongoDB 副本集和分片集群的时间点恢复。
提示
使用其他 MongoDB 备份方法很难实现分片集群快照。
要开始使用 MongoDB Cloud Manager Backup，请注册 MongoDB Cloud Manager。有关 MongoDB Cloud Manager 的文档，请参阅 MongoDB Cloud Manager 文档。
Ops Manager
借助 Ops Manager，MongoDB 订阅者可在自己的基础设施上安装并运行支持 MongoDB Cloud Manager 的同一核心软件。Ops Manager 是一种本地部署解决方案，具有与 MongoDB Cloud Manager 类似的功能，并且可随 Enterprise Advanced 订阅提供。
有关 Ops Manager 的更多信息，请参阅 MongoDB Enterprise Advanced 页面和 Ops Manager手册。
通过复制基础数据文件进行备份
注意
使用 AES256-GCM 的加密存储引擎的注意事项
对于使用 AES256-GCM 加密模式的加密存储引擎，AES256-GCM 要求每个进程使用带有密钥的唯一计数器块值。
对于使用 AES256-GCM 密码配置的加密存储引擎：
- 从热备份恢复
- 从 4.2 开始，如果从通过“热”备份（即
mongod正在运行）获取的文件进行恢复，MongoDB 可以在启动时检测到“脏”密钥，并自动滚动更新数据库密钥以避免重用 IV（初始化向量）。
- 从冷备份恢复
不过，如果从通过“冷”备份（即
mongod未运行）获取的文件进行恢复，MongoDB 无法在启动时检测到“脏”密钥，重用 IV 将导致机密性和完整性保证失效。从 4.2 版开始，为了避免从冷文件系统快照恢复后重用密钥，MongoDB 添加了一个新的命令行选项
--eseDatabaseKeyRollover。使用--eseDatabaseKeyRollover选项启动时，mongod实例会滚动使用AES256-GCM密码配置的数据库密钥并退出。
一般来说，如果对 MongoDB Enterprise 使用基于文件系统的备份，请尽可能使用“热”备份功能。
使用文件系统快照进行备份
您可以通过制作 MongoDB 底层数据文件的副本来创建 MongoDB 部署的备份。
如果 MongoDB 存储数据文件的卷支持时间点快照，您可以使用这些快照创建某个特定时刻的 MongoDB 系统备份。文件系统快照是操作系统卷管理器的功能，不是特定于 MongoDB 的功能。通过文件系统快照，操作系统可以创建卷的快照，以用作数据备份的基准。快照的机制取决于底层存储系统。例如，在 Linux 上，Logical Volume Manager (LVM) 可以创建快照。同样，Amazon EC2 的 EBS 存储系统也支持快照。
要获得正在运行的 mongod 进程的正确快照，必须启用日志功能，并且该日志必须与其他 MongoDB 数据文件位于同一逻辑卷上。如果未启用日志功能，则无法保证快照的一致性或有效性。
要获得分片集群的一致快照，必须禁用负载均衡器，并在大约同一时间从每个分片和配置服务器上捕获快照。要备份分片集群，请参阅使用数据库转储备份自管理分片集群。
有关更多信息，请参阅使用文件系统快照备份和还原自管理部署和使用文件系统快照备份自管理分片集群，以获取有关使用 LVM 创建快照的完整说明。
使用 cp 或 rsync 备份
如果存储系统不支持快照，可以使用 cp、rsync 或类似工具直接复制文件。由于复制多个文件不是原子操作，因此必须在复制文件前停止对 mongod 的所有写入。否则，您将复制处于无效状态的文件。
通过复制底层数据生成的备份不支持副本集的时间点恢复，并且难以管理较大的分片集群。此外，这些备份更大，因为它们包括索引和重复的底层存储填充和碎片。相比之下，mongodump 创建的备份较小。
备份 mongodump
mongodump 从 MongoDB 数据库读取数据并创建高保真 BSON 文件，而 mongorestore 工具可以使用这些文件来填充 MongoDB 数据库。mongodump 和 mongorestore 是备份和恢复小型 MongoDB 部署的简单而高效的工具，但对于获取大型系统的备份不是理想的工具。
mongodump 和 mongorestore 针对正在运行的 mongod 进程进行操作，并且可以直接操作底层数据文件。默认情况下， mongodump 不捕获本地数据库的内容。
mongodump 仅捕获数据库中的文档。生成的备份节省空间，但是 mongorestore 或 mongod 必须在恢复数据后重建索引。
当连接到 MongoDB 实例时，mongodump 会对 mongod 性能产生不利影响。如果您的数据大于系统内存，查询会将工作集挤出内存，从而导致页面错误。
在 mongodump 捕获输出的同时，应用程序可以继续修改数据。对于副本集，mongodump 提供了 --oplog 选项，用于将 mongodump 操作期间出现的 oplog 条目包含在输出中。这允许相应的 mongorestore 操作重放捕获的 oplog。要恢复使用 --oplog 创建的备份，请使用 mongorestore 和 --oplogReplay 选项。
但对于副本集，可考虑使用 MongoDB Cloud Manager 或 Ops Manager。
要备份分片集群，请参阅使用数据库转储备份自管理分片集群。
注意
要使用mongodump和mongorestore作为分分片的集群的备份策略，请参阅使用数据库转储备份自管理分片集群。
分片集群还可以使用以下协调备份和恢复流程之一，以确保跨分片事务的原子性：
有关详细信息，请参阅使用 MongoDB 工具备份和恢复自管理部署，以及使用数据库转储备份自管理分片集群。