对于 AI 代理:可在 https://www.mongodb.com/zh-cn/docs/llms.txt 获取文档索引—通过在任何 URL 路径后添加 .md 可获取所有页面的 Markdown 版本。
Docs 菜单

备份准备

在备份群集或副本集之前,请确定如何备份数据以及要备份哪些数据。本页介绍在开始备份之前必须考虑的事项。

提示

要了解备份的工作原理,请参阅备份。

When sizing the backup of your data, keep the replica set size to 2 TB or less of uncompressed data. If your database increases beyond 2 TB of uncompressed data:

  • 对数据库进行分片

  • 将每个分片的未压缩数据保持在 2 TB 或更少

这些大小建议是最佳实践。 它们不是 MongoDB database 或 Cloud Manager 的限制。

备份和恢复可能会使用大量的 CPU、内存、存储和网络带宽。

例子

您提到的网络吞吐量(例如 10 Gbps 或 100 Gbps)是理论上的最大值。该值不考虑网络流量的共享或限制。

考虑以下情况:

  • 您希望备份一个 2 TB 数据库。

  • 您的主机支持从 Cloud Manager 到其备份存储的 10 Gbps TCP 连接。

  • 网络连接的丢包率很低,往返延迟时间也很短。

A full backup of your data would take more than 30 hours to complete. [1]

这不考虑磁盘读取和写入速度,对于单个或镜像 NVMe 存储设备,磁盘读取和写入速度最多为 3 Gbps 读取和 1 Gbps 写入。

完成每个连续增量备份所需的时间取决于写入负载。

如果您将此数据库分成 4 个分区,则每个分区分别运行各自的备份。这会导致备份需要不到 8 小时才能完成。

[1] 这些吞吐量数字是使用网络吞吐量计算器计算的,并假设没有额外的网络压缩。

默认情况下,Cloud Manager 每 6 小时拍摄一次数据的基本快照。

如果需要,管理员可以将基本快照的频率更改为 6、8、12 或 24 小时。 Cloud Manager 按安排自动创建快照;您无法按需拍摄快照。

Cloud Manager 在下表所列的时间段内保留快照。

如果终止部署的备份,Cloud Manager 将立即删除当前保留策略日期内的快照。

如果您停止部署的备份,Cloud Manager 将停止拍摄新快照,但会保留现有快照,直到列出的到期日期为止。

快照
默认保留政策
最长保留时间策略

基础快照

2 天

5 天(如果频率为 24 小时,则为 30 天)

每日快照

7 天

1 年

每周快照

4 周

1 年

月度快照

13个月

7 年

对快照计划的更改会影响快照存储成本。

您可以通过 Backup 页面提供的 Edit Snapshot Schedule 菜单选项更改备份部署的计划。管理员可以通过 API 中的 snapshotSchedule 资源更改快照频率和保留时间。

您无法在 Cloud Manager 中更改快照的参考时间。

  • Cloud Manager 不会备份其中的collection总数达到或超过100,000的部署。

  • Cloud Manager 不会复制索引collection选项。

您无法使用 WiredTiger 加密来存储备份。如果不启用加密,则可以使用 WiredTiger storage engine 来存储备份。如果从备份恢复,则会恢复未加密的文件。

对于运行 MongoDB 4.2 或更高版本的集群:

  • Cloud Manager maintains causal consistency when taking snapshots except for size statistics reported by collStats and db.[collection].count(). Size statistics reported by collStats and db.[collection].count() may be inccurate.

  • Cloud Manager 协调分片集群的所有分片的时间。 这可确保快照包括截至计划快照时间写入每个分片和节点的所有文档。

对于运行 MongoDB 4.0 和更早版本的集群:

  • Cloud Manager 维护崩溃一致的快照。

  • Cloud Manager 大约在同一时间从分片集群的每个分片和配置服务器副本集拍摄快照。

功能
运行 FCV 4.2 及更高版本的数据库
运行 FCV 4.0 和更早版本的数据库

使用 WiredTiger 快照备份数据

使用备份守护程序备份数据

备份副本集

备份分片集群

Can Filter using Namespaces [2]

可指定同步源数据库

Can Restore Data to Specific Point in Time [3]

Can Perform Incremental Backups [4]

支持使用 KMIP 加密 [5] 的Atlas 备份快照

Supports Snapshots that use Local Key Encryption [6]

支持保存到 S3 快照存储

支持运行 MongoDB Enterprise 的数据库

支持运行 MongoDB Community 的数据库

Requires a MongoDB Agent with backup enabled on every mongod cluster node

[6] 仅 Cloud Manager 6.0.8 及更高版本支持命名空间筛选。 MongoDB 部署的featureCompatibilityVersion值必须为4.0及更早版本或者6.0.1及更高版本。

[3] 执行 PIT 恢复需要 Ops Manager 4.2.13 或更高版本。
[4]

在删除快照后以及块存储区块大小已更改的情况下,Cloud Manager 需要对首次备份进行完整备份。增量备份可降低网络传输和存储成本。

此功能适用于:

  • MongoDB 4.4 和更早版本。

  • MongoDB 4.2.6 or later if running FCV 4.2 or later.

[5] Querying an encrypted snapshot requires MongoDB Enterprise 4.2.9 and later or 4.4.0 and later.

[6] FCV 4.2 and later backups don't support local key encryption.

[ 7 ] Backups to a FCV 4.2 or later database to a File System Store ignore File System Store Gzip Compression Level.

