Data protection overview
Azure Storage provides data protection for Blob Storage and Azure Data Lake Storage to help you to prepare for scenarios where you need to recover data that has been deleted or overwritten. It's important to think about how to best protect your data before an incident occurs that could compromise it. This guide can help you decide in advance which data protection features your scenario requires, and how to implement them. If you should need to recover data that has been deleted or overwritten, this overview also provides guidance on how to proceed, based on your scenario.
In the Azure Storage documentation, data protection refers to strategies for protecting the storage account and data within it from being deleted or modified, or for restoring data after it has been deleted or modified. Azure Storage also offers options for disaster recovery, including multiple levels of redundancy to protect your data from service outages due to hardware problems or natural disasters. Customer-managed (unplanned) failover is another disaster recovery option that allows you to fail over to a secondary region if the primary region becomes unavailable. For more information about how your data is protected from service outages, see Disaster recovery.
Recommendations for basic data protection
If you're looking for basic data protection coverage for your storage account and the data that it contains, then Azure recommends taking the following steps to begin with:
- Configure an Azure Resource Manager lock on the storage account to protect the account from deletion or configuration changes. Learn more...
- Enable container soft delete for the storage account to recover a deleted container and its contents. Learn more...
- Save the state of a blob at regular intervals:
- For Blob Storage workloads, enable blob versioning to automatically save the state of your data each time a blob is overwritten. Learn more...
- For Azure Data Lake Storage workloads, take manual snapshots to save the state of your data at a particular point in time. Learn more...
These options, as well as other data protection options for other scenarios, are described in more detail in the following section.
For an overview of the costs involved with these features, see Summary of cost considerations.
Overview of data protection options
The following table summarizes the options available in Azure Storage for common data protection scenarios. Choose the scenarios that are applicable to your situation to learn more about the options available to you. Not all features are available at this time for storage accounts with a hierarchical namespace enabled.
| Scenario | Data protection option | Recommendations | Protection benefit | Available for Data Lake Storage |
|---|---|---|---|---|
| Prevent a storage account from being deleted or modified. | Azure Resource Manager lock Learn more... |
Lock all of your storage accounts with an Azure Resource Manager lock to prevent deletion of the storage account. | Protects the storage account against deletion or configuration changes. Doesn't protect containers or blobs in the account from being deleted or overwritten. |
Yes |
| Prevent a blob version from being deleted for an interval that you control. | Immutability policy on a blob version Learn more... |
Set an immutability policy on an individual blob version to protect business-critical documents, for example, in order to meet legal or regulatory compliance requirements. | Protects a blob version from being deleted and its metadata from being overwritten. An overwrite operation creates a new version. If at least one container has version-level immutability enabled, the storage account is also protected from deletion. Container deletion fails if at least one blob exists in the container. |
No |
| Prevent a container and its blobs from being deleted or modified for an interval that you control. | Immutability policy on a container Learn more... |
Set an immutability policy on a container to protect business-critical documents, for example, in order to meet legal or regulatory compliance requirements. | Protects a container and its blobs from all deletes and overwrites. When a legal hold or a locked time-based retention policy is in effect, the storage account is also protected from deletion. Containers for which no immutability policy has been set aren't protected from deletion. |
Yes |
| Restore a deleted container within a specified interval. | Container soft delete Learn more... |
Enable container soft delete for all storage accounts, with a minimum retention interval of seven days. Enable blob versioning and blob soft delete together with container soft delete to protect individual blobs in a container. Store containers that require different retention periods in separate storage accounts. |
A deleted container and its contents may be restored within the retention period. Only container-level operations (for example, Delete Container) can be restored. Container soft delete doesn't enable you to restore an individual blob in the container if that blob is deleted. |
Yes |
| Automatically save the state of a blob in a previous version when it's overwritten. | Blob versioning Learn more... |
Enable blob versioning, together with container soft delete and blob soft delete, for storage accounts where you need optimal protection for blob data. Store blob data that doesn't require versioning in a separate account to limit costs. |
Every blob write operation creates a new version. The current version of a blob may be restored from a previous version if the current version is deleted or overwritten. | No |
| Restore a deleted blob or blob version within a specified interval. | Blob soft delete Learn more... |
Enable blob soft delete for all storage accounts, with a minimum retention interval of seven days. Enable blob versioning and container soft delete together with blob soft delete for optimal protection of blob data. Store blobs that require different retention periods in separate storage accounts. |
A deleted blob or blob version may be restored within the retention period. | Yes |
| Restore a set of block blobs to a previous point in time. | Point-in-time restore Learn more... |
To use point-in-time restore to revert to an earlier state, design your application to delete individual block blobs rather than deleting containers. | A set of block blobs may be reverted to their state at a specific point in the past. Only operations performed on block blobs are reverted. Any operations performed on containers, page blobs, or append blobs aren't reverted. |
No |
| Manually save the state of a blob at a given point in time. | Blob snapshot Learn more... |
Recommended as an alternative to blob versioning when versioning isn't appropriate for your scenario, due to cost or other considerations, or when the storage account has a hierarchical namespace enabled. | A blob may be restored from a snapshot if the blob is overwritten. If the blob is deleted, snapshots are also deleted. | Yes, in preview |
| A blob can be deleted or overwritten, but the data is regularly copied to a second storage account. | Azure Blob vaulted backup Learn more |
Enable vaulted backup to have an offsite copy of your data backed up to a Microsoft tenant with no-direct access | Provides selective backup of essential containers and enables the restore of individual containers to a storage account which is different from the source storage account | No Roll-your-own solution for copying data to a second account AzCopy and Azure Data Factory are supported. Object replication isn't supported. |
Data protection by resource type
The following table summarizes the Azure Storage data protection options according to the resources they protect.
| Data protection option | Protects an account from deletion | Protects a container from deletion | Protects an object from deletion | Protects an object from overwrites |
|---|---|---|---|---|
| Azure Blob vaulted backup |
No | Yes | Yes | Yes |
| Azure Resource Manager lock | Yes | No1 | No | No |
| Immutability policy on a blob version | Yes2 | Yes3 | Yes | Yes4 |
| Immutability policy on a container | Yes5 | Yes | Yes | Yes |
| Container soft delete | No | Yes | No | No |
| Blob versioning6 | No | No | Yes | Yes |
| Blob soft delete | No | No | Yes | Yes |
| Point-in-time restore6 | No | No | Yes | Yes |
| Blob snapshot | No | No | No | Yes |
| Roll-your-own solution for copying data to a second account7 | No | Yes | Yes | Yes |
1 An Azure Resource Manager lock doesn't protect a container from deletion.
2 Storage account deletion fails if there is at least one container with version-level immutable storage enabled.
3 Container deletion fails if at least one blob exists in the container, regardless of whether policy is locked or unlocked.
4 Overwriting the contents of the current version of the blob creates a new version. An immutability policy protects a version's metadata from being overwritten.
5 While a legal hold or a locked time-based retention policy is in effect at container scope, the storage account is also protected from deletion.
6 Not currently supported for Data Lake Storage workloads.
7 AzCopy and Azure Data Factory are options that are supported for both Blob Storage and Data Lake Storage workloads. Object replication is supported for Blob Storage workloads only.
Recover deleted or overwritten data
If you should need to recover data that has been overwritten or deleted, how you proceed depends on which data protection options you've enabled and which resource was affected. The following table describes the actions that you can take to recover data.
| Deleted or overwritten resource | Possible recovery actions | Requirements for recovery |
|---|---|---|
| Storage account | Attempt to recover the deleted storage account Learn more... |
The storage account was originally created with the Azure Resource Manager deployment model and was deleted within the past 14 days. A new storage account with the same name hasn't been created since the original account was deleted. |
| Container | Recover the soft-deleted container and its contents Learn more... |
Container soft delete is enabled and the container soft delete retention period hasn't yet expired. |
| Containers and blobs | Restore data from a second storage account | All container and blob operations have been effectively replicated to a second storage account. |
| Blob (any type) | Restore a blob from a previous version1 Learn more... |
Blob versioning is enabled and the blob has one or more previous versions. |
| Blob (any type) | Recover a soft-deleted blob Learn more... |
Blob soft delete is enabled and the soft delete retention interval hasn't expired. |
| Blob (any type) | Restore a blob from a snapshot Learn more... |
The blob has one or more snapshots. |
| Set of block blobs | Recover a set of block blobs to their state at an earlier point in time1 Learn more... |
Point-in-time restore is enabled and the restore point is within the retention interval. The storage account hasn't been compromised or corrupted. |
| Blob version | Recover a soft-deleted version1 Learn more... |
Blob soft delete is enabled and the soft delete retention interval hasn't expired. |
1 Not currently supported for Data Lake Storage workloads.
Summary of cost considerations
The following table summarizes the cost considerations for the various data protection options described in this guide.
| Data protection option | Cost considerations |
|---|---|
| Azure Resource Manager lock for a storage account | No charge to configure a lock on a storage account. |
| Immutability policy on a blob version | No charge to enable version-level immutability on a container. Creating, modifying, or deleting a time-based retention policy or legal hold on a blob version results in a write transaction charge. |
| Immutability policy on a container | No charge to configure an immutability policy on a container. |
| Container soft delete | No charge to enable container soft delete for a storage account. Data in a soft-deleted container is billed at same rate as active data until the soft-deleted container is permanently deleted. |
| Blob versioning | No charge to enable blob versioning for a storage account. After blob versioning is enabled, every write or delete operation on a blob in the account creates a new version, which may lead to increased capacity costs. A blob version is billed based on unique blocks or pages. Costs therefore increase as the base blob diverges from a particular version. Changing a blob or blob version's tier may have a billing impact. For more information, see Pricing and billing. Use lifecycle management to delete older versions as needed to control costs. For more information, see Optimize costs by automating Azure Blob Storage access tiers. |
| Blob soft delete | No charge to enable blob soft delete for a storage account. Data in a soft-deleted blob is billed at same rate as active data until the soft-deleted blob is permanently deleted. |
| Point-in-time restore | No charge to enable point-in-time restore for a storage account; however, enabling point-in-time restore also enables blob versioning, soft delete, and change feed, each of which may result in other charges. You're billed for point-in-time restore when you perform a restore operation. The cost of a restore operation depends on the amount of data being restored. For more information, see Pricing and billing. |
| Blob snapshots | Data in a snapshot is billed based on unique blocks or pages. Costs therefore increase as the base blob diverges from the snapshot. Changing a blob or snapshot's tier may have a billing impact. For more information, see Pricing and billing. Use lifecycle management to delete older snapshots as needed to control costs. For more information, see Optimize costs by automating Azure Blob Storage access tiers. |
| Vaulted backup | For Vaulted Backup, You will incur backup storage charges or instance fees, and the source side cost (associated with Object replication) on the backed-up source account. See Pricing. |
| Copy data to a second storage account | Maintaining data in a second storage account will incur capacity and transaction costs. If the second storage account is located in a different region than the source account, then copying data to that second account will additionally incur egress charges. |
Disaster recovery
Azure Storage always maintains multiple copies of your data so that it's protected from planned and unplanned events, including transient hardware failures, network or power outages, and massive natural disasters. Redundancy ensures that your storage account meets its availability and durability targets even in the face of failures. For more information about how to configure your storage account for high availability, see Azure Storage redundancy.
If your storage account is configured for geo-redundancy, you have the option to initiate an unplanned failover from the primary to the secondary region during a data center failure. For more information, see Disaster recovery planning and failover.
Customer-managed failover isn't currently supported for storage accounts with a hierarchical namespace enabled. For more information, see Blob storage features available in Azure Data Lake Storage Gen2.