块 Blob 的时间点还原

时间点还原使你能够将块 Blob 数据恢复到较早状态，从而防止意外删除或损坏。该功能在用户或应用程序意外删除数据或应用程序错误导致数据损坏的情况中非常有用。时间点还原还支持测试方案，这些方案需要在运行其他测试之前将数据集还原到已知状态。

点时恢复仅支持标准性能层的通用v2存储账户。你只能通过点时恢复恢复热和冷访问层的数据。目前，在具有层级命名空间的账户中，时间点还原并不被支持。

若要了解如何对存储帐户启用时间点还原，请参阅对块 blob 数据执行时间点还原。

时间点还原的工作原理

要启用时间点还原，请为存储账户创建管理策略并指定保留期限。在保持期内，可以将块 blob 从当前状态还原到上一个时间点的状态。

若要启动时间点还原，请调用还原 Blob 范围操作并指定 UTC 时间的还原点。可以指定要还原的容器和 blob 名称的词典序范围，或省略该范围以还原存储帐户中的所有容器。每个还原操作最多支持10个字典序范围。

Azure 存储分析在请求的恢复点（UTC 时间指定）到当前时刻之间对指定 blobs 所做的所有变更。还原操作是原子操作，因此要么完全还原所有更改，要么失败。如果存在任何无法恢复的 blob，则该操作将失败，并且受影响容器的读写操作将恢复。

下图介绍了时间点还原的工作原理。一个或多个容器或 blob 范围已还原到其 n 天前的状态，其中 n 小于或等于为时间点还原定义的保持期。其作用是还原在保持期内发生的写入和删除操作。

示意时间点还原如何将块 Blob 容器恢复到之前的状态。

你一次只能对一个存储账户运行一次恢复操作。恢复操作进行中无法取消，但你可以执行第二次恢复操作来撤销第一次操作。

“还原 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 天前的数据。

时间点还原的保持期必须至少比为软删除指定的保持期少一天。例如，如果软删除保留期设置为七天，那么时间点还原保留期可以在1到6天之间。

注意

为时间点还原指定的保留期对 blob 版本的保留期没有影响。 Blob 版本将一直保留，直到显式删除为止。若要通过删除旧版本或对其分层来优化成本，请创建一个生命周期管理策略。有关详细信息，请参阅通过自动管理数据生命周期来优化成本。

还原一组数据所用的时间取决于在还原期间执行的写入和删除操作的次数。例如，一个账户拥有100万个blob，每天添加3000个blob，每天删除1000个blob，恢复到30天前的某个点大约需要两个小时。对于这种变动速度的账户，不建议设置保留期和恢复到 90 天以前的时间点。

时间点恢复权限

要启动恢复操作，客户端必须对存储账户中的所有容器拥有写入权限。要授权使用 Microsoft Entra ID 进行恢复操作，请在存储账户、资源组或订阅级别将存储帐户参与者角色分配给安全主体。

功能支持

启用 Data Lake Storage Gen2、网络文件系统 (NFS) 3.0 协议或 SSH 文件传输协议 (SFTP) 可能会影响对此功能的支持。如果已启用这些功能中的某一项，请参阅 Azure 存储帐户中的 Blob 存储功能支持，以评估对此功能的支持。

特征交互

时间点恢复依赖于多种其他数据保护特性，并且与这些功能相互作用，这可能会使恢复变得复杂。在启用时间点恢复前，请先阅读以下信息。

Blob版本控制、软删除和更改源（必要的前提条件）： 您必须启用这三个功能，才能开启时间点还原。这一要求有下游影响：每次写操作都会生成新的 blob 版本，这会增加存储成本，因为版本化 blob 会持续存在，直到你明确删除它们。时间点还原保留期必须至少比软删除和变更流保留期少一天。恢复的计费基于处理的变更馈送数据量。
不可变性策略： 你可以在有不可变性策略的账户上发起恢复，但恢复操作不会修改受策略保护的blobs。因此，恢复的数据可能无法反映所请求的时间点的一致状态。
快照： 恢复操作不会创建或删除快照。只有基础 blob（当前版本）会被还原到之前的状态。
客户管理的故障切换： 执行客户管理的故障切换会重置存储账户的最早可用还原点。发生故障转移后，你无法恢复到故障转移发生前的时间点。更多细节请参见“时间点恢复不一致”。

已知的限制

块 blob 的时间点还原具有以下限制和已知问题：

你只能在标准通用 v2 存储账户中将块 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 提供的时间戳时的上一版本不同，那么恢复操作会以原子方式失败。在启动恢复操作前，先解除所有有效的租约。
分层命名空间或通过 Azure Data Lake Storage 进行的操作不支持时间点还原。
当存储帐户的 AllowedCopyScope 属性设置为将复制范围限制为同一 Microsoft Entra 租户或虚拟网络时，不支持时间点还原。有关详细信息，请参阅关于复制操作的允许范围（预览版）。
如果对存储帐户或帐户中的容器启用了版本级不可变性，则不支持时间点还原。有关版本级别不可变性的详细信息，请参阅为 Blob 版本配置不可变性策略。

故障排除和监视

我无法启用 PITR：启用 PITR 需要软删除 blobs、blob 版本控制和更改源作为先决条件。检查这些先决条件已启用。
我无法恢复到目标时间：PITR要求目标时间戳必须在配置的保留窗口内。检查恢复时间是否在保留期内。
我的 PITR 恢复时间太长：PITR 的持续时间取决于数据量和恢复范围。检查一下作用域是否正确（容器集或对象集）。目前没有办法监控PITR的恢复进展。如果恢复显示卡住或比预期更长时间，请在 Azure 门户中开启支持请求。
PITR已完成，但我的数据仍然缺失：PITR会恢复到选定的时间点和范围。检查你是否选择了正确的账户、容器、路径和时间戳。
启用PITR后我的存储成本增加了：带有版本控制和保留的PITR会随着时间推移增加存储数据。检查生命周期规则和保留设置是否已优化。

重要

如果你将块 Blob 还原到早于 2020 年 9 月 22 日的时间点，则时间点还原的预览限制仍然生效。 Azure 建议你选择一个等于或晚于 2020 年 9 月 22 日的还原点，以利用正式发布的时间点还原。

定价和计费

启用时间点还原不收取任何费用。然而，启用时间点还原也会启用 blob 版本控制、软删除和更改源，这些都可能导致额外费用。

时间点还原操作的计费基于恢复过程中处理的变更数据量。你还需支付恢复过程中涉及的任何存储交易费用。

有关时间点还原定价的详细信息，请参阅块 Blob 定价。

后续步骤

Última atualização em 2026-10-16