备份进程
备份取决于数据库兼容的MongoDB 版本。 此特征兼容性版本的范围为从当前版本到前一个版本。 对于MongoDB 4.2 ， FCV可以是 4.0或4.2 。
备份进程会按照计划的快照时间间隔快照数据目录拍摄快照。 此进程会复制MongoDB部署中的数据文件，并通过MongoDB Ops Manager通过网络将其发送到现有快照存储。 在复制进程中，您的部署仍可处理读取和写入操作。
无论快照是如何存储的，备份进程都以此方式运行。
注意
使用新的备份进程时，不再有初始同步。 由于没有初始同步， MongoDB Ops Manager可以支持更大量的客户，例如大量使用renameCollection 的客户。
备份开始后， MongoDB Ops Manager会将数据备份为一个持续且连续的进程。 只要头部数据库与数据库保持同步，此进程就会继续创建快照。
此过程类似于副本集数据同步。
备份进程：
执行初始同步，以按当前状态备份所有现有数据。 在分片的集群中，这会发生在每个分分片和配置服务器上。
注意
重新启动初始同步的条件或操作
在初始同步进程，某些操作或条件可以重新启动初始同步进程。 避免以下操作和条件：
初始同步期间应避免的操作：
重新启动、关闭或更改源数据库的版本或 FCV值。
正在重命名源数据库的集合。
更改源数据库聚合管道中的$out值。
重新启动或关闭MongoDB Ops Manager应用程序或备份守护程序。
重新启动、关闭或升级MongoDB Agent 。
初始同步期间应避免的情况：
头部目录已满。
MongoDB Ops Manager组件之间的网络连接不稳定。
按照快照计划指定的频率获取部署中
data目录的快照，然后将快照传输到存储系统。重要
您可以对运行功能兼容性版本为4.0或更早版本的 MongoDB 的集群使用检查点。 检查点已从FCV为4.2或更高版本的 MongoDB 实例中删除。
持续监控oplog ，并将新的数据库操作添加到最新备份中，以使数据的本地MongoDB Ops Manager副本保持最新状态。
无论快照是如何存储的，备份进程都以此方式运行。
备份定义和运行状态
每次备份都被定义为作业。每个作业定义了备份数据的数量和频率。备份作业是按项目定义的。
操作状态
下表列出了备份作业的状态：
州 | 保留旧快照 | 创建新快照 |
|---|---|---|
Active | 是 | 是 |
Stopped | 是 | No |
Inactive | No | No |
州 | 保留旧快照 | 创建新快照 | 应用 Oplog |
|---|---|---|---|
Active | 是 | 是 | 是 |
Stopped | 是 | No | No |
Inactive | No | No | No |
更改操作状态
一旦项目的备份作业激活，无需进一步干预即可运行，直到停止或终止。操作员可以通过以下方式更改备份的状态：
初始状态(Initial State) | 所需状态 | 方法 |
|---|---|---|
Inactive | Active | 单击 Start（连接）。 |
Active | Stopped | 单击 Stop（连接）。 |
Stopped | Active | 单击 Restart（连接）。 |
Stopped | Inactive | 单击 Terminate（连接）。 警告： Terminate 会删除所有保留的备份。 |
初始状态(Initial State) | 所需状态 | 方法 |
|---|---|---|
Inactive | Active 之后 Initial Sync | 单击 Start（连接）。 |
Active | Stopped | 单击 Stop（连接）。 |
Stopped | Active 之后 Initial Sync | 单击 Restart（连接）。 |
Stopped | Inactive | 单击 Terminate（连接）。 警告： Terminate 会删除所有保留的备份。 |
重要
您可能会收到备份作业的Backup requires a resync警报。 这可能需要您重新同步备份。 这并不是一种不同的状态，而是触发了新的Backup Process Flow 。 一旦Initial
Sync完成，备份作业将再次变为Active 。
备份流程
创建备份任务后，它会经历以下流程：
当集群准备好执行计划的快照时，它会确定拍摄快照的最佳可用节点。 在大多数情况下，
mongod会将优先级从节点(secondary node from replica set)的从节点成员确定为首选快照节点。 在确定主节点 (primary node in the replica set)节点时，还可以考虑其他指标，例如从节点与从节点(secondary node from replica set)节点以及之前选择的快照成员的当前情况。一旦
mongod进程确定了快照的原始节点，备份进程就会在目标节点上打开$backupCursor。$backupCursor是一种存储引擎层机制，允许以一致的状态复制存储中的数据库文件，同时仍接受写入。MongoDB Agent Backup 功能复制并处理这些数据文件。
MongoDB Agent Backup 功能会将数据文件发送到 Ops Manager。
备份过程会收集这些文件并将其传输到您选择用于存储备份的快照存储。根据选择存储快照的快照存储，快照可以写出为：
区块到块存储。写入 Ops Manager 主机上的 MongoDB 数据库的二进制数据段。
阻止写入Amazon Web Services S3 存储桶。 这些区块的元数据会写入MongoDB MongoDB Ops Manager托管上的 数据库。
将文件快照到文件系统存储。
注意
要详细了解每种存储方法的特性，请参阅备份配置选项。
初始备份
启用备份的MongoDB Agent助手会连接到与备份作业关联的数据库，并对其进行身份验证。
初始同步开始并进入
starting阶段。 初始同步是介于Inactive和Active之间的过渡状态。 初始同步经历一系列阶段，这些阶段显示在Backup页面上以显示进度。 备份以 10 MB 压缩文档包（称为切片）的形式将现有数据流式传输到MongoDB Ops Manager 。 备份在创建快照的时间点创建切片。 快照单独启动后， MongoDB Ops Manager会捕获插入实例的数据。当切片代表备份守护程序暂时流式传输并存储在oplog 存储中时，
transferring阶段开始。备份守护程序服务不能以处理其他备份作业为代价，专注于处理大量流初始同步切片。 oplog存储会存储这些切片，直到备份守护程序可以获取它们。 oplog存储是在创建第一个快照存储时创建的。当 Backup流媒体数据时，它会oplog 。 此尾部收集备份开始时部署部署的当前状态之间的任何差异。 oplog条目以10 MB 压缩文档包（称为oplog切片）的形式发送。 这两个切片流是并行收集的，以减少构建完整快照所需的时间。
MongoDB Ops Manager收到第批处理初始同步片后，
building阶段就开始。 在此阶段， MongoDB Ops Manager在运行备份守护程序服务的托管上创建备份数据库的本地版本（称为头部数据库）。MongoDB Ops Manager使用备份守护程序服务将存储在oplog存储中的文档插入到头部数据库中。
当MongoDB Ops Manager将跟踪的oplog条目应用到头部数据库时，
applying oplogs阶段开始。在
fetching missing documents阶段， MongoDB Ops Manager会查询部署数据库以了解在文档插入期间遗漏的文档。 MongoDB Ops Manager会将部署数据库中找到的缺失文档插入到头部数据库中。插入缺失的文档后，
creating indexes阶段开始，因为MongoDB Ops Manager创建在头部数据库的部署数据库中找到的所有索引。 当索引完成时，初始同步结束，阶段变为complete。根据选择存储快照的快照存储，快照可以写出为：
块到块存储。
阻止写入Amazon Web Services S3 存储桶。 这些区块的元数据会写入MongoDB MongoDB Ops Manager托管上的 数据库。
将文件快照到文件系统存储。
注意
备份配置选项介绍了每种存储方法的特征。
后续备份
头部数据库作为部署数据库的完整副本运行。 它需要定期应用 oplog，以保持数据与部署数据库同步。 Atlas 备份快照是根据快照安排从头部数据库中存储的数据生成的。
第一次完整备份完成后，每个活动备份作业都会遵循以下进程：