常见问题解答：备份和恢复

备份需要哪些 MongoDB 权限？

如果要备份已启用身份验证的 MongoDB 实例，则 MongoDB 代理需要具有针对 MongoDB 代理备份功能所述的权限。

Cloud Manager 如何衡量数据大小？

Cloud Manager 使用以下转换来衡量快照大小并衡量已处理的 oplog 数据量：

• 1 MB = 1024 ²字节 (1 MiB)

• 1 GB = 1024 ³字节 (1 GiB)

• 1 TB = 1024 ⁴字节 (1 TiB)

备份是否适用于所有类型的部署？

• 对于 MongoDB 4.2 及更高版本，请参阅数据库的备份注意事项。

• 对于任何具有FCV 的MongoDB及更早版本的数据库，备份不支持独立运行部署。4.0备份完全支持副本集和分片的集群。

为什么备份功能不支持独立运行的实例部署？

Cloud Manager从oplog复制数据，以提供具有时间点恢复的连续备份。 Cloud Manager不支持备份独立运行主机，因为它们没有oplog 。 要支持使用单个mongod实例进行备份，您可以运行单副本集。

备份会影响我的生产数据库吗？

备份功能通常对生产 MongoDB 部署的影响很小。 这种影响类似于向副本集添加新的从节点的影响。

默认，代理会针对副本集的从节点成员执行初始同步，这是从节点(secondary node from replica set)中资源最密集的操作，以限制其影响。 您可以选择配置代理以针对副本集的主节点 (primary node in the replica set)节点执行初始同步，尽管这会增加初始同步操作的影响。

如何维护启用备份的副本集？

副本集中的大多数操作都是通过 oplog 复制的，因此会被备份过程捕获。但是，某些操作会进行未复制的更改：对于这些操作，您必须让 Cloud Manager从当前副本集重新同步以包含更改。

以下操作不会被复制，因此需要重新同步：

• 通过删除数据数据目录中的数据文件来重命名或删除数据库。 或者，使用MongoDB将复制的操作删除数据库，例如 mongosh 中的db.dropDatabase() 。

• 在实例作为独立运行实例运行时更改任何数据。

• 滚动索引构建。

• 使用compact或repairDatabase回收大量空间。

  在执行compact或repairDatabase操作后，重新同步并不是绝对必要的，但可以确保调整数据的 Cloud Manager 副本的大小，这意味着恢复速度更快，成本更低。

我应该在哪里运行备份代理？

在符合以下条件的主机上运行备份代理：

• 与 MongoDB 实例分开。 这样可以避免系统资源争用。

• 可以连接到您的 MongoDB 实例。 检查代理与 MongoDB 主机之间连接的网络设置。 有关所需端口的列表，请参阅为代理开放的端口。

• 至少具有高于平台要求的 2 个 CPU 内核和 3 GB RAM。 每次运行备份作业时，备份代理都会进一步影响主机性能。

是否可以在单个系统上运行备份和监控代理？

不存在阻止备份代理和监控在单个系统或主机上运行的技术限制。 但是，这两个代理都有资源要求，并且在单个系统上运行这两个代理可能会影响这些代理支持在 Cloud Manager 中部署的能力。

备份代理所需的资源取决于新oplog条目的速率和大小（即每小时生成的oplog总量为 GB）。 监控所需的资源取决于受监控的mongod 实例数量以及 实例提供的 数据库 mongod总数。

我是否可以运行多个备份代理来实现高可用性？

您可以运行多个备份代理以实现高可用性。 如果这样做，备份代理必须在不同的主机上运行。

当您运行多个备份代理时，每个项目只有一个代理是主代理。 主代理执行备份。 其余代理完全空闲，除了将其状态记录为备用代理并定期询问 Cloud Manager 是否应成为主代理。

备份代理是否会修改我的数据库？

备份代理会定期将一个称为检查点的小令牌写入源数据库的 oplog。 这些令牌为备份提供心跳，对源部署没有影响。 每个词元小于 100 字节。

初始备份同步如何影响数据库性能？

初始备份同步的影响应类似于同步新的从节点副本集成员。 备份代理不会限制其活动，并会尝试尽快执行同步。

如何防止 Cloud Manager 备份 collection？

Cloud Manager 提供了一个命名空间 filter，允许您指定要备份的 collection 或数据库。

如何更改备份的命名空间？

