Blob Versioning
What it is
Blob versioning automatically retains a previous version of a blob every time it is overwritten or deleted, so you can restore an older state on demand. Each write produces a new version of that blob (identified by a version ID) in addition to the current one.
Why it exists
To give point-in-time recovery against accidental overwrites, application bugs, or rogue edits — instead of losing the old data the moment a blob is rewritten, you keep working copies of every earlier version.
Key ideas
- Enabled at the storage-account level (all containers/blobs in the account); it cannot be enabled per-container.
- A delete creates a special delete-marker version; the blob remains restorable by promoting the last good version.
- Restore = promote/overwrite the current blob with an older version.
- Cost concern: every version still occupies storage — leaving versioning on for a long time grows cost, so pair it with lifecycle management / version-level retention to auto-delete old versions.
- Fully separate from (and can be combined with) soft delete / immutability.
How object replication ties in
Object replication requires blob versioning on both source and destination accounts, which is why the two features are commonly configured together. See object-replication.
How it fits (diagram)
Exam notes
- Versioning vs soft delete: versioning recovers overwrites and point-in-time states; soft delete recovers deleted blobs/snapshots for a retention period. Versioning keeps every version forever unless you limit it — that’s the cost trap.
- Enabled account-wide (never per-container), and often paired with soft delete for full protection.
- Promoting an old version = restoring; deleting a blob with versioning on leaves a recoverable delete marker.
Related
blob-storage · immutable-storage · object-replication · storage-performance
📘 Source: Microsoft Learn — Blob Versioning