使用不可变的存储来存储业务关键型 Blob 数据Store business-critical blob data with immutable storage

Azure Blob 存储的不可变存储可让用户以 WORM(一次写入,多次读取)状态存储业务关键型数据对象。Immutable storage for Azure Blob storage enables users to store business-critical data objects in a WORM (Write Once, Read Many) state. 此状态可以根据用户指定的时间间隔使数据保持不可擦除且不可修改的状态。This state makes the data non-erasable and non-modifiable for a user-specified interval. 在保留时间间隔期间内,可以创建和读取 Blob,但不能对其进行修改或删除。For the duration of the retention interval, blobs can be created and read, but cannot be modified or deleted. 不可变存储适用于所有 Azure 区域中的常规用途 v1、常规用途 v2、BlobStorage 和 BlockBlobStorage 帐户。Immutable storage is available for general-purpose v1, general-purpose v2, BlobStorage, and BlockBlobStorage accounts in all Azure regions.

有关如何使用 Azure 门户、PowerShell 或 Azure CLI 来设置和清除法定保留或如何创建基于时间的保留策略的信息,请参阅为 Blob 存储设置和管理不可变性策略For information about how to set and clear legal holds or create a time-based retention policy using the Azure portal, PowerShell, or Azure CLI, see Set and manage immutability policies for Blob storage.

备注

本文中所述的功能现在可用于具有分层命名空间的帐户。The features described in this article are now available to accounts that have a hierarchical namespace. 若要查看限制,请参阅 Azure Data Lake Storage Gen2 中可用的 Blob 存储功能一文。To review limitations, see the Blob storage features available in Azure Data Lake Storage Gen2 article.

关于不可变的 Blob 存储About immutable Blob storage

不可变存储可以帮助医疗保健组织、金融机构和相关行业(—尤其是证券公司—)安全存储数据。Immutable storage helps healthcare organization, financial institutions, and related industries—particularly broker-dealer organizations—to store data securely. 不可变存储还可以在任何场景中防止关键数据遭到修改或删除。Immutable storage can also be leveraged in any scenario to protect critical data against modification or deletion.

典型的应用程序包含:Typical applications include:

  • 法规遵从:Azure Blob 存储的不可变存储可帮助组织达到 SEC 17a-4(f)、CFTC 1.31(d)、FINRA 和其他法规要求。Regulatory compliance: Immutable storage for Azure Blob storage helps organizations address SEC 17a-4(f), CFTC 1.31(d), FINRA, and other regulations. Azure 信任中心包含有关我们的合规认证的详细信息。The Azure Trust Center contains detailed information about our compliance certifications.

  • 安全的文档保留:Azure Blob 存储的不可变存储确保用户(包括具有帐户管理特权的用户)无法修改或删除数据。Secure document retention: Immutable storage for Azure Blob storage ensures that data can't be modified or deleted by any user, including users with account administrative privileges.

  • 法定保留:Azure Blob 存储的不可变存储允许用户以防篡改状态存储对诉讼或商业用途而言非常重要的敏感信息,可将这些信息存储所需的一段时间,然后将其删除。Legal hold: Immutable storage for Azure Blob storage enables users to store sensitive information that is critical to litigation or business use in a tamper-proof state for the desired duration until the hold is removed. 此功能并不局限于法律用例,而且还可将它视为基于事件的保留或企业锁定机制,满足企业根据事件触发器或政策保护数据的需求。This feature is not limited only to legal use cases but can also be thought of as an event-based hold or an enterprise lock, where the need to protect data based on event triggers or corporate policy is required.

