Soft delete for blobs
Blob soft delete protects an individual blob, snapshot, or version from accidental deletes or overwrites by maintaining the deleted data in the system for a specified period of time. During the retention period, you can restore a soft-deleted object to its state at the time it was deleted. After the retention period has expired, the object is permanently deleted.
Recommended data protection configuration
Blob soft delete is part of a comprehensive data protection strategy for blob data. For optimal protection for your blob data, We recommend enabling all of the following data protection features:
- Container soft delete, to restore a container that has been deleted. To learn how to enable container soft delete, see Enable and manage soft delete for containers.
- Blob versioning, to automatically maintain previous versions of a blob. When blob versioning is enabled, you can restore an earlier version of a blob to recover your data if it's erroneously modified or deleted. To learn how to enable blob versioning, see Enable and manage blob versioning.
- Blob soft delete, to restore a blob, snapshot, or version that has been deleted. To learn how to enable blob soft delete, see Enable and manage soft delete for blobs.
To learn more about Azure'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 results in the creation of a new version. For this reason, enabling blob versioning may result in additional 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:
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 is available for general-purpose v2, block blob, and Blob storage accounts. Storage accounts with a hierarchical namespace aren't currently supported.
Version 2017-07-29 and higher of the Azure Storage REST API support 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. Azure 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 blob soft delete is enabled, deleting a blob marks that blob as soft-deleted. No snapshot is created. 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 will remain intact if the blob is restored.
If a blob has snapshots, the blob can't be deleted unless the snapshots are also deleted. When you delete a blob and its snapshots, both the blob and snapshots are marked as soft-deleted. No new snapshots are created.
You can also delete one or more active snapshots without deleting the base blob. In this case, the snapshot is soft-deleted.
If a directory is deleted in an account that has the hierarchical namespace feature enabled on it, the directory and all its contents are marked as soft-deleted. Only the soft-deleted directory can be accessed. In order to access the contents of the soft-deleted directory, the soft-deleted directory needs to be undeleted first.
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 prior to the write operation. When the retention period expires, the soft-deleted snapshot is permanently deleted. The operation performed by the system to create the snapshot doesn't appear in Azure Monitor resource logs or Storage Analytics logs.
Soft-deleted snapshots are invisible unless soft-deleted objects are explicitly displayed or listed. For more information about how to list soft-deleted objects, see Manage and restore soft-deleted blobs.
To protect a copy operation, blob soft delete must be enabled for the destination storage account.
Blob soft delete doesn't protect against operations to write blob metadata or properties. No soft-deleted snapshot is created when a blob's metadata or properties are updated.
Blob soft delete doesn't afford overwrite protection for blobs in the archive tier. If a blob in the archive tier is overwritten with a new blob in any tier, then the overwritten blob is permanently deleted.
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. Any snapshots that were deleted during the retention period are restored. 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, the Undelete Blob operation can also be used 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. If you want to restore those blobs, you'll have to revert the name of the directory back to its original name or create a separate directory that uses the original directory name. Otherwise, you'll 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 has a directory or blob of that name already there. 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) has either been deleted or renamed. You can't access the contents of a soft-deleted directory until after the directory has been undeleted.
Calling Undelete Blob on a blob that isn't soft-deleted will restore any soft-deleted snapshots that are associated with the blob. If the blob has no snapshots and isn't soft-deleted, then 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.
Data in a soft-deleted blob or snapshot can't be read until the object has been restored.
For more information on how to restore soft-deleted objects, see Manage and restore soft-deleted blobs.
Blob soft delete and versioning
Important
Versioning is not supported for accounts that have a hierarchical namespace.
If blob versioning and blob soft delete are both enabled 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 blob versioning and blob soft delete are both enabled 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 they're explicitly deleted, 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 soft delete is enabled, explicitly deleting a previous version creates a soft-deleted version that is retained until the soft-delete retention period elapses. After the soft-delete retention period has elapsed, 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 does not restore the current version. To restore the current version, promote a previous version by copying it to the current version.
We recommend 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.
Storage account (no hierarchical namespace)
| REST API operations | Soft delete enabled | Soft delete and versioning enabled |
|---|---|---|
| Delete Storage Account | No change. Containers and blobs in the deleted account aren't recoverable. | No change. Containers and blobs in the deleted account aren't recoverable. |
| Delete Container | No change. Blobs in the deleted container aren't recoverable. | No change. Blobs in the deleted container aren't recoverable. |
| 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. Blobs in the deleted container aren't recoverable. |
| 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. Softdelete won't be supported for blobs with snapshots and snapshots. |
| Path - Create that renames a blob or directory | Existing destination blob or empty directory will get soft-deleted and the source will replace 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 won't be charged for data that is permanently deleted after the retention period elapses.
When you enable soft delete, We recommend using 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 may result in increased storage capacity charges and increased latency when listing blobs. You can mitigate this additional 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 is n't recoverable. An Azure virtual machine writes to an unmanaged disk 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.