Rediger

Soft delete for blobs

Blob soft delete protects an individual blob, snapshot, or version from accidental deletes or overwrites by keeping the deleted data in the system for a specified period. During the retention period, you can restore a soft-deleted object to its state at the time it was deleted. After the retention period expires, the object is permanently deleted.

Blob soft delete is part of a comprehensive in-account data protection strategy for blob data. For optimal protection of your blob data, Microsoft recommends enabling the following data protection features:

For protection against broader data loss scenarios such as accidental account deletion or ransomware, consider enabling Azure Backup in addition to in-account features. To learn more about Microsoft's recommendations for data protection, see Data protection overview.

Caution

After you enable blob versioning for a storage account, every write operation to a blob in that account creates a new version. For this reason, enabling blob versioning might result in extra costs. To minimize costs, use a lifecycle management policy to automatically delete old versions. For more information about lifecycle management, see Optimize costs by automating Azure Blob Storage access tiers.

How blob soft delete works

When you enable blob soft delete for a storage account, you specify a retention period for deleted objects of between 1 and 365 days. The retention period indicates how long the data remains available after it's deleted or overwritten. The clock starts on the retention period as soon as an object is deleted or overwritten.

While the retention period is active, you can restore a deleted blob, together with its snapshots, or a deleted version by calling the Undelete Blob operation. The following diagram shows how a deleted object can be restored when blob soft delete is enabled:

Screenshot of how a soft-deleted blob can be restored during the retention period.

You can change the soft delete retention period at any time. An updated retention period applies only to data that was deleted after the retention period was changed. Any data that was deleted before the retention period was changed is subject to the retention period that was in effect when it was deleted.

Attempting to delete a soft-deleted object doesn't affect its expiry time.

If you disable blob soft delete, you can continue to access and recover soft-deleted objects in your storage account until the soft delete retention period has elapsed.

Blob versioning, which Microsoft recommends enabling alongside soft delete, is available for general-purpose v2, block blob, and Blob storage accounts. Versioning isn't supported for accounts that have a hierarchical namespace.

Version 2017-07-29 and higher of the Azure Storage REST API supports blob soft delete.

Important

You can use blob soft delete only to restore an individual blob, snapshot, directory (in a hierarchical namespace) or version. To restore a container and its contents, container soft delete must also be enabled for the storage account. Microsoft recommends enabling container soft delete and blob versioning together with blob soft delete to ensure complete protection for blob data. For more information, see Data protection overview.

Blob soft delete does not protect against the deletion of a storage account. To protect a storage account from deletion, configure a lock on the storage account resource. For more information about locking a storage account, see Apply an Azure Resource Manager lock to a storage account.

How deletions are handled when soft delete is enabled

When you enable blob soft delete, deleting a blob marks that blob as soft deleted. The deletion doesn't create a snapshot. When the retention period expires, the soft-deleted blob is permanently deleted. In accounts that have a hierarchical namespace, the access control list of a blob is unaffected and remains intact if the blob is restored.

If a blob has snapshots, you can't delete the blob unless you also delete the snapshots. When you delete a blob and its snapshots, both the blob and snapshots are marked as soft deleted. The deletion doesn't create new snapshots.

You can also delete one or more active snapshots without deleting the base blob. In this case, the snapshot is soft-deleted.

If you delete a directory in an account that has the hierarchical namespace feature enabled on it, the directory and all its contents are marked as soft deleted. You can access only the soft-deleted directory. To access the contents of the soft-deleted directory, you need to undelete the soft-deleted directory.

Soft-deleted objects are invisible unless they're explicitly displayed or listed. For more information about how to list soft-deleted objects, see Manage and restore soft-deleted blobs.

How overwrites are handled when soft delete is enabled

Important

This section doesn't apply to accounts that have a hierarchical namespace.

Calling an operation such as Put Blob, Put Block List, or Copy Blob overwrites the data in a blob. When blob soft delete is enabled, overwriting a blob automatically creates a soft-deleted snapshot of the blob's state before the write operation. When the retention period expires, the soft-deleted snapshot is permanently deleted. The operation that the system performs to create the snapshot doesn't appear in Azure Monitor resource logs or Storage Analytics logs.

Soft-deleted snapshots are invisible unless you explicitly display or list soft-deleted objects. For more information about how to list soft-deleted objects, see Manage and restore soft-deleted blobs.

