MongoDB Ops Manager 可以将备份（包括快照和操作日志）存储在 S3 或 S3 兼容的对象存储中，方式是将备份数据以块的形式写入 S3 存储桶，并在 MongoDB Ops Manager 应用程序数据库中追踪元数据。凭借不可变 S3 备份，Ops Manager 与 S3 对象锁 或其等效版集成，以提供以下功能：
将备份数据和备份元数据一起存储在 S3 存储桶中。
防止备份对象在定义的保留期到期之前被删除或修改，这由对象存储强制执行。
将完整的时点还原链（快照和 oplog）从启用了对象锁的存储桶导入到新的或重建的 MongoDB Ops Manager 部署中，以进行灾难恢复或迁移。
使用此功能可保护备份免遭恶意或意外删除，例如勒索软件攻击或操作符错误。您可以仅使用存储在 S3 中的内容在新的Ops Manager实例中恢复备份。
本指南涵盖了直接在托管上安装和管理的 MongoDB Ops Manager 部署的不可变 S3 备份。如果您使用 MongoDB Controllers for Kubernetes 操作符 (MCK) 部署 MongoDB Ops Manager，请参阅 MongoDB Ops Manager 资源规范示例。
重要
Ops Manager 支持不可变的 S3 快照，从 8.0.19 版本开始。不可变的 S3 oplog 可以将此保护扩展到支持从完全不可变的、可导入的备份中进行时点还原，需要版本 9.0 或 8.0.28。
不可变 S3 备份的工作原理
使用启用了对象锁的存储桶配置 S3快照存储并启用不可变备份后：
Ops Manager将快照块和恢复所需的元数据写入 S3 存储桶，而不是仅将元数据保存在Ops Manager应用程序数据库中。
如果已配置， Ops Manager会延长每个快照的对象锁保留时间，以便对象存储在备份作业保留窗口结束之前防止删除或修改。
Ops Manager可以通过仅读取 S3 存储桶存储的内容，从预填充的存储桶中发现这些不可变的快照并将其导入到另一个Ops Manager实例中。
如果您还配置一个 S3 oplog 存储并启用对象锁：
MongoDB Ops Manager 将 oplog 切片和恢复所需的元数据写入 S3 oplog 存储的存储桶，与处理快照数据的方式相同。
MongoDB Agent 仅跟踪该备份作业中已提交大多数的 oplog 条目，因此 MongoDB Ops Manager 永远不会备份可能被后续回滚删除的 oplog 条目。
MongoDB Ops Manager 可以发现并将这些不可变的 oplog 与导入的不可变快照一起导入到另一个 MongoDB Ops Manager 实例中，以支持从导入的备份进行时点还原。
先决条件
要使用不可变的 S3 备份，请确保您具备以下条件：
Ops Manager 68008.0.19 或更高版本，用于不可变快照。不可变 oplog 还需要版本 79009.0 或8.0.28 7300。
在Ops Manager中配置的 S3快照存储（块存储）。不可变快照仅支持基于 S3 的快照存储，而不支持MongoDB块存储或文件系统快照存储。
支持对象锁的对象存储（例如 AWS S3 或兼容设备），且您用于存储的存储桶已启用对象锁。大多数 S3 提供商要求启用对象版本控制才能使用 Object Lock，而有些提供商仅允许在创建存储桶时启用 Object Lock。
标准备份要求，例如在适当节点上启用备份的 MongoDB Agent 以及用于 PITR 的 oplog （操作日志）存储。
一个为您的快照存储启用了对象锁的 S3 存储桶。该存储桶不一定非要是新的，也不一定非要专用于此存储，但建议使用专用存储桶。您无法通过更改 MongoDB Ops Manager 中现有 S3 快照存储配置的设置来启用对象锁。您必须配置一个新的 S3 快照存储，该存储指向启用了对象锁 (Object Lock) 的存储桶。
如果您使用不可变 oplog：一个为您的 oplog 存储启用了版本控制和对象锁的 S3 存储桶。该存储桶不一定非要是新的，也不一定非要专用于此存储，但建议使用专用存储桶。您无法通过更改现有 S3 oplog 存储的配置来在 MongoDB Ops Manager 中启用对象锁。您必须配置一个新的 S3 oplog 存储，该存储点一个启用了版本控制和对象 锁的存储桶。
Considerations
在规划不可变 S3 备份时，请考虑以下事项：
没有追溯不变性。启用不可变备份后， Ops Manager仅使用对象锁保护写入存储桶的快照。Ops Manager不会对现有快照对象应用对象锁定。
对象锁配置。Ops Manager不为不支持对象锁的 S3 存储桶提供不变性。您必须单独在存储桶上配置对象锁。在Ops Manager中配置对象锁设置或在创建存储桶后更新存储桶设置不会在存储桶上启用对象锁。
不会自动迁移现有数据。通过在 S3 存储之间迁移备份功能，您可以更改备份作业用于将来快照的 S3快照存储。它不会在存储桶之间复制或移动现有快照数据。
托管存储上的保留和对象锁。当快照根据备份作业保留策略过期时， Ops Manager会停止公开快照并尝试删除相关对象。只有在对象锁定保留期到期后， Ops Manager才能删除对象。如果对象存储拒绝删除，示例因为对象仍处于保留状态，则groom作业不会失败。 Ops Manager会对无法删除的对象进行排队，备份守护程序每
mms.backup.groom.failedDeleteRetryDelayHours小时重试删除，直到对象存储允许为止。导入存储的保留。MongoDB Ops Manager 永远不会从您导入的 S3 存储桶中删除数据。MongoDB Ops Manager 可以删除其导入到自身应用程序数据库中的元数据。保留策略仅影响 MongoDB Ops Manager 中元数据的可见性。
oplog 不可变性不具有追溯力。您只能在创建 S3 oplog 存储时启用对象锁。您无法通过更改现有 S3 oplog 存储的设置来启用对象锁；必须创建一个新存储。
oplog 版本固定默认处于关闭状态。默认情况下，MongoDB Ops Manager 在从不可变 oplog 存储中读取 oplog slice 时，不会使用它记录的确切 S3 对象版本。
brs.oplogStoreFallBackToLatestVersion应用程序设置默认为true，这会导致 MongoDB Ops Manager 始终获取对象的最新版本，而不是它记录的版本。要要求 MongoDB Ops Manager 使用确切的记录版本，全局管理员必须将brs.oplogStoreFallBackToLatestVersion设置为false。oplog 跟踪的大多数提交拓扑结构要求。Ops Manager 只跟踪启用对象锁的 oplog 存储的大多数提交的 oplog 条目，因为对象锁意味着 Ops Manager 永远不能撤销或更改已写入存储的数据。在从节点(secondary node from replica set)宕机的 PSA 拓扑结构上，或在 PAA 拓扑结构上，oplog 尾部永远无法达到大多数提交，因此，尾部追踪会停滞，直到拓扑结构恢复。发生此情况时，MongoDB Ops Manager 会发出警报，指明原因和解决方案。
警告
对于快照或 oplog 存储，MongoDB Ops Manager 不会读取存储桶的实际保留模式或期限。如果您在 MongoDB Ops Manager 中设置的保留值与您直接在 S3 存储桶上配置的保留设置不匹配，则您的备份可能无法防止删除或修改，并且如果存储桶实施了 MongoDB Ops Manager 不知道的保留策略，MongoDB Ops Manager 清理作业可能会失败。
配置不可变快照存储
要配置不可变快照存储，请完成以下任务：
在Ops Manager中启用不可变备份。
准备一个启用了 对象-锁 的 S3 存储桶。
在Ops Manager中配置新的 S3快照存储。
启用不可变备份
应用程序设置控制不可变备份。在配置带有 Object Lock 的 S3 快照存储之前，全局管理员必须启用此设置。
注意
您也可以在 conf-mms.properties 中将 brs.immutableBackupEnabled 设置为 true，而不是使用管理用户界面。如果您在两个地方都进行了设置，MongoDB Ops Manager 将使用 conf-mms.properties 值。
准备一个启用 对象-锁 的 S3 存储桶
(可选) 配置存储桶上的条件写入。
MongoDB Ops Manager 默认使用存储桶的条件写入支持，以减少不可变快照元数据使用的存储空间。配置您的存储桶以支持 条件写入。
重要
建议使用条件写入支持，但不是必需的。如果您的存储桶不支持条件写入，MongoDB Ops Manager 仍会使用对象锁保护您的快照，但存储桶的增长速度可能会超出预期。
注意
在 MongoDB Ops Manager 中，您无法为现有的 S3 快照存储配置启用对象锁。如果您已经使用 S3 存储桶进行备份，但需要不可变快照，请在提供商允许的情况下在该存储桶上启用对象锁，或者指向另一个已启用对象锁的存储桶，并配置一个新的 S3 快照存储。
在Ops Manager中配置新的 S3 快照存储
创建新的 S3快照存储。
遵循 添加一个 S3 兼容快照存储 程序，以创建一个点到启用对象锁的存储桶的新 S3 快照存储。按 S3 提供商的要求指定存储桶名称、终结点、区域和凭证。
重要
仅在创建新的 S3 快照存储时，才能选择 Object Lock Enabled。保存存储后，无法更改此设置。您可以随时更改 Object Retention Period (Days) 和 Object Retention Mode。
此快照存储用作不可变快照的目标。Ops Manager会将使用此存储的备份的快照块和元数据写入存储桶。
注意
如果使用 MongoDB Enterprise Kubernetes Operator 管理 Ops Manager，则还必须在 MongoDBOpsManager 资源中对应的 s3Stores 条目启用对象锁。将 spec.backup.s3Stores[].objectLockEnabled 字段设置为 true，以便 Kubernetes Operator 协调具有对象锁定意识的 Ops Manager。
您仍然需要一个MongoDB实例来充当Ops Manager操作的元数据存储。
配置不可变 oplog 存储
要配置不可变的 oplog 存储，请完成以下任务：
如果尚未启用，请在 MongoDB Ops Manager 中启用不可变备份。
准备一个已启用版本控制和 对象锁 的 S3 存储桶。
在 MongoDB Ops Manager 中配置新的 S3 oplog 存储。
将现有的备份作业切换到不可变的 S3 oplog 存储。
启用不可变备份
此步骤使用与不可变快照存储相同的 MongoDB Ops Manager 应用程序设置。如果您在配置不可变快照存储时已经完成了启用不可变备份，请跳过此步骤。
准备一个已启用版本控制和对象锁的 S3 存储桶
为您的不可变 oplog 存储准备一个存储桶。
(可选) 配置存储桶上的条件写入。
默认情况下，MongoDB Ops Manager 会使用存储桶的条件写入支持，以减少不可变备份元数据所占用的存储空间。配置您的存储桶以支持 条件写入。
重要
建议使用条件写入支持，但不是必需的。如果您的存储桶不支持条件写入，MongoDB Ops Manager 仍会使用对象锁保护您的 oplog，但存储桶的增长速度可能会超出预期。
注意
您无法在 MongoDB Ops Manager 中为现有的 S3 oplog 存储配置启用对象锁。如果您已经将 S3 存储桶用于 oplog 存储，但需要不可变的 oplog，请在提供商允许的情况下在该存储桶上启用版本控制和对象锁，或者指向另一个已启用这两项功能的存储桶，并配置一个新的 S3 oplog 存储。
在 MongoDB Ops Manager 中配置新的 S3 oplog 存储
将新桶配置为 S3 oplog 存储。
创建一个新的 S3 oplog 存储。
请按照添加一个 S3 兼容的 oplog 存储步骤创建一个指向点为已启用版本控制和对象锁的存储桶的新 S3 oplog 存储。根据您的 S3 提供商的要求，指定存储桶名称、终结点、区域和凭证。
设置 Object Retention Period (Days)。
输入Ops Manager使用对象锁保护每个oplog分片对象的天数。此值必须与您直接在存储桶上配置的保留期相匹配。此字段不会修改 S3 存储桶本身的保留设置， Ops Manager不会读取存储桶的对象锁配置，因此无法检测到此字段与存储桶的保留期之间的不匹配情况。您必须手动设立此字段，以匹配您在存储桶上配置的保留模式。
重要
我们建议设置此字段。如果将其留空，MongoDB Ops Manager 将无法记录存储桶的保留期实际到期的时间。MongoDB Ops Manager 会在自己的 整理逻辑认为对象符合条件时立即尝试删除该对象，但 S3 存储桶会拒绝该删除操作，直到其保留期结束。MongoDB Ops Manager 会不断重试删除，直到存储桶允许删除为止。
重要
只有在创建新的 S3 oplog 存储时，才能选择 Object Lock Enabled。保存存储后，无法更改此设置。您可以随时更改 Object Retention Period (Days) 和 Object Retention Mode。
此 oplog 存储提供服务，作为不可变 oplog 备份的目标。MongoDB Ops Manager 将使用此存储的备份的 oplog 切片和元数据写入存储桶。
将现有备份作业切换到不可变 S3 oplog 存储
要将现有的备份作业重新分配给不可变的 S3 oplog 存储，请使用分配标签：
为不可变的 S3 oplog 存储添加标签。
按照 Edit One Existing S3-Compatible oplog 存储 程序，为不可变的 S3 oplog 存储添加标签。
重要
PIT 恢复不可用，直到 MongoDB Ops Manager 在重新分配后拍摄下一个快照。
验证不可变性
MongoDB Ops Manager 会自动将每个快照的数据以及保护该数据的对象锁元数据写入 S3 存储桶。您无需手动导出数据。请按照以下步骤确认特定快照是否受对象锁保护。
要确认 S3 oplog 存储已启用对象锁，请转到oplog 存储页面并检查该存储的设置。
导入Atlas 备份快照以进行灾难恢复
如果需要从包含不可变快照和备份元数据的预先存在的 S3 存储桶中恢复数据，则可以将这些快照导入到Ops Manager部署中。将此工作流程用于灾难恢复场景，例如在重建Ops Manager后恢复备份。
重要
导入的快照仅用于一次性恢复操作。Ops Manager不管理导入快照的生命周期，也不将其包含在活动备份计划中。
选择或添加外部 S3 存储桶。
选择现有的存储桶，或者选择 Add S3 bucket 定义一个新的存储桶。桶名和 S3 终结点必须与快照的 S3 存储上配置的值一致。
重要
Add S3 bucket 表单要求提供与 添加一个 S3 兼容的快照存储 过程相同的字段，包括数据存储类型和 MongoDB 托管列表或 URI。这些字段必须点到此存储桶的专用元数据存储，而不是您正在恢复的 MongoDB 部署。
导入完成后，导入的快照将显示在 Continuous Backup 页面上，在您分配的项目下。MongoDB Ops Manager 仅显示已完全导入的集群快照。
MongoDB Ops Manager 绝不会从您导入的 S3 存储桶中删除或 groom 数据。您可以在对象存储层控制导入的快照对象的生命周期。MongoDB Ops Manager 可以删除其导入到自身应用程序数据库中的元数据。
导入 Oplog 以进行灾难恢复
如果您需要从包含不可变 oplog 的现有 S3 存储桶中恢复时点还原数据，则可以将这些 oplog 导入到 MongoDB Ops Manager 部署中。您必须先导入相应的快照。MongoDB Ops Manager 只能发现已导入快照的集群的 oplog。
重要
如果 MongoDB Ops Manager 在尝试导入存储桶中列出的元数据文件时发现该文件缺失，MongoDB Ops Manager 将跳过该文件，日志一条警告，并将导入作业报告为 SUCCEEDED。这可能会在可恢复的时间范围内留下一个缺口，只有在您尝试跨越该缺口进行时点还原时，才会作为拒绝请求显示出来。
选择或添加包含 oplog 的 S3 存储桶。
从 Select an S3 bucket 列表中选择一个现有存储桶，然后单击 Next。或者选择 Add S3 bucket 注册一个新存储桶，然后单击 Save 注册该存储桶并继续。
重要
Add S3 bucket 表单要求提供与添加一个 S3 兼容快照存储过程相同的字段，包括数据存储类型和 MongoDB URI。
在 MongoDB Ops Manager 保存存储桶之前，您还必须选中复选框，确认 MongoDB 不支持由您的 S3 兼容存储解决方案引起的问题。
导入完成后，MongoDB Ops Manager 会在该行显示一个 Manage Oplogs 操作，您可以在其中查看或删除导入的 oplog。
与 PITR 交互
PITR 结合基线快照与存储在 oplog 存储中的 oplog 数据。不可变快照仅影响基线快照组件：
当您切换到不可变的 S3 快照存储时，PITR 会继续使用现有快照和 oplog 数据工作。旧快照保留在其原始存储中，并且 oplog 存储配置保持不变。
在新存储上完成第一个完整的不可变快照后，PITR 可以使用该快照作为基线，并继续从配置的 oplog 存储中追踪 oplog。
PITR 从导入的快照仅在您同时导入对应的不可变 oplogs 时可用。否则，您仅可以将已导入的快照恢复到 MongoDB Ops Manager 创建快照的精确时刻。
重要
为了实现完全的不可变保护，请使用启用对象锁的 oplog 存储与启用对象锁的快照存储一起。默认情况下，MongoDB Ops Manager 不会实施此配对：备份作业可以将不可变快照存储与标准 oplog 存储一起使用，即使使用这种组合，PITR 仍可正常工作。要求进行配对，全局管理员必须启用 mms.backup.enforceObjectLockOplogsOnObjectLockSnapshot 应用程序设置。MongoDB Ops Manager 默认禁用此设置。要创建一个启用对象锁定的 oplog 存储，请遵循 添加一个 S3-兼容的 oplog 存储 程序。
当您在 oplog 存储上启用对象锁时，MongoDB Agent 仅会为该备份作业跟踪大多数已提交的 oplog 条目。大多数已提交的条目无法回滚，因此此行为可防止 MongoDB Ops Manager 备份可能被后续回滚删除的 oplog 条目。
故障场景和恢复
当您切换快照存储时，不可变的 S3 快照不会引入额外的数据丢失情况。每个快照都从单个存储中恢复，因此恢复逻辑不需要为一个快照使用来自多个存储桶的数据。
在新存储上创建第一个快照之前崩溃
所有现有快照都保留在原始 S3存储中，并且可以完全恢复。
PITR 基于最近完成的快照和 oplog 数据工作。
在新存储上创建第一个完整快照期间发生崩溃
Ops Manager将正在进行的新存储快照标记为失败或不完整，并且不会将其用于恢复。
原始存储中的最后一个成功快照仍然是最新的可恢复快照。
Ops Manager和集群恢复后， Ops Manager会在下一个快照窗口将新的完整快照安排到不可变存储。
由于新存储上的第一个快照始终是完整快照，并且每个快照都从单个存储中恢复，因此恢复逻辑不依赖于为单个快照混合来自多个 S3 存储桶的数据。