Implement Soft Delete for Blobs and Containers
Soft delete is a safety feature in Azure Storage that prevents accidental data loss. When enabled, it keeps deleted blobs and containers in a recoverable state for a period you choose. You turn this on for each storage account, and it applies to both the containers that hold data and the individual blobs (files) inside them.
Soft Delete for Containers
When container soft delete is active and you delete a container, the container and everything inside it is hidden but not erased. You can restore the entire container to its exact state at the moment it was deleted. The retention period—how long the container stays recoverable—can be set from 1 to 365 days. It is important to know that you cannot restore just one file from a deleted container this way; you need blob soft delete for that.
Soft Delete for Blobs
Blob soft delete protects individual files, their snapshots, and their versions. If you delete or accidentally overwrite a blob, the old data is saved as a soft-deleted item. You can then use the Undelete Blob operation to bring it back. Like container soft delete, you set a retention period between 1 and 365 days. Be aware that enabling blob versioning alongside this can increase storage costs, as it saves a new version every time a file is changed.
Recommended Data Protection Configuration
For the strongest protection against data loss, Microsoft suggests using multiple features together. Enable container soft delete to restore whole containers. Enable blob versioning to automatically keep a history of file changes. Also enable blob soft delete to recover individual deleted files, snapshots, or versions. This layered approach covers different types of accidental deletion.
Enabling Soft Delete
You can turn on soft delete through several management tools. In the Azure portal, you go to your storage account's Data Protection settings. Using PowerShell, you run commands like Enable-AzStorageBlobDeleteRetentionPolicy. With the Azure CLI, you use the az storage account blob-service-properties update command. The setting applies to the entire storage account.
Viewing and Restoring Soft-Deleted Data
In the Azure portal, you can see items that are in the soft-deleted state by toggling a switch labeled Show deleted containers or Show deleted blobs. To restore one, you select it and choose the Undelete option. The system will recover the item, making it active again.
Evaluate Soft Delete Configuration Parameters and Their Impact
Balancing Recovery Time and Cost
The key setting for soft delete is the retention period, which you choose between 1 and 365 days. A longer period gives you more time to discover and fix an accidental deletion, but it also increases storage costs because you are billed for the soft-deleted data just like active data. Once the retention period expires, the data is permanently erased and cannot be recovered.
Interaction with Other Protection Features
Soft delete works alongside other Azure data protection tools. Container soft delete restores an entire container, while blob soft delete is needed to restore a single file. Importantly, soft delete does not protect against someone deleting the entire storage account itself; for that, you need to apply an Azure Resource Manager lock. When blob versioning is also enabled, overwriting a file creates a new version instead of a soft-deleted snapshot, which changes the recovery process and storage patterns.
Enabling soft delete features does not have an upfront fee, but your storage bill will grow because you are keeping extra data. If you have more than 1,000 soft-deleted items, listing your blobs can become slower. To manage costs, you can use lifecycle management policies to automatically clean up old, soft-deleted data after a certain time.
Management and Security
You manage soft delete policies through the Azure portal, PowerShell, or Azure CLI. For high-security environments, you can enable Always-on soft delete, which makes the setting permanent and prevents anyone, including a malicious actor, from turning it off. After changing a policy, administrators should wait about 30 seconds for it to take full effect before testing deletions.
Analyze the Operational Mechanics and Recovery Procedures of Soft Delete
Container Soft Delete State and Recovery
When container soft delete is enabled and a container is deleted, it enters a soft-deleted state. It becomes hidden from normal view but is preserved with all its blobs, versions, and snapshots intact for the retention period. Restoring the container brings back everything as it was. A recovery will fail if a new, active container is already using the original name, so you must resolve such name conflicts first.
Blob Soft Delete Behavior
Blob soft delete works on individual files. A deleted blob is marked as soft-deleted and hidden. If a blob is overwritten while soft delete is on (but versioning is off), Azure automatically creates a soft-deleted snapshot of the previous content. The soft-deleted data remains billable. In accounts with a hierarchical namespace (used by Azure Data Lake Storage Gen2), you can soft-delete entire directories, and restoring a directory brings back all files inside it.
To restore soft-deleted data, you use specific operations in your management tool of choice. In the Azure portal, you toggle the "Show deleted" setting and use the Undelete button. With PowerShell, you use cmdlets like Restore-AzStorageContainer or Undelete-AzStorageBlob. In the Azure CLI, you run the az storage blob undelete command. The process is deliberate and requires you to specifically target the soft-deleted item.
Soft Delete for Azure Files
Azure Files also supports soft delete, but it works at the file share level, not for individual files. When a share is deleted, it and all its share snapshots and directory structures enter a soft-deleted state. To permanently delete a share before the retention period ends, an administrator must first undelete it, then disable soft delete for the account, and finally delete it again. This extra step prevents irreversible loss from a single accidental command.