Docs 主页 → 开发应用程序 → MongoDB Manual
MongoDB 备份方法
在生产中部署 MongoDB 时，您应该制定在数据丢失事件发生时捕获和恢复备份的策略。
使用 Atlas 进行备份
MongoDB Atlas 是 Cloud 托管的 MongoDB 服务选项，可提供两种完全托管的备份方法：
使用 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 备份，请注册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 4.2+ 使用基于文件系统的备份，请尽可能使用“热”备份功能。
对于 MongoDB Enterprise 版本 4.0 及更早版本，如果您使用
AES256-GCM加密模式，请勿复制数据文件或从文件系统快照（“热”快照或“冷”快照）进行恢复。
使用文件系统快照进行备份
您可以通过制作 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选项，以在其输出oplog条目中包含mongodump操作期间出现的条目。这允许相应的mongorestore操作重放捕获的 oplog。要恢复使用--oplog创建的备份，请使用mongorestore和--oplogReplay选项。
但是，对于副本集，请考虑使用 MongoDB Cloud Manager或Ops Manager。
注意
要使用mongodump 和mongorestore 作为分片集群的备份策略，您必须停止分 片集群负载均衡器 ，并使用fsync 命令或 上的db.fsyncLock() mongos方法以阻止在备份期间对集群进行写入。
分片集群还可以使用以下协调备份和恢复流程之一，以确保跨分片事务的原子性：
有关详细信息，请参阅“使用 MongoDB 工具备份和恢复”以及“使用数据库转储备份分片集群”。