To protect a copy operation, you must enable blob soft delete for the destination storage account.

Blob soft delete doesn't protect against operations to write blob metadata or properties. The deletion doesn't create a soft-deleted snapshot when a blob's metadata or properties are updated.

For premium storage accounts, soft-deleted snapshots don't count toward the per-blob limit of 100 snapshots.

Restoring soft-deleted objects

You can restore soft-deleted blobs or directories (in a hierarchical namespace) by calling the Undelete Blob operation within the retention period. The Undelete Blob operation restores a blob and any soft-deleted snapshots associated with it. It restores any snapshots that you deleted during the retention period. In accounts that have a hierarchical namespace, the access control list of a blob is restored along with the blob.

In accounts that have a hierarchical namespace, you can also use the Undelete Blob operation to restore a soft-deleted directory and all its contents. If you rename a directory that contains soft-deleted blobs, those soft-deleted blobs become disconnected from the directory. To restore those blobs, you need to revert the directory name to its original name or create a separate directory that uses the original directory name. Otherwise, you receive an error when you attempt to restore those soft-deleted blobs. You also can't restore a directory or a blob to a filepath that already has a directory or blob of that name. For example, if you delete a.txt (1) and upload a new file also named a.txt (2), you can't restore the soft-deleted a.txt (1) until the active a.txt (2) is either deleted or renamed. You can't access the contents of a soft-deleted directory until after the directory is undeleted.

Calling Undelete Blob on a blob that isn't soft-deleted restores any soft-deleted snapshots that are associated with the blob. If the blob has no snapshots and isn't soft-deleted, calling Undelete Blob has no effect.

To promote a soft-deleted snapshot to the base blob, first call Undelete Blob on the base blob to restore the blob and its snapshots. Next, copy the desired snapshot over the base blob. You can also copy the snapshot to a new blob.

You can't read data in a soft-deleted blob or snapshot until the object is restored.

For more information on how to restore soft-deleted objects, see Manage and restore soft-deleted blobs.

Tip

You can use a storage task to restore blobs at scale across multiple storage accounts based on a set of conditions that you define. A storage task is a resource available in Azure Storage Actions; a serverless framework that you can use to perform common data operations on millions of objects across multiple storage accounts. To learn more, see What is Azure Storage Actions?

Blob soft delete and versioning

Important

Versioning isn't supported for accounts that have a hierarchical namespace.

If you enable both blob versioning and blob soft delete for a storage account, then overwriting a blob automatically creates a new previous version that reflects the blob's state before the write operation. The new version isn't soft-deleted and isn't removed when the soft-delete retention period expires. No soft-deleted snapshots are created.

If you enable both blob versioning and blob soft delete for a storage account, then when you delete a blob, the current version of the blob becomes a previous version, and there's no longer a current version. No new version is created and no soft-deleted snapshots are created. All previous versions are retained until you explicitly delete them, either with a direct delete operation or via a lifecycle management policy.

Enabling soft delete and versioning together protects previous blob versions as well as current versions from deletion. When you enable soft delete, versions remain undeleted even if the blob is deleted. If you delete a version, then that version becomes soft-deleted. Soft-deleted versions are retained until the soft-delete retention period elapses. After the retention period elapses, the soft-deleted blob version is permanently deleted.

You can use the Undelete Blob operation to restore soft-deleted versions during the soft-delete retention period. The Undelete Blob operation always restores all soft-deleted versions of the blob. It isn't possible to restore only a single soft-deleted version.

Note

Calling the Undelete Blob operation on a deleted blob when versioning is enabled restores any soft-deleted versions or snapshots, but doesn't restore the current version. To restore the current version, promote a previous version by copying it to the current version.

Microsoft recommends enabling both versioning and blob soft delete for your storage accounts for optimal data protection. For more information about using blob versioning and soft delete together, see Blob versioning and soft delete.

Blob soft delete protection by operation

The following table describes the expected behavior for delete and write operations when blob soft delete is enabled, either with or without blob versioning. In the following tables, No change means the operation behaves the same whether or not blob soft delete is enabled.

Storage account (no hierarchical namespace)

REST API operations Soft delete enabled Soft delete and versioning enabled
Delete Storage Account No change. You can't recover containers and blobs in the deleted account. No change. You can't recover containers and blobs in the deleted account.
Delete Container No change. You can't recover blobs in the deleted container. No change. You can't recover blobs in the deleted container.
Delete Blob If used to delete a blob, that blob is marked as soft deleted.