不可变存储支持以下功能:Immutable storage supports the following features:

  • 基于时间的保留策略支持 :用户可以设置策略,按指定的时间间隔存储数据。Time-based retention policy support: Users can set policies to store data for a specified interval. 设置基于时间的保留策略后,可以创建和读取 Blob,但不能修改或删除 Blob。When a time-based retention policy is set, blobs can be created and read, but not modified or deleted. 保留期过后,可以删除但不能覆盖 Blob。After the retention period has expired, blobs can be deleted but not overwritten.

  • 法定保留策略支持 :如果保留时间间隔未知,用户可以设置法定保留来存储不可变数据,直至法定保留得以清除。Legal hold policy support: If the retention interval is not known, users can set legal holds to store immutable data until the legal hold is cleared. 设置法定保留策略后,可以创建和读取 Blob,但不能修改或删除 Blob。When a legal hold policy is set, blobs can be created and read, but not modified or deleted. 每个法定保留都与一个用户定义的用作标识符字符串的字母数字标记(例如案例 ID、事件名称等)相关联。Each legal hold is associated with a user-defined alphanumeric tag (such as a case ID, event name, etc.) that is used as an identifier string.

  • 支持所有 Blob 层:WORM 策略独立于 Azure Blob 存储层,将应用到所有层:热层、冷层和存档层。Support for all blob tiers: WORM policies are independent of the Azure Blob storage tier and apply to all the tiers: hot, cool, and archive. 用户可将工作负荷的数据转换为最具成本效益的层,同时保持数据的不可变性。Users can transition data to the most cost-optimized tier for their workloads while maintaining data immutability.

  • 容器级配置:用户可在容器级别配置基于时间的保留策略和法定保留标记。Container-level configuration: Users can configure time-based retention policies and legal hold tags at the container level. 通过使用简单的容器级设置,用户可以创建并锁定基于时间的保留策略、扩展保留时间间隔、设置并清除法定保留,等等。By using simple container-level settings, users can create and lock time-based retention policies, extend retention intervals, set and clear legal holds, and more. 这些策略将应用到容器中的所有 Blob,不管是现有的还是新的 Blob。These policies apply to all the blobs in the container, both existing and new.

  • 审核日志记录支持:每个容器包含一个策略审核日志。Audit logging support: Each container includes a policy audit log. 该日志显示针对锁定的基于时间的保留策略执行的最多七个基于时间的保留命令,并且包含用户 ID、命令类型、时间戳和保留时间间隔。It shows up to seven time-based retention commands for locked time-based retention policies and contains the user ID, command type, time stamps, and retention interval. 对于法定保留,日志包含用户 ID、命令类型、时间戳和法定保留标记。For legal holds, the log contains the user ID, command type, time stamps, and legal hold tags. 根据 SEC 17a-4(f) 法规准则,此日志的保留时间就是策略的生存时间。This log is retained for the lifetime of the policy, in accordance with the SEC 17a-4(f) regulatory guidelines. Azure 活动日志显示所有控制平面活动的更全面日志;同时,启用 Azure 资源日志可以保留和显示数据平面操作。The Azure Activity Log shows a more comprehensive log of all the control plane activities; while enabling Azure Resource Logs retains and shows data plane operations. 由用户负责根据法规要求或其他要求永久存储这些日志。It is the user's responsibility to store those logs persistently, as might be required for regulatory or other purposes.

工作原理How it works

Azure Blob 存储的不可变存储支持两类 WORM 或不可变策略:基于时间的保留和法定保留。Immutable storage for Azure Blob storage supports two types of WORM or immutable policies: time-based retention and legal holds. 在容器上应用基于时间的保留策略或法定保留时,所有现有的 Blob 会在 30 秒内转为不可变的 WORM 状态。When a time-based retention policy or legal hold is applied on a container, all existing blobs move into an immutable WORM state in less than 30 seconds. 所有上传到受该策略保护的容器的新 Blob 也会转为不可变状态。All new blobs that are uploaded to that policy protected container will also move into an immutable state. 所有 Blob 转为不可变状态后,将确认不可变策略,并且不允许在不可变容器中执行任何覆盖或删除操作。Once all blobs are in an immutable state, the immutable policy is confirmed and any overwrite or delete operations in the immutable container are not allowed.