要编辑筛选器，请参阅编辑备份的设置。 更改命名空间筛选器可能需要重新同步。 如果是这样，Cloud Manager 将处理重新同步。

Cloud Manager 如何提供时间点恢复？

当您触发恢复时，Cloud Manager 会创建指向此快照的链接。 单击后，Cloud Manager 将从快照存储中检索数据段并将其流式传输到目标主机。

然后，在该主机上运行的 MongoDB 备份恢复实用程序会下载并应用 oplog 条目，以达到指定的时间点。

Cloud Manager 可以通过将 oplog 重放到所需点来恢复到 24 小时内的任何点。

要了解如何恢复副本集和分片集群，请参阅恢复 MongoDB 部署。

我是否可以提高每 6 小时拍摄一次快照的频率？

不可以。Cloud Manager 不支持大于每 6 小时一次的安排快照。有关更多信息，请参阅快照频率和保留策略。

我是否可以设置自己的快照保留策略？

是的。 您可以通过备份部署的Edit Snapshot Schedule菜单选项更改安排。管理员可以通过 API 中的 snapshotSchedule 资源 更改 快照频率和保留策略 。

通过自定义快照频率和保留策略，您可以更好地控制备份成本。

创建恢复快照需要多长时间？

Cloud Manager 以压缩形式将所有备份从 Cloud Manager 主机传输到您的基础架构。

在美国，Cloud Manager 以 50 到 100 Mbps 的速度发送快照。假设压缩系数为 4 倍，传输速度为 50 Mbps，则传输 250 GB 的快照需要 2.5 小时。

此外，时间点恢复取决于主机必须应用于收到的快照才能前滚到请求的备份时间点的 oplog 条目数量。

备份功能是否执行任何数据验证？

备份执行基本的损坏检查，并在任何组件（例如代理）关闭或损坏时发出警报，但不执行显式数据验证。 当 Cloud Manager 检测到损坏时，为谨慎起见，它会使当前的备份失效并发送警报。

如何恢复快照？

您可以通过 Cloud Manager 请求恢复，然后可以选择要恢复的快照以及希望 Cloud Manager 如何提供恢复。 所有恢复都需要双重身份验证。 如果您设置了短信，Cloud Manager 将通过短信发送授权码。 您必须在备份界面中输入授权代码才能开始恢复过程。

恢复快照时会传递什么？

Cloud Manager 将恢复作为 MongoDB 数据文件的tar.gz存档提供。

要了解有关恢复的更多信息，请参阅恢复 MongoDB 部署。

Cloud Manager 如何回滚备份数据？

如果您的MongoDB 部署遇到回滚，则Cloud Manager还会回滚已备份的数据。

当尾随游标发现写入操作的时间戳或哈希不匹配时， Cloud Manager会检测到回滚。 Cloud Manager进入回滚状态并测试副本集主节点 (primary node in the replica set)节点的oplog中的三个点，以找到历史中的共同点。 Cloud Manager回滚与MongoDB从回滚从节点(secondary node from replica set)的不同之处在于，公共点不一定是最近的公共点。

当 Cloud Manager 找到点时，该服务会使该点之后的 oplog 条目和快照失效，并回滚到该点之前的最新快照。然后，Cloud Manager 将恢复正常的备份操作。

如果 Cloud Manager 找不到公共点，则需要重新同步。

哪些条件需要重新同步？

如果备份代理的尾随游标跟不上部署的oplog ，则必须重新同步备份。

在以下情况下，可能会出现这种情况：

• 您的应用程序会定期生成大量数据，从而缩小主节点的 oplog 窗口，从而导致数据写入 oplog 的速度超过 Cloud Manager 消耗数据的速度。

• 如果备份代理在预配不足或过度使用的计算机上运行，并且无法跟上 oplog 活动。

• 如果备份代理关闭的时间超过oplog大小允许的时间。 如果您关闭代理（例如出于维护目的），请及时重新启动它们。 有关oplog 大小的更多信息，请参阅 oplogMongoDB手册中的 副本集 。

• 如果删除所有副本集数据并部署具有相同名称的新副本集，在定期拆除和重建部署的测试环境中可能会发生这种情况。

• 如果存在回滚，并且 Cloud Manager 无法在 oplog 中找到共同点。

• 如果 oplog 事件尝试更新副本集备份中不存在的文档，例如从数据与主节点不一致的从节点进行同步时可能会发生这种情况。

• 如果以滚动方式创建索引。