If used to delete a blob snapshot, the snapshot is marked as soft deleted.		 If used to delete a blob, the current version becomes a previous version, and the current version is deleted. No new version is created and no soft-deleted snapshots are created.

If used to delete a blob version, the version is marked as soft deleted.
Undelete Blob Restores a blob and any snapshots that were deleted within the retention period. Restores a blob and any versions that were deleted within the retention period.
Put Blob
Put Block List
Copy Blob
Copy Blob from URL		 If called on an active blob, then a snapshot of the blob's state prior to the operation is automatically generated.

If called on a soft-deleted blob, then a snapshot of the blob's prior state is generated only if it's being replaced by a blob of the same type. If the blob is of a different type, then all existing soft-deleted data is permanently deleted.		 A new version that captures the blob's state prior to the operation is automatically generated.
Put Block If used to commit a block to an active blob, there's no change.

If used to commit a block to a blob that is soft-deleted, a new blob is created and a snapshot is automatically generated to capture the state of the soft-deleted blob.		 No change.
Put Page
Put Page from URL		 No change. Page blob data that is overwritten or cleared using this operation isn't saved and isn't recoverable. No change. Page blob data that is overwritten or cleared using this operation isn't saved and isn't recoverable.
Append Block
Append Block from URL		 No change. No change.
Set Blob Properties No change. Overwritten blob properties aren't recoverable. No change. Overwritten blob properties aren't recoverable.
Set Blob Metadata No change. Overwritten blob metadata isn't recoverable. A new version that captures the blob's state prior to the operation is automatically generated.
Set Blob Tier The base blob is moved to the new tier. Any active or soft-deleted snapshots remain in the original tier. No soft-deleted snapshot is created. The base blob is moved to the new tier. Any active or soft-deleted versions remain in the original tier. No new version is created.

Storage account (hierarchical namespace)

REST API operation Soft delete enabled
Delete Storage Account No change. Containers and blobs in the deleted account aren't recoverable.
Filesystem - Delete No change. Blobs in the deleted container aren't recoverable.
Delete Container No change. You can't recover blobs in the deleted container.
Path - Delete A soft-deleted blob or directory is created. The soft-deleted object is deleted after the retention period.
Delete Blob A soft-deleted object is created. The soft-deleted object is deleted after the retention period. Soft delete isn't supported for blobs that have snapshots.
Path - Create that renames a blob or directory Existing destination blob or empty directory gets soft deleted and the source replaces it. The soft-deleted object is deleted after the retention period.
Set Blob Expiry that sets an expiration date on an existing blob A soft-deleted blob isn't created. An expired blob doesn't become a soft-deleted blob when it expires.

Feature support

Support for this feature might be impacted by enabling Data Lake Storage Gen2, Network File System (NFS) 3.0 protocol, or the SSH File Transfer Protocol (SFTP). If you've enabled any of these capabilities, see Blob Storage feature support in Azure Storage accounts to assess support for this feature.

Soft delete isn't supported for blobs that are uploaded by using Data Lake Storage APIs on Storage accounts with no hierarchical namespace.

Pricing and billing

All soft-deleted data is billed at the same rate as active data. You aren't charged for data that's permanently deleted after the retention period elapses.

When you enable soft delete, use a short retention period to better understand how the feature affects your bill. The minimum recommended retention period is seven days.

Enabling soft delete for frequently overwritten data might result in increased storage capacity charges and increased latency when listing blobs. You can mitigate this extra cost and latency by storing the frequently overwritten data in a separate storage account where soft delete is disabled.

You aren't billed for transactions related to the automatic generation of snapshots or versions when a blob is overwritten or deleted. You're billed for calls to the Undelete Blob operation at the transaction rate for write operations.

For more information on pricing for Blob Storage, see the Blob Storage pricing page.

Blob soft delete and virtual machine disks

Blob soft delete is available for both premium and standard unmanaged disks, which are page blobs under the covers. Soft delete can help you recover data deleted or overwritten by the Delete Blob, Put Blob, Put Block List, and Copy Blob operations only.

Data that is overwritten by a call to Put Page isn't recoverable. An Azure virtual machine writes to an unmanaged disk by using calls to Put Page, so using soft delete to undo writes to an unmanaged disk from an Azure VM isn't a supported scenario.

Next steps

  • Last updated on