块 blob 的时间点还原
时间点还原支持将块 blob 数据还原到之前的状态，以防止意外删除或损坏。 当用户或应用程序意外删除数据或应用程序错误损坏数据时，时间点还原非常有用。 时间点还原还支持测试方案，这些方案需要在运行其他测试之前将数据集还原到已知状态。
仅标准性能层中的常规用途 v2 存储帐户支持时间点还原。 只有热访问层和冷访问层中的数据才能使用时间点还原进行还原。
若要了解如何对存储帐户启用时间点还原，请参阅对块 blob 数据执行时间点还原。
时间点还原的工作原理
若要启用时间点还原，请为存储帐户创建管理策略并指定保持期。 在保持期内，可以将块 blob 从当前状态还原到上一个时间点的状态。
若要启动时间点还原，请调用还原 Blob 范围操作并指定 UTC 时间的还原点。 可以指定字典范围的容器和 blob 名称进行还原，或省略范围以还原存储帐户中的所有容器。 每个还原操作最多支持 10 个字典范围。
Azure 存储会分析在所请求的还原点（UTC 时间）和当前时间段内对指定的 blob 所做的所有更改。 还原操作是原子操作，因此要么完全还原所有更改，要么失败。 如果存在无法还原的 blob，则该操作将失败，并且对受影响容器的读取和写入操作将继续。
下图介绍了时间点还原的工作原理。 一个或多个容器或 blob 范围已还原到其 n 天前的状态，其中 n 小于或等于为时间点还原定义的保持期。 其作用是还原在保持期内发生的写入和删除操作。
一个存储帐户一次只能运行一个还原操作。 还原操作在执行过程中无法取消，但可以执行第二个还原操作来撤消第一个操作。
“还原 Blob 范围”操作将返回唯一标识操作的还原 ID。 若要检查时间点还原的状态，请使用从“还原 Blob 范围”操作返回的还原 ID 调用“获取还原状态”操作。
重要
执行还原操作时，Azure 存储会阻止对在操作期间还原的范围内的 blob 执行数据操作。 读取、写入和删除操作在主位置中被阻止。 出于此原因，在执行还原操作时，Azure 门户中的操作（如列出容器）可能不会按预期执行。
如果存储帐户是异地复制的，则在还原操作期间，从辅助位置读取的操作可以继续。
注意
时间点还原仅支持还原对块 blob 执行的操作。 不能还原对容器执行的任何操作。 例如，如果你通过调用删除容器操作从存储帐户中删除了容器，将无法使用时间点还原操作来还原该容器。 如果要在以后还原它们，请删除单个 blob，而不是删除整个容器。
时间点还原的先决条件
执行时间点还原需要启用以下 Azure 存储功能，然后才能启用时间点还原：
若要详细了解 Azure 的数据保护建议，请参阅数据保护概述。
注意
为存储帐户启用 Blob 版本控制后，对该帐户中的 Blob 执行的每个写入操作都会创建一个新版本。 因此，启用 Blob 版本控制可能会导致额外的成本。 若要尽量降低成本，请使用生命周期管理策略自动删除旧版本。 有关生命周期管理的详细信息，请参阅通过自动执行 Azure Blob 存储访问层来优化成本。
时间点还原的保持期
为存储帐户启用时间点还原时，将指定一个保持期。 存储帐户中的块 blob 可以在保持期内还原。
保持期会在启用时间点还原后几分钟开始。 请记住，不能将 blob 还原到保持期开始之前的状态。 例如，如果在 5 月 1 日启用时间点还原，保持期为 30 天，则在 5 月 15 日最多可以还原到 15 天前。 在 6 月 1 日则可以还原 1 到 30 天内的数据。
时间点还原的保持期必须至少比为软删除指定的保持期少一天。 例如，如果软删除的保持期设置为 7 天，则时间点还原的保持期可以介于 1 到 6 天之间。
注意
为时间点还原指定的保留期对 blob 版本的保留期没有影响。 Blob 版本将一直保留，直到显式删除为止。 若要通过删除旧版本或对其分层来优化成本，请创建一个生命周期管理策略。 有关详细信息，请参阅通过自动管理数据生命周期来优化成本。
还原一组数据所用的时间取决于在还原期间执行的写入和删除操作的次数。 例如，如果一个帐户有 100 万个 blob，每天增加 3,000 个 blob，每天删除 1,000 个 blob，那么将需要大约两个小时才能还原到过去 30 天的那个时间点。 对于具有此变化率的帐户，不建议将保持期和恢复时间跨度设置为 90 天以上。
时间点还原权限
若要启动还原操作，客户端必须对存储帐户中的所有容器具有写入权限。 若要使用 Microsoft Entra ID 授予授权还原操作的权限，请将存储帐户参与者角色分配给存储帐户、资源组或订阅级别的安全主体。
限制和已知问题
块 blob 的时间点还原具有以下限制和已知问题：
- 在时间点还原操作过程中，只能还原标准常规用途 v2 存储帐户中的块 blob。 追加 blob、页 blob 和高级块 blob 不会还原。
- 如果在保持期内删除了某个容器，则该容器将无法通过时间点还原操作进行还原。 如果尝试还原的 blob 范围包含已删除的容器中的 blob，则时间点还原操作将失败。 若要了解如何防止删除容器，请参阅容器软删除。
- 如果在时间点还原保留期内使用永久删除来清除软删除的 blob 版本，则还原操作可能无法正确还原该 blob。
- 如果在当前时间与还原点之间的时间段内，blob 已移动到热存储层和冷存储层之间，则会将 blob 还原到其以前的层。
- 不支持还原存档层中的块 blob。 例如，如果热存储层中的某一 blob 在两天前已移至存档存储层，而还原操作还原至三天前的某个时间点，则该 blob 不会被还原至热存储层。 要还原已存档的 blob，请先将其从存档存储层移开。 有关详细信息，请参阅存档层中的 blob 解除冻结概述。
- 不支持部分还原操作。 因此，如果容器中包含存档的 blob，则整个还原操作将失败，因为系统不支持还原存档层中的块 blob。
- 如果配置了不可变策略，则可以启动还原操作，但任何受不可变策略保护的 blob 都不会被修改。 在这种情况下，还原操作不会导致统一将所有 blob 都还原到给定的日期和时间。
- 通过 Put Block 或 Put Block from URL 上传、但未通过 Put Block List 提交的块不是 blob 的一部分，因此不会在还原操作过程中还原。
- 如果具有有效租约的 blob 包含在还原范围内，并且所租用 blob 的当前版本与为 PITR 提供的时间戳的以前版本不同，则还原操作将自动失败。 建议在启动还原操作之前中断任何活动租约。
- 对存储帐户执行客户管理的故障转移会为该存储帐户重置尽可能早的还原点。 有关更多详细信息，请参阅时间点还原。
- 在还原操作过程中，不会创建或删除快照。 只有基本 blob 还原到其以前的状态。
- 通过 Azure Data Lake Storage Gen2 的分层命名空间或操作不支持时间点还原。
- 当存储帐户的 AllowedCopyScope 属性设置为将复制范围限制为同一 Microsoft Entra 租户或虚拟网络时，不支持时间点还原。 有关详细信息，请参阅关于复制操作的允许范围（预览版）。
- 如果对存储帐户或帐户中的容器启用了版本级不可变性，则不支持时间点还原。 有关版本级别不可变性的详细信息，请参阅为 Blob 版本配置不可变性策略。
重要
如果将块 blob 还原到早于 2020 年 9 月 22 日的点，则时间点还原的预览版限制将有效。 Azure 建议你选择一个等于或晚于 2020 年 9 月 22 日的还原点，以利用正式发布的时间点还原功能。
功能支持
启用 Data Lake Storage Gen2、网络文件系统 (NFS) 3.0 协议或 SSH 文件传输协议 (SFTP) 可能会影响对此功能的支持。 如果已启用这些功能中的某一项，请参阅 Azure 存储帐户中的 Blob 存储功能支持，以评估对此功能的支持。
定价和计费
启用时间点还原不收取任何费用。 但是，启用时间点还原还会启用 blob 版本控制、软删除和更改源，其中每个都可能产生额外的费用。
对执行时间点还原操作的计费将基于为还原而处理的更改源数据量。 还原过程中涉及的所有存储事务也都将计费。
有关时间点还原定价的详细信息，请参阅块 Blob 定价。