Blob Data Protection
Soft delete · Versioning · Point-in-time restore · Immutability · Object replication
Practice questions for this topic →
Features
| Feature | Protects against | Key facts |
|---|---|---|
| Resource lock (CanNotDelete) | Deleting or reconfiguring the storage account | Protects the account only, not containers or blobs |
| Container soft delete | Accidental container deletion | Microsoft suggests at least 7 days; restores only container-level deletes |
| Blob soft delete | Accidental delete or overwrite of a blob, snapshot or version | Retention 1–365 days; restore with Undelete Blob; doesn't protect containers or the account; enable at scale with a built-in Azure Policy |
| Versioning | Overwrites and deletes | A new version on every write or delete, automatically; previous versions are immutable; keep under 1,000 versions per blob; use lifecycle rules to delete old ones; snapshots are manual, so stop taking them once versioning is on |
| Point-in-time restore | Corruption or accidental deletion of block blobs | Needs soft delete + versioning + change feed; standard GPv2, hot and cool tiers only, no hierarchical namespace; atomic; one restore at a time, can't be cancelled; up to 10 ranges; doesn't protect container or account deletion |
| Object replication | Latency and data distribution (not a backup) | Async copy of block blobs; change feed on the source, versioning on both; GPv2 or premium block blob; no hierarchical namespace; customer-managed failover unsupported |
| Azure Backup for blobs | Account deletion, ransomware, long retention | Operational and vaulted tiers (see Business Continuity) |
Immutable storage (WORM)
| Policy | Behavior |
|---|---|
| Time-based retention (unlocked) | Can be changed or removed; for testing |
| Time-based retention (locked) | Can extend but never shorten or delete: meets SEC 17a-4(f), FINRA, CFTC |
| Legal hold | Until explicitly cleared; no expiry; can coexist with time-based retention |
| Scope | Container-level or version-level WORM |
| Limits | Not supported with NFS 3.0 or SFTP; a policy can take up to about 35 seconds to take effect; after retention expires blobs can be deleted but not overwritten |
Exam Tips
Tick each tip once you can answer it without looking.
“Recover a blob deleted by mistake last week” → Blob soft delete.
“Recover previous content after an overwrite” → Blob versioning.
“Restore a container's blobs to their state 3 days ago” → Point-in-time restore.
“SEC 17a-4: data can't be modified or deleted, even by admins” → Immutable storage, locked time-based retention.
“Preserve data for litigation with no end date” → Legal hold.
“Prevent the storage account itself being deleted” → CanNotDelete resource lock.
“Copy blobs asynchronously to an account in another region for low-latency reads” → Object replication.
“Ransomware protection for blobs” → Versioning + soft delete + immutability (+ vaulted backup).
“Basic blob data protection baseline” → Resource lock on the account, container soft delete, blob soft delete. Trap: Add Azure Backup for account deletion or ransomware.
“Blob soft delete retention” → 1 to 365 days; restore with Undelete Blob. Trap: It doesn't protect containers or the account.
“How versioning works” → A new version on every write or delete, automatically; previous versions are immutable. Trap: Keep under 1,000 versions per blob; stop taking snapshots once versioning is on.
“Point-in-time restore prerequisites” → Soft delete, versioning and change feed; standard GPv2; hot and cool tiers only. Trap: Not on hierarchical namespace accounts; atomic; one restore at a time.
“Object replication prerequisites” → Change feed on the source, versioning on both; GPv2 or premium block blob; block blobs only. Trap: Asynchronous; not on hierarchical namespace accounts.