Storage & Unstructured Data Protection
Blob backup · Azure Files backup · Storage account failover
Practice questions for this topic →
Blob backup tiers
| Operational backup | Vaulted backup | |
|---|---|---|
| Where | Local, inside the source account | Offsite copy in a Backup vault |
| How | Continuous: point-in-time restore, versioning, soft delete, change feed + a delete lock | Scheduled (uses object replication to the vault) |
| Retention | Up to 360 days | Up to 10 years |
| Restores to | The source account only (can overwrite data) | A different storage account only; container names must not clash |
| Protects against | Accidental delete or overwrite | Account deletion or compromise, ransomware, compliance |
Setting up blob backup (order in Microsoft's article)
- 1. Create a Backup vault. 2. Grant permissions to the Backup vault on the storage accounts. 3. Create a backup policy. 4. Configure backups. The Microsoft.DataProtection resource provider must be registered for your subscription first. A Backup vault is needed even for operational backup, which keeps data in the source account for up to 360 days; vaulted backup keeps an offsite copy for up to 10 years.
Operational backup limitations
- Supports block blobs in standard general-purpose v2 accounts only; page blobs, append blobs and premium blobs aren't restored. Private endpoints are supported; accounts in a network security perimeter aren't.
- Containers with legal hold aren't supported; a container deleted during retention isn't restored (enable container soft delete too); archive-tier blobs aren't restored; a blob with an active lease can't be restored; immutable blobs aren't restored to the chosen point.
- Protect the container, not just the blob: delete individual blobs if you may need to restore them.
Azure Files and storage failover
| Item | Detail |
|---|---|
| Azure Files snapshot tier | Local snapshots; accidental deletion only |
| Azure Files Vault-Standard | Offsite vaulted copy, long-term retention, cross-region restore |
| Planned storage failover | Swaps primary and secondary after pending writes sync, no data loss, original redundancy restored on failback; for drills and non-storage outages |
| Unplanned storage failover | Writes after the Last Sync Time may be lost; the account becomes LRS, so re-enable GRS or GZRS |
Exam Tips
Tick each tip once you can answer it without looking.
“Restore blobs to their state 2 days ago within the same account” → Operational backup (blob point-in-time restore).
“Blob backups must survive deletion of the storage account and be kept 7 years” → Vaulted blob backup.
“File share backups must be offsite and restorable in another region” → Azure Files Vault-Standard backup.
“Test storage DR without losing data” → Customer-managed planned failover.
“After an unplanned failover the account is no longer geo-redundant” → Expected: it becomes LRS; reconfigure GRS/GZRS.
“Estimate data loss before unplanned storage failover” → Check Last Sync Time.
“Limits of operational blob backup” → Block blobs in standard GPv2 accounts only; legal-hold containers, deleted containers and archive-tier blobs aren't restored. Trap: A blob with an active lease can't be restored.
“Where blob backups restore to” → Operational: the source account (can overwrite). Vaulted: a different storage account with no clashing container names. Trap: Operational keeps data up to 360 days, vaulted up to 10 years.
“Container deleted during the retention period” → Not restored by point-in-time restore; enable container soft delete as well. Trap: Delete individual blobs, not the container, if you may need to restore them.
“Set up Azure Backup for blobs in order” → Create a Backup vault, grant it permissions on the storage accounts, create a backup policy, configure backups. Trap: Register the Microsoft.DataProtection provider first; a vault is needed even for operational backup.