如果容器中的任何 Blob 受到法定保留策略或锁定的基于时间的策略的保护,则也不允许删除容器和存储帐户。Container and storage account deletion are also not permitted if there are any blobs in a container that are protected by a legal hold or a locked time-based policy. 法定保留策略会防止删除 Blob、容器和存储帐户。A legal hold policy will protect against blob, container, and storage account deletion. 锁定的和未锁定的基于时间的策略会防止在指定的时间删除 Blob。Both unlocked and locked time-based policies will protect against blob deletion for the specified time. 仅当容器中至少有一个 Blob 时,未锁定和锁定的基于时间的策略才会防止删除容器。Both unlocked and locked time-based policies will protect against container deletion only if at least one blob exists within the container. 只有具有锁定的基于时间的策略的容器才能防止删除存储帐户;具有未锁定的基于时间的策略的容器不提供存储帐户删除保护与合规性。Only a container with locked time-based policy will protect against storage account deletions; containers with unlocked time-based policies do not offer storage account deletion protection nor compliance.

若要详细了解如何设置和锁定基于时间的保留策略,请参阅为 Blob 存储设置和管理不可变性策略For more information on how to set and lock time-based retention policies, see Set and manage immutability policies for Blob storage.

基于时间的保留策略Time-based retention policies

重要

根据 SEC 17a-4(f) 和其他法规符合性要求,基于时间的保留策略必须处于锁定状态才能确保 Blob 既兼容又不可变(不可写入和删除)。A time-based retention policy must be locked for the blob to be in a compliant immutable (write and delete protected) state for SEC 17a-4(f) and other regulatory compliance. 我们建议将策略锁定合理的时间,通常不到 24 小时。We recommend that you lock the policy in a reasonable amount of time, typically less than 24 hours. 已应用的基于时间的保留策略的初始状态为“未锁定”,在此状态下可以先测试该功能,并在锁定之前对策略进行更改。The initial state of an applied time-based retention policy is unlocked, allowing you to test the feature and make changes to the policy before you lock it. 虽然“未锁定”状态提供不变性保护,但除非是短时功能试用,否则我们不建议使用未锁定状态。 While the unlocked state provides immutability protection, we don't recommend using the unlocked state for any purpose other than short-term feature trials.

在容器上应用基于时间的保留策略时,容器中的所有 Blob 都会保持在不可变的状态,其持续时间就是有效保留期。When a time-based retention policy is applied on a container, all blobs in the container will stay in the immutable state for the duration of the effective retention period. Blob 的有效保持期就是 Blob 创建时间和用户指定的保留时间间隔之间的差异。The effective retention period for blobs is equal to the difference between the blob's creation time and the user-specified retention interval. 由于用户可以延长保留时间间隔,因此不可变存储使用用户指定的保留时间间隔的最新值来计算有效保留期。Because users can extend the retention interval, immutable storage uses the most recent value of the user-specified retention interval to calculate the effective retention period.

例如,假设用户创建了一个基于时间的保留策略,将保留时间间隔设置为五年。For example, suppose that a user creates a time-based retention policy with a retention interval of five years. 一年前,在该容器中创建了现有的 Blob testblob1;因此,testblob1 的有效保留期为四年。An existing blob in that container, testblob1, was created one year ago; so, the effective retention period for testblob1 is four years. 将新 Blob testblob2 上传到容器后,testblob2 的有效保留期为五年(从其创建时间开始算起)。When a new blob, testblob2, is uploaded to the container, the effective retention period for the testblob2 is five years from the time of its creation.

根据 SEC 17a-4(f) 和其他法规符合性要求,基于时间的未锁定保留策略只建议用于功能测试,而通常情况下策略必须处于锁定状态。An unlocked time-based retention policy is recommended only for feature testing and a policy must be locked in order to be compliant with SEC 17a-4(f) and other regulatory compliance. 一旦基于时间的保留策略处于锁定状态,就不能将该策略删除,但允许延长有效保留期限,最多延迟五次。Once a time-based retention policy is locked, the policy cannot be removed and a maximum of five increases to the effective retention period is allowed.

