在 Azure Cosmos DB 中通过时间点恢复实现连续备份

  • 適用於: ✅ NoSQL, ✅ MongoDB, ✅ Apache Gremlin, ✅ Table

Azure Cosmos DB 的时间点还原功能有助于多种场景，包括：

  • 在容器中执行意外的写入或删除操作后进行恢复。
  • 还原已删除的帐户、数据库或容器。
  • 可以在备份存在的任何区域中还原至特定还原点。

Azure Cosmos DB 在后台执行数据备份，而无需消耗任何额外的预配吞吐量（RU），也不会影响数据库的性能和可用性。 连续备份是在帐户所在的每个区域中创建的。 例如，帐户可以在中国北部 3 具有写入区域，并在中国东部 2 具有读取区域。 然后，可以将这些副本区域备份到每个相应区域中的远程Azure 存储帐户。 默认情况下，每个区域将备份存储在本地冗余storage帐户中。 如果区域启用了 可用性区域 ，则备份将存储在 Zone-Redundant 存储帐户中。

示意图显示如何跨多个区域备份容器。

可用于还原的时间范围（也称为保留期）取决于所选的持续备份层：35 天、30 天或 7 天。 该 Continuous35Days 层目前以预览版提供。

还原的时间点可以是保留期内的任何时间戳，不早于创建资源时的时间点。 在强一致性模式下，与读取区域相比，写入区域的备份更加及时更新。 由于网络或其他暂时性问题，读取区域可能会滞后。 执行还原时，可以获取该区域中给定资源的最新可还原时间戳。 引用最新的可还原时间戳有助于确认资源备份是否达到给定的时间戳，并且可以在该区域还原。

目前，可以将Azure Cosmos DB 帐户（API for NoSQL 或 MongoDB、API for Table、API for Gremlin）内容在特定时间点还原到另一个帐户。 可以通过 Azure portal、Azure CLI、Azure PowerShell 或 Azure 资源管理器 模板执行此还原作。

备份存储冗余

默认情况下，Azure Cosmos DB 将连续模式备份数据存储在本地冗余storage blob 中。 对于配置了区域冗余的区域，备份存储在区域冗余的存储 blob 中。 在连续备份模式下，无法更新备份存储冗余。

不同的还原方法

连续备份模式支持使用两种方法来还原已删除的容器和数据库。 它们可以还原到 新帐户 或 现有帐户中。 要选择哪种模式取决于方案。 在大多数情况下，最好将已删除的容器和数据库还原到现有帐户中。 这可以避免还原到新帐户时所需的数据传输成本。 出现意外数据修改的情况时，将数据还原到新帐户可能是首选。

哪些数据或功能将还原到新帐户？

处于稳定状态时，在源帐户中执行的所有改动（包括数据库、容器和项）都会在 100 秒内进行异步备份。 如果Azure 存储备份介质已关闭或不可用，则在媒体可用之前，这些突变将保留在本地。 然后，操作中出现的变动会被清除，以防止可还原操作的保真度产生任何损失。

你可以选择还原预配的吞吐量容器、共享吞吐量数据库或整个帐户的任意组合。 还原操作会将所有数据及其索引属性还原到新帐户中。 还原过程可确保在帐户、数据库或容器中还原的所有数据在指定的还原时间之前都是一致的。 还原持续时间取决于需要还原的数据量。 新还原的数据库帐户的一致性设置与源数据库帐户的一致性设置相同。

注意事项

使用连续备份模式时，备份将在 Azure Cosmos DB 帐户可用的每个区域进行。 默认情况下，对于每个区域帐户创建的备份是局部冗余的，如果帐户为该区域启用了可用性区域功能，则将是区域冗余。 还原操作始终将数据还原到新帐户。

什么不会被还原？

执行时间点恢复操作后，以下配置不会被还原：

  • 无法还原共享吞吐量数据库下的容器子集。 整个数据库可作为一个整体进行还原。
  • 防火墙、虚拟网络、基于角色的数据平面访问控制或专用终结点设置。
  • 源帐户中的所有区域。
  • 存储过程、触发器、UDF。
  • 基于角色的访问控制分配。

完成还原后，可将这些配置添加到还原的帐户。

直播帐户的可恢复时间戳

