使用 Azure Cosmos DB 中的时间点还原功能进行连续备份

项目
10/23/2024

适用对象： NoSQL MongoDB Gremlin 表

Azure Cosmos DB 的时间点还原功能可在多种方案中发挥作用，包括：

在容器中执行意外的写入或删除操作后进行恢复。
还原已删除的帐户、数据库或容器。
还原到任何区域（其中存在备份）中的还原时间点。

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

可进行还原的时间范围（也称为保持期）是以下两个选项中的较低值：30 天和 7 天。

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

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

备份存储冗余

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

不同的还原方法

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

哪些内容将还原到新帐户？

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

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

注意

使用连续备份模式时，将在提供你的 Azure Cosmos DB 帐户的每个区域中创建备份。为每个区域帐户创建的备份默认是本地冗余的备份；如果你的帐户在该区域中启用了可用性区域功能，则备份是区域冗余的备份。还原操作始终将数据还原到新帐户。

哪些内容不会还原？

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

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

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

实时帐户的可还原时间戳

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

还原方案

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

还原已删除的帐户 -“还原”窗格中显示了所有可还原的已删除帐户。例如，如果在时间戳 T3 处删除了帐户 A。在这种情况下，使用紧靠在 T3、位置、目标帐户名称、资源组和目标帐户名称前面的时间戳就足以能够从 Azure 门户、PowerShell 或 CLI 还原。
还原特定区域中的帐户数据 - 例如，如果帐户 A 位于“中国东部”和“中国北部”这两个区域中的时间戳 T3 处。如果你需要“中国北部”中帐户 A 的副本，可以使用“中国北部”作为目标位置，从 Azure 门户、PowerShell 或 CLI 执行时间点还原。
执行意外的写入或删除操作后在具有已知还原时间戳的容器中恢复 - 例如，如果你知道数据库 1 中容器 1 的内容在时间戳 T3 处发生意外的修改。可以在 Azure 门户、PowerShell 或 CLI 中从时间戳 T3 处执行到另一个帐户的时间点还原，以恢复容器的所需状态。
将帐户还原到在意外删除数据库之前的某个时间点 - 在 Azure 门户中，可以使用事件源窗格确定数据库的删除时间并查找还原时间。同样，在 Azure CLI 和 PowerShell 中，可以通过枚举数据库事件源来发现数据库删除事件，然后结合所需的参数触发 restore 命令。
将帐户还原到在意外删除或修改容器属性之前的某个时间点。 - 在 Azure 门户中，可以使用事件源窗格确定容器的创建、修改或删除时间，以找到还原时间。同样，在 Azure CLI 和 PowerShell 中，可以通过枚举容器事件源来发现所有容器事件，然后结合所需的参数触发 restore 命令。

权限

Azure Cosmos DB 允许隔离和限制将连续备份帐户还原为特定角色或主体的权限。有关详细信息，请参阅权限一文。

定价

具有连续 30 天备份功能的 Azure Cosmos DB 帐户需要每月支付额外费用来存储备份。连续备份的 30 天和 7 天层均会产生还原数据费用。每次启动还原操作，还原费用都会累加。如果你在帐户中配置了连续备份但未还原数据，则帐单中只包括备份存储费用。

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

已启用 30 天连续备份策略的所有帐户都会产生每月备份存储费用，其计算方式如下：

2.034 元/GB * 帐户中的数据大小 (GB) * 区域数量
每次调用还原 API 都会产生一次性费用。费用取决于还原的数据量：

1.524 元/GB * 数据大小 (GB)。

例如，如果你在两个区域中有 1 TB 数据，那么：

备份存储费用的计算方式为 (1000 * 2.034 * 2) = 4068 元/月
每次还原的还原费用计算方式为 (1000 * 1.524) = 1524 元

提示

若要详细了解如何测量 Azure Cosmos DB 帐户的当前数据使用情况，请参阅探究 Azure Monitor Azure Cosmos DB 见解。连续 7 天层不会产生数据备份费用。

连续 30 天层与连续 7 天层

两个层的保留期分别为 30 天和 7 天。
30 天保留层会产生备份存储费用。 7 天保留层不收费。
任何一层的还原都始终收费

生存时间

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

客户管理的密钥

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

在结合使用客户管理的密钥和连续备份时，如何配置 Azure Cosmos DB 帐户。
客户管理的密钥如何影响还原？

当前限制

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

适用于 SQL、MongoDB、Gremlin、Table 的 Azure Cosmos DB API 支持连续备份。目前不支持 API for Cassandra。
Multi region write 帐户不受支持。
使用连续备份模式的数据库帐户的 Synapse Link 是正式发布版。相反的情况是，已启用 Synapse Link 的帐户的连续备份模式为公共预览版。目前，从容器禁用 Synapse Link 的客户无法迁移到连续备份。分析存储不包括在备份中。有关备份和分析存储的详细信息，请参阅分析存储备份。
还原的帐户是在源帐户所在的区域中创建的。如果源帐户未存在于某个区域中，则无法将该帐户还原到该区域。
连续 30 天层的还原时段仅为 30 天，连续 7 天层的还原时段为 7 天。虽然可以切换这些层，但无法更改实际数量（7 或 30）。此外，如果从 30 天层切换到 7 天层，则超过第七天之后的数据可能会丢失。
备份不能自动进行异地灾难恢复。应显式添加另一个区域，以确保帐户和备份具有复原能力。
当还原正在进行时，请不要修改或删除标识和访问管理 (IAM) 策略。这些策略可为帐户授予权限来更改任何 VNET、防火墙配置。
具有持续备份的 Azure Cosmos DB for MongoDB 帐户不支持为现有集合创建唯一索引。对于此类帐户，唯一索引必须与其集合一起创建；可以使用创建集合扩展命令执行这一操作。
还原后，对于某些集合，可能会重新生成一致的索引。可以通过 IndexTransformationProgress 属性检查重新生成操作的状态。
创建连续备份模式帐户时，无法添加、更新或删除 API for MongoDB 中的唯一索引。将帐户从定期模式迁移到连续模式时也无法修改适用于 MongoDB 的 API 中的唯一索引。
连续模式还原可能无法还原从还原点开始生效的吞吐量设置。

后续步骤

使用 Azure 门户、PowerShell、CLI 或 Azure 资源管理器启用连续备份。
获取 SQL 和 MongoDB 帐户的最新可还原时间戳。
使用 Azure 门户、PowerShell、CLI 或 Azure 资源管理器还原连续备份帐户。
将帐户从定期备份迁移到连续备份。
管理以连续备份模式还原数据所需的权限。
连续备份模式的资源模型

通过