以下限制适用于保留策略:The following limits apply to retention policies:

  • 对于存储帐户,具有锁定的基于时间的不可变策略的最大容器数为 10,000。For a storage account, the maximum number of containers with locked time-based immutable policies is 10,000.
  • 最小保留时间间隔为 1 天。The minimum retention interval is 1 day. 最大值为 146,000 天(400 年)。The maximum is 146,000 days (400 years).
  • 对于容器而言,为了延长锁定的基于时间的不可变策略的保留时间间隔而可执行的最大编辑次数为 5。For a container, the maximum number of edits to extend a retention interval for locked time-based immutable policies is 5.
  • 对于容器而言,将针对锁定策略最多保留七个基于时间的保留策略审核日志。For a container, a maximum of seven time-based retention policy audit logs are retained for a locked policy.

允许受保护的追加 Blob 写入Allow protected append blobs writes

追加 Blob 由数据块组成,并针对审核和日志记录方案所需的数据追加操作进行了优化。Append blobs are comprised of blocks of data and optimized for data append operations required by auditing and logging scenarios. 按照设计,追加 Blob 只允许将新块添加到 Blob 末尾。By design, append blobs only allow the addition of new blocks to the end of the blob. 无论是否不可变,基本上都不允许修改或删除追加 Blob 中的现有块。Regardless of immutability, modification or deletion of existing blocks in an append blob is fundamentally not allowed. 若要详细了解追加 Blob,请参阅关于追加 BlobTo learn more about append blobs, see About Append Blobs.

仅基于时间的保留策略具有 allowProtectedAppendWrites 设置,该设置允许将新块写入追加 Blob,同时维持不可变性保护和符合性。Only time-based retention policies have an allowProtectedAppendWrites setting that allows for writing new blocks to an append blob while maintaining immutability protection and compliance. 在启用此设置的情况下,你可以直接在受策略保护的容器中创建追加 Blob,并使用 AppendBlock API 继续向现有追加 Blob 的末尾添加新数据块。If this setting is enabled, you are allowed to create an append blob directly in the policy protected container and continue to add new blocks of data to the end of existing append blobs using the AppendBlock API. 只能添加新块,而不能修改或删除任何现有块。Only new blocks can be added and any existing blocks cannot be modified or deleted. 时间保留不可变性保护仍适用,系统会阻止删除追加 Blob,直到有效的保留期结束。Time-retention immutability protection still applies, preventing deletion of the append blob until the effective retention period has elapsed. 启用此设置不影响块 Blob 或页 Blob 的不可变性行为。Enabling this setting does not affect the immutability behavior of block blobs or page blobs.

由于此设置是基于时间的保留策略的一部分,因此在有效保留期内追加 Blob 仍会保持不可变状态。As this setting is part of a time-based retention policy, the append blobs still stay in the immutable state for the duration of the effective retention period. 由于新数据可以在最初创建追加 Blob 之后追加,因此确定保留期的方式略有不同。Since new data can be appended beyond the initial creation of the append blob, there is a slight difference in how the retention period is determined. 有效保留期是追加 Blob 的上次修改时间和用户指定的保留时间间隔之差。The effective retention is the difference between append blob's last modification time and the user-specified retention interval. 类似地,当延长保留时间间隔时,不可变存储使用用户指定的保留时间间隔的最新值来计算有效保留期。Similarly when the retention interval is extended, immutable storage uses the most recent value of the user-specified retention interval to calculate the effective retention period.

例如,假设用户创建了一项基于时间的保留策略,在启用 allowProtectedAppendWrites 的同时将保留时间间隔设置为 90 天。For example, suppose that a user creates a time-based retention policy with allowProtectedAppendWrites enabled and a retention interval of 90 days. 现在,我们在容器中创建了追加 Blob logblob1,并会在接下来的 10 天内继续将新日志添加到追加 Blob,因此,logblob1 的有效保留期是从今天开始算起的 100 天(上次追加的时间 + 90 天)。An append blob, logblob1, is created in the container today, new logs continue to be added to the append blob for the next 10 days; so, the effective retention period for the logblob1 is 100 days from today (the time of its last append + 90 days).

