A blob was accidentally overwritten with bad data, not deleted. Both soft delete and versioning are enabled on the account. Why doesn't 'undelete' bring back the good version, and what actually will?

Soft delete and versioning protect against two different mistakes: soft delete recovers a blob that was deleted, while versioning preserves every prior version of a blob's content each time it's overwritten. An overwrite isn't a delete, so there's nothing for soft delete to undelete — the fix is retrieving the previous version of the blob (which versioning automatically preserved as a distinct, addressable version at the moment it was overwritten) and either promoting it or copying its content back.

The confusion comes from treating "soft delete and versioning" as one generic safety net, when they're actually two independent mechanisms that respond to two different kinds of mistakes — and only one of them applies to an overwrite.

• The blob is present and accessible, just with incorrect content — there's no "deleted" state to recover from.
• Attempting to list or restore soft-deleted blobs in the container shows nothing relevant to this blob, since it was never deleted.
• The team's initial recovery attempt (looking for an undelete option) finds nothing applicable, causing confusion about whether the good data is recoverable at all.

• The mental model conflates soft delete and versioning as one feature, when soft delete specifically responds to deletion (the blob or a version of it being removed) and versioning specifically responds to overwrites (each write creating a new, retained version) — an overwrite triggers versioning's protection, not soft delete's.
• Versioning is enabled but nobody previously verified it was actually capturing versions correctly — worth confirming, though if versioning has been on since before the overwrite, the previous version should exist regardless.

List the blob's version history directly, via the Portal's version list for that blob or az storage blob list with the --include versions flag — this shows every previous version, each independently addressable, including the one that existed immediately before the bad overwrite.

Identify the correct version by its last-modified timestamp, comparing against when the bad overwrite is known to have happened — the version immediately prior to that timestamp is the one to recover.

Restore the correct prior version by promoting it to be the current version (or by copying its content over the current blob, depending on the tooling used) — this is a version-restore operation, not an undelete operation, and it directly recovers the pre-overwrite content without needing soft delete to be involved at all.

Make sure the team's operational runbooks distinguish these two mechanisms explicitly — "accidentally deleted" points to soft delete recovery, "accidentally overwritten" points to version recovery — rather than treating "we have soft delete and versioning on, we're covered" as one undifferentiated safety net that gets reached for the wrong way during an actual incident.

• Soft delete recovers from deletion; versioning recovers from overwrite — they respond to different mistakes and aren't interchangeable safety nets.
• An overwrite doesn't create anything for soft delete to act on, because the blob was never deleted — this is the source of the "nothing to undelete" confusion.
• Versioning automatically retains the prior version at the moment of an overwrite, addressable independently of the current version, which is exactly what makes recovery from an overwrite possible.
• Recovery runbooks should explicitly distinguish "deleted" versus "overwritten" scenarios, since reaching for the wrong recovery mechanism costs time during an actual incident.

• Azure Blob Storage: Blob versioning
• Azure Blob Storage: Soft delete for blobs