To run backups and restores if you are running MongoDB 4.2 or later with FCV 4.2 or later, you:

  • 必须考虑块存储块大小的变化。如果您未设置块大小并使用默认值,该块大小将从 64 KB 更改为 1 MB。这可能会影响存储使用情况。

  • Must ensure the hostnames in your replica set configuration match the hostnames that the MongoDB Agent uses, or that your host mappings contain the correct hostnames. You can use rs.conf() to verify your replica set configuration.

  • 仅当运行的是 MongoDB 6.0或更高版本时,才能使用命名空间筛选器列表来定义备份中包含的命名空间。 在 MongoDB 4.2到5.0版本上拍摄的快照始终包含所有命名空间。

  • 不需要同步源数据库。 拍摄快照时,Cloud Manager 会选择对性能影响最小且快照数据的存储级别重复最多的副本集成员。

  • Must deploy a MongoDB Agent with every mongod node in the cluster.

注意

如果 Cloud Manager 不托管您的集群:

  • Grant the backup and clusterAdmin roles to the MongoDB user that runs backups.

  • 确保运行 MongoDB 助手的操作系统用户对部署的所有数据文件(包括日志文件)具有读取权限。

重要

Only sharded clusters or replica sets can be backed up. To back up a standalone mongod process, you must convert it to a single-member replica set.

如果数据库运行任何 MongoDB 4.0 或更早版本,或者数据库运行 MongoDB 4.2 并满足以下条件,则以下注意事项适用: "featureCompatibilityVersion" : 4.0

Cloud Manager 使用 groom 作业托管过期快照。根据包含快照的快照存储,这些groom作业的行为会有所不同:

快照存储
Groom 作业的工作方式

MongoDB 块存储

使用额外的磁盘空间,最多为每个作业的活动块数量。

文件系统快照存储

删除过期的快照

S3 快照存储

如果 Cloud Manager 在groom作业运行时创建快照,则可能会使用额外的磁盘空间。Cloud Manager 可以在 S3 快照存储上运行并发groom作业。

注意

快照作业和修饰作业不能同时运行。 如果在快照作业运行时启动 groom 作业,则 groom 作业将失败, MongoDB Ops Manager会记录错误并在快照作业完成后自动重试 groom 作业。 如果在 groom 作业运行时启动快照作业,则快照作业将失败, MongoDB Ops Manager会记录错误并在 groom 作业完成后重试快照作业。

通过使用命名空间过滤器,您可以指定要备份的数据库和集合。您可以创建 Deny List 以包含要排除的数据库和集合,或者创建 Whitelist 以包含要包括的数据库和集合。您可以在开始备份时选择数据库和集合,也可以以后根据需要编辑这些数据库和集合。如果在备份中添加数据以更改过滤器,则需要进行重新同步。

使用拒绝列表可阻止备份包含日志记录数据、缓存或其他临时数据的备份。 排除这些类型的数据库和集合可以减少备份时间和成本。 使用拒绝列表通常比使用白名单更可取,因为白名单要求您有意选择加入要备份的每个命名空间。

注意

仅 Cloud Manager 6.0.8及更高版本支持命名空间筛选。 MongoDB 部署的featureCompatibilityVersion值必须为4.0及更早版本或者6.0.1及更高版本。

To back up MongoDB clusters, use the WiredTiger storage engine storage engine.

如果您当前的支持数据库使用 MMAPv1,请升级到 WiredTiger:

借助 WiredTiger,Cloud Manager 将备份限制为文件数少于 100,000 个的部署。文件包括集合和索引。

MongoDB 4.2 removes MMAPv1 storage. To learn more about storage engines, see Storage Engines in the MongoDB manual.

对于生产部署,请定期重新同步所有备份的副本集,例如每年一次。重新同步时,将从每个副本集中的从节点读取数据。在重新同步期间,不会生成新快照。

如果您符合以下条件,您可能还需要重新同步备份:

重要

您可以对运行MongoDB且 Feature Compatibility Version 为 4.0 或更早版本的集群使用检查点。检查点已从使用FCV 4.2 或更高版本的MongoDB实例中删除。

For sharded clusters, checkpoints provide additional restore points between snapshots. With checkpoints enabled, Cloud Manager creates restoration points at configurable intervals of every 15, 30 or 60 minutes between snapshots. To enable checkpoints, see enable checkpoints.

为了创建检查点,Cloud Manager 会停止 负载均衡器 ,并将令牌插入到集群中每个分 片 和 配置服务器 的 oplog 中。这些检查点令牌是轻量级的,不会影响性能或磁盘使用情况。

备份不需要检查点,默认情况下它们处于禁用状态。

Restoring from a checkpoint requires Cloud Manager to apply the oplog of each shard and config server to the last snapshot captured before the checkpoint. Restoration from a checkpoint takes longer than restoration from a snapshot.

For sharded clusters running with FCV 4.0 or earlier, Cloud Manager disables the balancer before taking a cluster snapshot. In certain situations, such as a long migration or no running mongos, Cloud Manager tries to disable the balancer but cannot. In such cases, Cloud Manager continues to take cluster snapshots but flags the snapshots that may have incomplete or inconsistent data. Cluster snapshots taken during an active balancing operation run the risk of data loss or orphaned data.

For sharded clusters, if the Backup can't reach a mongod process, whether a shard or config server, then the agent can't insert a synchronization oplog token. In these cases, Cloud Manager doesn't create the snapshot and displays a warning message.