未锁定的基于时间的保留策略允许随时启用和禁用 allowProtectedAppendWrites 设置。Unlocked time-based retention policies allow the allowProtectedAppendWrites setting to be enabled and disabled at any time. 锁定基于时间的保留策略后,不能更改 allowProtectedAppendWrites 设置。Once the time-based retention policy is locked, the allowProtectedAppendWrites setting cannot be changed.

法定保留策略无法启用 allowProtectedAppendWrites,任何法定保留都会将“allowProtectedAppendWrites”属性设置为 null。Legal hold policies cannot enable allowProtectedAppendWrites and any legal holds will nullify the 'allowProtectedAppendWrites' property. 如果在启用 allowProtectedAppendWrites 的情况下将法定保留应用于基于时间的保留策略,则 AppendBlock API 会失败,除非取消法定保留。If a legal hold is applied to a time-based retention policy with allowProtectedAppendWrites enabled, the AppendBlock API will fail until the legal hold is lifted.

法律保留是可用于法律调查目的或常规保护策略的临时保留。Legal holds are temporary holds that can be used for legal investigation purposes or general protection policies. 每个法定保留策略需要与一个或多个标记相关联。Each legal hold policy needs to be associated with one or more tags. 标记用作命名标识符(例如案例 ID 或事件),用于分类和描述保留的用途。Tags are used as a named identifier, such as a case ID or event, to categorize and describe the purpose of the hold.

容器可能会同时有法定保留策略和基于时间的保留策略。A container can have both a legal hold and a time-based retention policy at the same time. 该容器中的所有 Blob 会一直保持不可变状态,直至所有法定保留被清除,即使有效保留期已过。All blobs in that container stay in the immutable state until all legal holds are cleared, even if their effective retention period has expired. 与之相反,即使所有法定保留已被清除,Blob 也会保持不可变状态,直至有效保留期已过。Conversely, a blob stays in an immutable state until the effective retention period expires, even though all legal holds have been cleared.

以下限制适用于法定保留:The following limits apply to legal holds:

  • 对于存储帐户,使用法定保留设置的最大容器数为 10,000。For a storage account, the maximum number of containers with a legal hold setting is 10,000.
  • 对于某个容器而言,最大法定保留标记数为 10。For a container, the maximum number of legal hold tags is 10.
  • 法定保留标记的最小长度为三个字母数字字符。The minimum length of a legal hold tag is three alphanumeric characters. 最大长度为 23 个字母数字字符。The maximum length is 23 alphanumeric characters.
  • 对于容器而言,将根据策略的持续时间最多保留 10 个法定保留策略审核日志。For a container, a maximum of 10 legal hold policy audit logs are retained for the duration of the policy.

方案Scenarios

下表显示了会因各种不可变方案而禁用的 Blob 存储操作的类型。The following table shows the types of Blob storage operations that are disabled for the different immutable scenarios. 有关详细信息,请参阅 Azure Blob 服务 REST API 文档。For more information, see the Azure Blob Service REST API documentation.

方案Scenario Blob 状态Blob state Blob 操作被拒绝Blob operations denied 容器和帐户保护Container and account protection
Blob 的有效保留时间间隔尚未到期,并且/或者法定保留已设置Effective retention interval on the blob has not yet expired and/or legal hold is set 不可变:不可删除和写入Immutable: both delete and write-protected 放置 Blob1、放置块1、放置块列表1、删除容器、删除 Blob、设置 Blob 元数据、放置页、设置 Blob 属性、快照 Blob、增量复制 Blob、追加块2Put Blob1, Put Block1, Put Block List1, Delete Container, Delete Blob, Set Blob Metadata, Put Page, Set Blob Properties, Snapshot Blob, Incremental Copy Blob, Append Block2 容器删除操作被拒绝;存储帐户删除操作被拒绝Container deletion denied; Storage Account deletion denied
Blob 的有效保留间隔已过期,且未设置法定保留Effective retention interval on the blob has expired and no legal hold is set 仅仅不可写入(允许删除操作)Write-protected only (delete operations are allowed) 放置 Blob1、放置块1、放置块列表1、设置 Blob 元数据、放置页、设置 Blob 属性、快照 Blob、增量复制 Blob、追加块2Put Blob1, Put Block1, Put Block List1, Set Blob Metadata, Put Page, Set Blob Properties, Snapshot Blob, Incremental Copy Blob, Append Block2 如果受保护容器中至少存在 1 个 Blob,则容器删除操作将被拒绝;仅拒绝锁定的基于时间的策略的存储帐户删除操作Container deletion denied if at least 1 blob exists within protected container; Storage Account deletion denied only for locked time-based policies
未应用 WORM 策略(没有基于时间的保留,也没有法定保留标记)No WORM policy applied (no time-based retention and no legal hold tag) 可变Mutable None None