若要还原未删除Azure Cosmos DB 实时帐户，最佳做法是始终标识容器的 latest 可还原时间戳。 然后，可以使用此时间戳将帐户还原到最新版本。

恢复场景

时间点还原功能支持以下场景： 方案 1 到 3 演示了在事先知道还原时间戳时如何触发还原。 但在某些情况下，你可能并不知道发生意外删除或损坏的确切时间。 方案 4 和 5 演示如何使用可还原数据库或容器上的新事件源 API 发现 还原时间戳。

显示可还原帐户的带有时间戳的生命周期事件的示意图。

  • 方案 1 - 还原已删除的帐户：可以在 “还原 ”窗格中看到所有可以还原的已删除帐户。 例如，如果在时间戳 T3 处删除了帐户 A。 在本例中，在 T3、位置、目标帐户名、资源组和目标帐户名之前，时间戳足以从 Azure portal、PowerShell 或 CLI 还原。

    具有可还原数据库和容器时间戳的生命周期事件。

  • 方案 2 - 还原特定区域中帐户的数据：例如，如果 帐户 A 存在于两个区域 中国东部 2 和中国 北部 3 （时间戳为 T3）。 如果需要中国北部 3 帐户 A 的副本，可以从 Azure 门户、PowerShell 或 CLI 执行时间点还原，并将中国北部 3 用作目标位置。

  • 方案 3 - 从具有已知还原时间戳的容器中恢复因意外写入或删除操作而丢失的数据：例如，如果知道容器 1 中数据库 1 的内容在时间戳 T3 时意外修改。 可以在时间戳 T3 处从 Azure portal、PowerShell 或 CLI 还原到另一个帐户中，以恢复容器的所需状态。

  • Scenario 4 - 将帐户还原到数据库意外删除之前的时间点：在 Azure portal 中，可以使用事件源窗格来确定数据库何时被删除并查找还原时间。 同样，使用 Azure CLI 和 PowerShell，可以通过枚举数据库事件源来发现数据库删除事件，然后使用所需的参数触发还原命令。

  • Scenario 5 - 在意外删除或修改容器属性之前将帐户还原到以前的时间点：在 Azure portal 中，可以使用事件源窗格来确定何时创建、修改或删除容器以查找还原时间。 同样，使用 Azure CLI 和 PowerShell，可以通过枚举容器事件源来发现所有容器事件，然后使用所需的参数触发还原命令。

权限

Azure Cosmos DB 允许将连续备份帐户的还原权限隔离并限制为特定角色或主体。 若要了解详细信息，请参阅 管理权限以还原 Azure Cosmos DB 帐户。

了解多区域写入帐户还原

在 枢纽区域 执行的写入会立即确认，并在 100 秒内异步备份。 在多写入帐户中，对附属区域执行的任何变更都将发送到中心区域进行确认。 中心区域会检查是否需要任何 冲突解决 ，在解决冲突后分配 冲突解决时间戳 ，并将文档发送回附属区域。 附属区域仅在从中心收到确认后备份文档。 简言之，还原过程仅还原中心区域在还原时间点确认的文档。

多区域写入帐户的还原会发生什么情况？

  • 还原时间戳尚未确认的突变不会还原。
  • 具有自定义冲突解决策略的集合将根据时间戳重置为“以最后写入者为准”。

注意事项

对于多区域帐户，要解析已确认的本地暂定写入，或者要采取措施回滚这些写入，从附属区域还原比在中心区域还原速度更慢。

若要详细了解如何在启用了多写入的帐户中了解时间戳，请参阅 “了解时间戳”。

示例方案：假设具有两个区域（中国北部 3 和中国东部 2）的多写入区域帐户，其中中国北部 3 是中心区域，请考虑以下事件序列：

  • T1：客户端将文档 Doc1 写入中国北部 3（由于中国北部 3 是中心区域，写入立即确认）

  • T2：客户端将文档 Doc2 写入中国东部 2

  • T3：中国东部 2 向中国北部 3 发送 Doc2 进行确认

  • T4：中国北部 3 收到 Doc2，确认文档并将 Doc2 发送回中国东部 2

  • T5：中国东部 2 已收到确认 Doc2

