|
| 1 | +--- |
| 2 | +title: Container-level WORM policies for immutable blob data |
| 3 | +titleSuffix: Azure Storage |
| 4 | +description: Description goes here. |
| 5 | +services: storage |
| 6 | +author: normesta |
| 7 | + |
| 8 | +ms.service: azure-blob-storage |
| 9 | +ms.topic: conceptual |
| 10 | +ms.date: 09/14/2022 |
| 11 | +ms.author: normesta |
| 12 | +--- |
| 13 | + |
| 14 | +# Container-level write once, read many (WORM) policies for immutable blob data |
| 15 | + |
| 16 | +Something needed here as an introduction. |
| 17 | + |
| 18 | +## Availability |
| 19 | + |
| 20 | +Container-level policies are available for all new and existing containers. These policies are supported for general-purpose v2, premium block blob, general-purpose v1 (legacy)*, and blob storage (legacy) accounts. This feature is supported for hierarchical namespace accounts. If hierarchical namespace is enabled, you cannot rename or move a blob when the blob is in the immutable state. Both the blob name and the directory structure provide essential container-level data that cannot be modified once the immutable policy is in place. |
| 21 | + |
| 22 | +There is no enablement process for this feature; it is automatically available for all containers. To learn more about how to set a policy on a new or existing container, see [Configure container-level immutability policies](immutable-policy-configure-container-scope.md). |
| 23 | + |
| 24 | +Microsoft recommends upgrading general-purpose v1 accounts to general-purpose v2 so that you can take advantage of more features. For information on upgrading an existing general-purpose v1 storage account, see [Upgrade a storage account](../common/storage-account-upgrade.md). |
| 25 | + |
| 26 | +## Deletion |
| 27 | + |
| 28 | +A container with a CLW policy set must be empty before the container can be deleted. If there is a policy set on a container with hierarchical namespace enabled, a directory must be empty before it can be deleted. |
| 29 | + |
| 30 | +> [!div class="mx-imgBorder"] |
| 31 | +>  |
| 32 | +
|
| 33 | +## Scenarios |
| 34 | + |
| 35 | +| Scenario | Prohibited operations | Blob protection | Container protection | Account protection | |
| 36 | +|----|----|----|-----|-----| |
| 37 | +| A container is protected by an active time-based retention policy with container scope and/or a legal hold is in effect | [Delete Blob](/rest/api/storageservices/delete-blob), [Put Blob](/rest/api/storageservices/put-blob)<sup>1</sup>, [Set Blob Metadata](/rest/api/storageservices/set-blob-metadata), [Put Page](/rest/api/storageservices/put-page), [Set Blob Properties](/rest/api/storageservices/set-blob-properties), [Snapshot Blob](/rest/api/storageservices/snapshot-blob), [Incremental Copy Blob](/rest/api/storageservices/incremental-copy-blob), [Append Block](/rest/api/storageservices/append-block)<sup>2</sup>| All blobs in the container are immutable for content and user metadata. | Container deletion fails if a container-level policy is in effect.| Storage account deletion fails if there is a container with at least one blob present.| |
| 38 | +| A container is protected by an expired time-based retention policy with container scope and no legal hold is in effect | [Put Blob](/rest/api/storageservices/put-blob)<sup>1</sup>, [Set Blob Metadata](/rest/api/storageservices/set-blob-metadata), [Put Page](/rest/api/storageservices/put-page), [Set Blob Properties](/rest/api/storageservices/set-blob-properties), [Snapshot Blob](/rest/api/storageservices/snapshot-blob), [Incremental Copy Blob](/rest/api/storageservices/incremental-copy-blob), [Append Block](/rest/api/storageservices/append-block)<sup>2</sup> | Delete operations are allowed. Overwrite operations are not allowed. | Container deletion fails if at least one blob exists in the container, regardless of whether policy is locked or unlocked. | Storage account deletion fails if there is at least one container with a locked time-based retention policy.<br>Unlocked policies do not provide delete protection.| |
| 39 | + |
| 40 | +<sup>1</sup> Azure Storage permits the [Put Blob](/rest/api/storageservices/put-blob) operation to create a new blob. Subsequent overwrite operations on an existing blob path in an immutable container are not allowed. |
| 41 | + |
| 42 | +<sup>2</sup> The [Append Block](/rest/api/storageservices/append-block) operation is permitted only for policies with the allowProtectedAppendWrites or allowProtectedAppendWritesAll property enabled. For more information, see Allow protected append blobs writes. |
| 43 | + |
| 44 | +## Allow protected append blobs writes |
| 45 | + |
| 46 | +Append blobs are composed of blocks of data and optimized for data append operations required by auditing and logging scenarios. By design, append blobs only allow the addition of new blocks to the end of the blob. Regardless of immutability, modification or deletion of existing blocks in an append blob is fundamentally not allowed. To learn more about append blobs, see [About Append Blobs](/rest/api/storageservices/understanding-block-blobs--append-blobs--and-page-blobs#about-append-blobs). |
| 47 | + |
| 48 | +The AllowProtectedAppendWrites property setting allows for writing new blocks to an append blob while maintaining immutability protection and compliance. If this setting is enabled, you can create an append blob directly in the policy-protected container and then continue to add new blocks of data to the end of the append blob with the Append Block operation. Only new blocks can be added; any existing blocks can't be modified or deleted. Enabling this setting doesn't affect the immutability behavior of block blobs or page blobs. |
| 49 | + |
| 50 | +The AllowProtectedAppendWritesAll property setting provides the same permissions as the AllowProtectedAppendWrites property and adds the ability to write new blocks to a block blob. The Blob Storage API doesn't provide a way for applications to do this directly. However, applications can accomplish this by using append and flush methods that are available in the Data Lake Storage Gen2 API. Also, this property enables Microsoft applications such as Azure Data Factory to append blocks of data by using internal APIs. If your workloads depend on any of these tools, then you can use this property to avoid errors that can appear when those tools attempt to append data to blobs. |
| 51 | + |
| 52 | +Append blobs remain in the immutable state during the effective retention period. Since new data can be appended beyond the initial creation of the append blob, there's a slight difference in how the retention period is determined. 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. |
| 53 | + |
| 54 | +For example, suppose that a user creates a time-based retention policy with the AllowProtectedAppendWrites property enabled and a retention interval of 90 days. 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 that the effective retention period for logblob1 is 100 days from today (the time of its last append + 90 days). |
| 55 | + |
| 56 | +Unlocked time-based retention policies allow the AllowProtectedAppendWrites and the AllowProtectedAppendWritesAll property settings to be enabled and disabled at any time. Once the time-based retention policy is locked, the AllowProtectedAppendWrites and the AllowProtectedAppendWritesAll property settings can't be changed. |
| 57 | + |
| 58 | +## Limits |
| 59 | + |
| 60 | +- For a storage account, the maximum number of containers with an immutable policy (time-based retention or legal hold) is 10,000. |
| 61 | + |
| 62 | +- For a container, the maximum number of legal hold tags at any one time is 10. |
| 63 | + |
| 64 | +- The minimum length of a legal hold tag is three alphanumeric characters. The maximum length is 23 alphanumeric characters. |
| 65 | + |
| 66 | +- For a container, a maximum of 10 legal hold policy audit logs are retained for the policy's duration. |
| 67 | + |
| 68 | +## Next steps |
| 69 | + |
| 70 | +- [Data protection overview](data-protection-overview.md) |
| 71 | +- [Store business-critical blob data with immutable storage](immutable-storage-overview.md) |
| 72 | +- [Version-level WORM policies](immutable-version-level-worm-policies.md) |
| 73 | +- [Configure immutability policies for blob versions](immutable-policy-configure-version-scope.md) |
| 74 | +- [Configure immutability policies for containers](immutable-policy-configure-container-scope.md) |
0 commit comments