1 Blob 服务允许这些操作创建新的 Blob 一次。1 The blob service allows these operations to create a new blob once. 不允许针对不可变容器中的现有 Blob 路径执行任何后续覆盖操作。All subsequent overwrite operations on an existing blob path in an immutable container are not allowed.

2 追加块只能用于基于时间且启用了 allowProtectedAppendWrites 属性的保留策略。2 Append Block is only allowed for time-based retention policies with the allowProtectedAppendWrites property enabled. 有关详细信息,请参阅允许受保护的追加 Blob 写入部分。For more information, see the Allow Protected Append Blobs Writes section.

定价Pricing

使用此功能不会产生额外的费用。There is no additional charge for using this feature. 不可变数据的定价方式与可变数据的定价方式相同。Immutable data is priced in the same way as mutable data. 有关 Azure Blob 存储中的定价详细信息,请参阅 Azure 存储定价页For pricing details on Azure Blob storage, see the Azure Storage pricing page.

常见问题FAQ

你们是否可以提供有关 WORM 合规性的文档?Can you provide documentation of WORM compliance?

是的。Yes. 为了表明我们的合规性,Azure 一直在与一家领先的独立评估机构 Cohasset Associates 保持合作。该机构专业从事记录管理和信息监管,可以评估不可变的 Blob 存储及其是否符合金融服务行业的相关要求。To document compliance, Azure retained a leading independent assessment firm that specializes in records management and information governance, Cohasset Associates, to evaluate immutable Blob storage and its compliance with requirements specific to the financial services industry. 经 Cohasset 验证,在用于保留 WORM 状态的基于时间的 Blob 时,不可变 Blob 存储符合 CFTC 规则 1.31(c)-(d)、FINRA 规则 4511 和 SEC 规则 17a-4 的相关存储要求。Cohasset validated that immutable Blob storage, when used to retain time-based Blobs in a WORM state, meets the relevant storage requirements of CFTC Rule 1.31(c)-(d), FINRA Rule 4511, and SEC Rule 17a-4. Azure 以这一套规则为目标,因为这些规则代表了全球最规范的金融机构记录保留准则。Azure targeted this set of rules, as they represent the most prescriptive guidance globally for records retention for financial institutions. Azure 服务信任中心已提供 Cohasset 的报告。The Cohasset report is available in the Azure Service Trust Center. 若要向 Azure 请求有关 WORM 不可变性合规性的证明信,请联系 Azure 支持。To request a letter of attestation from Azure regarding WORM immutability compliance, please contact Azure support.

此功能是只适用于块 Blob 和追加 Blob,还是也适用于页 Blob?Does the feature apply to only block blobs and append blobs, or to page blobs as well?

