你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
适用于：
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 帐户的每个区域中创建备份。 默认情况下，为每个区域帐户创建的备份是本地冗余的，如果你的帐户为该区域启用了可用性区域功能，则为区域冗余。 还原操作始终将数据还原到新帐户。
哪些内容不会还原？
执行时间点恢复后，不会还原以下配置：
- 无法还原共享吞吐量数据库下的容器子集。 整个数据库可作为一个整体进行还原。
- 防火墙、 虚拟网络、数据平面基于角色的访问控制或专用终结点设置。
- 源帐户中的所有区域。
- 存储过程、触发器、UDF。
- 基于角色的访问控制分配。
完成还原后，可将这些配置添加到还原的帐户。
实时帐户的可还原时间戳
若要还原未删除的 Azure Cosmos DB 实时帐户，最佳做法是始终标识容器的最新可还原时间戳。 然后，可以使用此时间戳将帐户还原到最新版本。
还原方案
时间点还原功能支持以下场景。 方案 1 到 3 演示了在事先知道还原时间戳时如何触发还原。 但在某些情况下，你可能并不知道发生意外删除或损坏的确切时间。 方案 4 和 5 演示如何使用可还原数据库或容器上的新事件源 API 发现 还原时间戳。
方案 1 - 还原已删除的帐户：可以在 “还原 ”窗格中看到所有可以还原的已删除帐户。 例如，如果在时间戳 T3 处删除了帐户 A。 在这种情况下，T3 之前的时间戳、位置、目标帐户名称和资源组信息足以从 Azure 门户、PowerShell 或 CLI 进行还原。
方案 2 - 还原特定区域中帐户的数据：例如，如果 帐户 A 存在于 美国东部 和美国 西部 的两个区域（时间戳为 T3）。 如果需要 美国西部帐户 A 的副本，可以从 Azure 门户、 PowerShell 或 CLI 执行时间点还原，并将美国西部用作目标位置。
方案 3 - 在具有已知还原时间戳的容器中从意外写入或删除操作中恢复：例如，如果你知道数据库 1 中容器 1 的内容是在时间戳 T3 时被意外修改的。 你可以在时间戳 T3 从 Azure 门户、PowerShell 或 CLI 执行时间点还原，以恢复到所需的容器状态。
方案 4 - 在意外删除数据库之前将帐户还原到以前的时间点：在 Azure 门户中，可以使用事件源窗格来确定数据库何时被删除并查找还原时间。 同样，在 Azure CLI 和 PowerShell 中，可以通过枚举数据库事件源来发现数据库删除事件，然后结合所需的参数触发 restore 命令。
方案 5 - 在意外删除或修改容器属性之前将帐户还原到以前的时间点：在 Azure 门户中，可以使用事件源窗格来确定容器何时创建、修改或删除以查找还原时间。 同样，在 Azure CLI 和 PowerShell 中，可以通过枚举容器事件源来发现所有容器事件，然后结合所需的参数触发 restore 命令。
权限
Azure Cosmos DB 允许隔离和限制将连续备份帐户还原为特定角色或主体的权限。 若要了解详细信息，请参阅 “管理权限”以还原 Azure Cosmos DB 帐户。
了解多区域写入帐户还原
在 枢纽区域 执行的写入会立即确认，并在 100 秒内异步备份。 在多写入帐户中，对附属区域执行的任何变更都将发送到中心区域进行确认。 中心区域会检查是否需要任何 冲突解决 ，在解决冲突后分配 冲突解决时间戳 ，并将文档发送回附属区域。 附属区域仅在从中心收到确认后备份文档。 简言之，还原过程仅还原中心区域在还原时间点确认的文档。
多区域写入帐户在还原时会发生什么情况？
- 还原时间戳尚未确认的突变不会还原。
- 具有自定义冲突解决策略的集合将根据时间戳重置为“以最后写入者为准”。
若要详细了解如何在启用了多写入的帐户中了解时间戳，请参阅 “了解时间戳”。
示例方案：假设具有两个区域（美国东部和美国西部）的多写入区域帐户，其中美国东部是中心区域，请考虑以下事件序列：
T1：客户端将文档 Doc1 写入美国东部（由于美国东部是中心区域，因此立即确认写入）
T2：客户将文档 Doc2 写入美国西部
T3：美国西部将 Doc2 发送至美国东部进行确认
T4：美国东部收到 Doc2，确认该文档，然后将 Doc2 发送回美国西部。
T5：美国西部收到已确认的 Doc2
在这种情况下，如果为充当源的中心区域提供的还原时间戳为 T3，则将仅还原 Doc1。 Doc2 在 T3 之前尚未得到中心确认。 仅当恢复时间戳超过 T4 时，doc2 才会被恢复，因为在卫星中，T4 的恢复版本仅包含 doc1，因为 doc2 尚未确认。
定价
具有连续 30 天备份功能的 Azure Cosmos DB 帐户需要每月支付额外费用来存储备份。 连续备份的 30 天和 7 天层均会产生还原数据费用。 每次启动还原操作，还原费用都会累加。 如果你在帐户中配置了连续备份但未还原数据，则帐单中只包括备份存储费用。
以下示例基于在美国西部部署的 Azure Cosmos DB 帐户的价格。 定价和计算可能因所使用的区域而异。有关最新定价信息，请参阅 Azure Cosmos DB 定价页。
已启用 30 天连续备份策略的所有帐户都会产生每月备份存储费用，其计算方式如下：
$0.20/GB * 帐户中的数据大小 (GB) * 区域数量
每次还原 API 调用都会产生一次性费用。 费用取决于还原的数据量函数：
$0.15/GB * 数据大小（以 GB 为单位）
例如，如果两个区域中有 1 TB 的数据：
备份存储成本计算为 1000 * 0.20 * 2 = 每月 400 美元
还原成本计算为 1000 * 0.15 = 每个还原 150 美元
提示
若要详细了解如何测量 Azure Cosmos DB 帐户的当前数据使用情况，请参阅探究 Azure Monitor Azure Cosmos DB 见解。 连续 7 天的层级不会对数据的备份收取费用。
连续 30 天级别与 7 天级别
- 一个层的保留期为 30 天，而另一层的保留期为 7 天。
- 30 天保留层会产生备份存储费用。 不会针对七天保留层收取费用。
- 任何一层的还原都始终收费
生存时间
- 默认情况下，默认还原过程会还原容器的所有属性，包括其 TTL 配置。 如果在不禁用 TTL 的情况下进行还原操作，这可能会导致数据被删除。 若要防止删除，请在执行还原时传递参数以在 PowerShell （-DisableTtl $true）或 cli （-disable-ttl True）中禁用 TTL。
客户管理的密钥
请参阅客户管理的密钥如何影响连续备份以了解：
- 在结合使用客户管理的密钥和连续备份时，如何配置 Azure Cosmos DB 帐户。
- 客户管理的密钥如何影响还原？
当前限制
目前，时间点还原功能具有以下限制：
适用于 SQL、MongoDB、Gremlin、Table 的 Azure Cosmos DB API 支持连续备份。 目前不支持 API for Cassandra。
目前，从容器中禁用 Synapse Link （已弃用） 的客户无法迁移到连续备份。 分析存储不包括在备份中。
还原的帐户是在源帐户所在的区域中创建的。 如果源帐户未存在于某个区域中，则无法将该帐户还原到该区域。
对于连续 30 天层，还原窗口只有 30 天，而连续 7 天层只有 7 天。 可以切换这些层，但无法更改实际数量（
7或30）。 此外，如果从 30 天层切换到 7 天层，则超过第七天之后的数据可能会丢失。备份不能自动进行异地灾难恢复。 应显式添加另一个区域，以确保帐户和备份具有复原能力。
当还原正在进行时，请不要修改或删除标识和访问管理 (IAM) 策略。 这些策略授予帐户更改任何虚拟网络、防火墙配置的权限。
具有连续备份的 Azure Cosmos DB for MongoDB 帐户不支持为现有集合创建 唯一索引 。 对于此类帐户，必须创建唯一索引及其集合创建，这必须且只能使用创建集合 扩展命令来完成。
还原后，对于某些集合，可能会重新生成一致性索引。 可以通过 IndexTransformationProgress 属性检查重新生成操作的状态。
创建连续备份模式帐户时，无法添加、更新或删除 API for MongoDB 中的唯一索引。 将帐户从定期模式迁移到连续模式时也无法修改适用于 MongoDB 的 API 中的唯一索引。
在连续模式下进行还原时，可能无法恢复到还原点时有效的吞吐量设置。