在此场景中，如果提供的还原时间戳为以中心区域为源的 T3，则只恢复 Doc1。 Doc2 在 T3 之前尚未得到中心确认。 仅当恢复时间戳超过 T4 时，doc2 才会被恢复，因为在卫星中，T4 的恢复版本仅包含 doc1，因为 doc2 尚未确认。

定价

Azure Cosmos DB连续 30 天或 35 天备份的帐户每月额外收费用于存储备份。 连续备份的所有层（7、30 或 35 天）都会产生 还原数据的费用。 每次启动还原操作，还原费用都会累加。 如果配置了连续备份但未还原数据的帐户，则账单中仅包括备份存储成本。

以下示例基于在中国北部 3 中部署的Azure Cosmos DB帐户的价格。 定价和计算可能因所使用的区域而异，请参阅 Azure Cosmos DB 定价页以获取最新定价信息。

  • 在 30 天或 35 天层启用连续备份策略的帐户每月会产生备份存储费用。 30 天和 35 天层按相同的费率收费，计算方式如下：

    2.034 元/GB * 帐户中的数据大小 (GB) * 区域数量

  • 每次还原 API 调用都会产生一次性费用。 根据还原的数据量计算费用：

    1.524 元/GB * 以 GB 为单位的数据大小。

例如，如果两个区域中有 1 TB 的数据：

  • 备份存储成本的计算为（1000 * 2.034 * 2）= 每月4068 CNY

  • 每次还原的恢复成本计算方式为 (1000 * 1.524) = 1524 元人民币

提示

有关测量 Azure Cosmos DB 帐户的当前数据使用情况的详细信息，请参阅 Explore Azure Monitor Azure Cosmos DB 见解。 连续 7 天的服务层对数据备份不收取费用。

比较连续备份层

  • 保留期为 7 天、30 天或 35 天，具体取决于所选层。
  • 备份存储收取 30 天和 35 天层的费用。 7 天层不对备份存储收费。
  • 无论层如何，始终收费还原。

生存时间

  • 默认情况下，默认还原过程会还原容器的所有属性，包括其 TTL 配置。 如果在不禁用 TTL 的情况下还原，这可能会导致数据被删除。 若要防止删除，请在执行还原时传递参数以在 PowerShell （-DisableTtl $true）或 cli （-disable-ttl True）中禁用 TTL。

客户管理的密钥

请参阅客户管理的密钥如何影响连续备份了解：

  • 如何在将客户管理的密钥与连续备份配合使用时配置 Azure Cosmos DB 帐户。
  • 고객이 관리하는 키는 복원에 어떤 영향을 미치나요?

当前限制

目前，时间点还原功能具有以下限制：

  • 支持连续备份的 Azure Cosmos DB SQL、MongoDB、Gremlin 和 Table API。 目前不支持 API for Cassandra。

  • 目前，从容器禁用 Synapse Link （已弃用）的客户无法迁移到连续备份。 分析型存储不包括在备份中。

  • 还原的帐户是在源帐户所在的区域中创建的。 如果源帐户未存在于某个区域中，则无法将该帐户还原到该区域。

  • 对于连续 7 天层，还原时段为 7 天，连续 30 天层为 30 天，连续 35 天为 35 天。 可以在这些层之间切换，但不能更改实际数量（7或3035）。 如果切换到较短的窗口，例如从 30 天或 35 天层切换到 7 天层，则可能会在超出新的较短保留时段以外的天数丢失数据。

  • 备份不会自动具备地理灾难抵御能力。 应显式添加另一个区域，以确保帐户和备份具有复原能力。

  • 还原进行时，请不要修改或删除身份和访问管理 (IAM) 策略。 这些策略授予帐户更改任何虚拟网络或防火墙配置的权限。

  • 具有连续备份的 Azure Cosmos DB for MongoDB 帐户不支持为现有集合创建唯一索引。 对于此类帐户，必须创建唯一索引及其集合创建，这必须且只能使用创建集合扩展命令来完成。

  • 还原后，对于某些集合，可能会重新生成一致的索引。 可以通过 IndexTransformationProgress 属性检查重新生成操作的状态。

  • 创建连续备份模式帐户时，无法添加、更新或删除 API for MongoDB 中的唯一索引。 当您将帐户从定期模式迁移到连续模式时，它们也无法被修改。

  • 连续模式还原可能无法恢复到还原点时有效的吞吐量设置。

后续步骤

  • Last updated on