不可变存储可以用于任何 Blob 类型,因为它是在容器级别设置的,但我们建议你将 WORM 用于主要存储块 Blob 和追加 Blob 的容器。Immutable storage can be used with any blob type as it is set at the container level, but we recommend that you use WORM for containers that mainly store block blobs and append blobs. 容器中的现有 Blob 将受新设置的 WORM 策略的保护。Existing blobs in a container will be protected by a newly set WORM policy. 但是,需要在 WORM 容器外部创建任何新的页 Blob,然后复制它。But any new page blobs need to be created outside the WORM container, and then copied in. 复制到 WORM 容器中后,不再允许对页 Blob 进行更改。Once copied into a WORM container, no further changes to a page blob are allowed. 建议不要在存储 VHD(页 Blob)的容器上为任何活动的虚拟机设置 WORM 策略,因为它会锁定 VM 磁盘。Setting a WORM policy on a container that stores VHDs (page blobs) for any active virtual machines is discouraged as it will lock the VM disk. 建议在锁定任何基于时间的策略之前,仔细查看文档并测试方案。We recommend that you thoroughly review the documentation and test your scenarios before locking any time-based policies.

是否需要创建新的存储帐户才能使用此功能?Do I need to create a new storage account to use this feature?

否。可将不可变存储与任何现有的或新建的常规用途 v1、常规用途 v2、BlobStorage 或 BlockBlobStorage 帐户配合使用。No, you can use immutable storage with any existing or newly created general-purpose v1, general-purpose v2, BlobStorage, or BlockBlobStorage accounts. 支持常规用途 v1 存储帐户,但我们建议升级到常规用途 v2,以便能够利用更多功能。General-purpose v1 storage accounts are supported but we recommend upgrading to general-purpose v2 such that you can take advantage of more features. 有关升级现有常规用途 v1 存储帐户的信息,请参阅升级存储帐户For information on upgrading an existing general-purpose v1 storage account, see Upgrade a storage account.

是否可以同时应用法定保留和基于时间的保留策略?Can I apply both a legal hold and time-based retention policy?

是的。容器可以同时有法定保留和基于时间的保留策略;但是,在清除法定保留之前,“allowProtectedAppendWrites”设置不会应用。Yes, a container can have both a legal hold and a time-based retention policy at the same time; however, the 'allowProtectedAppendWrites' setting will not apply until the legal hold is cleared. 该容器中的所有 Blob 会一直保持不可变状态,直至所有法定保留被清除,即使有效保留期已过。All blobs in that container stay in the immutable state until all legal holds are cleared, even if their effective retention period has expired. 与之相反,即使所有法定保留已被清除,Blob 也会保持不可变状态,直至有效保留期已过。Conversely, a blob stays in an immutable state until the effective retention period expires, even though all legal holds have been cleared.

法定保留是否仅用于法律诉讼程序;是否还存在其他使用方案?Are legal hold policies only for legal proceedings or are there other use scenarios?

否。法定保留只是非基于时间的保留策略的概括术语。No, Legal Hold is just the general term used for a non-time-based retention policy. 它并非只用于诉讼相关的程序。It does not need to only be used for litigation-related proceedings. 在保留期为未知的情况下,法定保留策略可用于禁用覆盖和删除,以保护重要的企业 WORM 数据。Legal Hold policies are useful for disabling overwrite and deletes for protecting important enterprise WORM data, where the retention period is unknown. 可将它用作一种企业策略来保护任务关键的 WORM 工作负荷,或者在自定义事件触发器要求使用基于时间的保留策略之前,将它用作一种临时策略。You may use it as an enterprise policy to protect your mission critical WORM workloads or use it as a staging policy before a custom event trigger requires the use of a time-based retention policy.

是否可以删除锁定的基于时间的保留策略或法定保留?Can I remove a locked time-based retention policy or legal hold?

只能从容器中删除未锁定的基于时间的保留策略。Only unlocked time-based retention policies can be removed from a container. 一旦基于时间的保留策略处于锁定状态,就不能将其删除,只能进行有效的保留期延长。Once a time-based retention policy is locked, it cannot be removed; only effective retention period extensions are allowed. 法定保留标记可以删除。Legal hold tags can be deleted. 删除所有法定标记以后,就会删除法定保留。When all legal tags are deleted, the legal hold is removed.

如果尝试删除某个容器,而该容器具有基于时间的保留策略或法定保留,会发生什么情况?What happens if I try to delete a container with a time-based retention policy or legal hold?

如果容器中至少有一个 Blob 具有锁定的或未锁定的基于时间的保留策略,或者容器具有法定保留,则“删除容器”操作将会失败。The Delete Container operation will fail if at least one blob exists within the container with either a locked or unlocked time-based retention policy or if the container has a legal hold. 仅当容器中没有 Blob 且没有法定保留时,“删除容器”操作才会成功。The Delete Container operation will succeed only if no blobs exist within the container and there are no legal holds.

如果尝试删除的存储帐户有一个容器,而该容器具有基于时间的保留策略或法定保留,会发生什么情况?What happens if I try to delete a storage account with a container that has a time-based retention policy or legal hold?

如果至少有一个容器设置了法定保留或者具有锁定的基于时间的策略,则存储帐户删除操作将会失败。The storage account deletion will fail if there is at least one container with a legal hold set or a locked time-based policy. 具有未锁定的基于时间的策略的容器无法防止删除存储帐户。A container with an unlocked time-based policy does not protect against storage account deletion. 在删除存储帐户之前,必须先删除所有法定保留,并删除所有锁定的容器。You must remove all legal holds and delete all locked containers before you can delete the storage account. 有关删除容器的信息,请查看上一个问题。For information on container deletion, see the preceding question. 还可以使用 Azure 资源管理器锁为存储帐户应用更多的删除保护。You can also apply further delete protections for your storage account with Azure Resource Manager locks.

当 Blob 处于不可变状态时,是否可以跨不同的 Blob 层(热、冷、存档)来移动数据?Can I move the data across different blob tiers (hot, cool, archive) when the blob is in the immutable state?

是的,可以在数据处于合规的不可变状态时使用“设置 Blob 层”命令跨 Blob 层移动数据。Yes, you can use the Set Blob Tier command to move data across the blob tiers while keeping the data in the compliant immutable state. 热、冷和存档 Blob 层均支持不可变存储。Immutable storage is supported on hot, cool, and archive blob tiers.

如果我无法付款,但我的保留时间间隔尚未到期,会发生什么情况?What happens if I fail to pay and my retention interval has not expired?

在未付款的情况下,会根据你与 Azure 签署的合同条款与条件应用常规的数据保留策略。In the case of non-payment, normal data retention policies will apply as stipulated in the terms and conditions of your contract with Azure.

你们是否为只想试用此功能的用户提供试用期或宽限期?Do you offer a trial or grace period for just trying out the feature?

是的。Yes. 基于时间的保留策略在首先创建时,将处于未锁定状态。When a time-based retention policy is first created, it is in an unlocked state. 在这种状态下,可以对保留时间间隔进行所需的更改,例如延长或缩短保留时间间隔,甚至可以删除策略。In this state, you can make any desired change to the retention interval, such as increase or decrease and even delete the policy. 策略被锁定后,它将保持锁定状态,直到保留时间间隔到期为止。After the policy is locked, it stays locked until the retention interval expires. 此锁定策略可以防止删除和修改保留时间间隔。This locked policy prevents deletion and modification to the retention interval. 我们强烈建议仅在试用的情况下使用未锁定状态,并在 24 小时内锁定策略。We strongly recommend that you use the unlocked state only for trial purposes and lock the policy within a 24-hour period. 这种做法有助于遵守 SEC 17a-4(f) 及其他法规。These practices help you comply with SEC 17a-4(f) and other regulations.

是否可以同时使用软删除和不可变的 Blob 策略?Can I use soft delete alongside Immutable blob policies?

是,前提是合规性要求允许启用软删除。Yes, if your compliance requirements allow for soft delete to be enabled. Azure Blob 存储的软删除适用于存储帐户中的所有容器,无论使用的是法定保留还是基于时间的保留策略。Soft delete for Azure Blob storage applies for all containers within a storage account regardless of a legal hold or time-based retention policy. 我们建议在应用并确认任何不可变 WORM 策略之前启用软删除,以提供额外的保护。We recommend enabling soft delete for additional protection before any immutable WORM policies are applied and confirmed.

后续步骤Next steps