Restore a blob's current content separately from undeleting its versions

Source facts

With versioning enabled, deleting a blob without a version ID turns its current version into a previous version and leaves no current version. Existing previous versions remain. Deleting a specific previous version while soft delete is enabled instead retains that deleted version for the configured retention period.

Undelete Blob restores all retained soft-deleted versions, not a selected single version, and promotes none of them to current. Microsoft describes restoring those versions first and then copying the chosen previous version to a new current version. Microsoft Learn.

Applicability

Identify the account’s supported configuration, exact blob and relevant version IDs. Confirm that the required version is still recoverable before planning restoration.

DSE recommendation

DSE recommends recording which content the application should receive and who approves that choice. Keep restoration of historical versions separate from any operation that changes current content. Review existing application writes before promoting a version so the recovery decision accounts for concurrent activity. Do not interpret a successful undelete response as proof that the intended application data is now current.

Verification

In an approved recovery test, inspect the recovered version list, identify the selected source and read the current blob after the separate promotion. Compare its content with the approved recovery point. Record any version that could not be recovered and any current-content discrepancy before returning the application to normal use.

Official references

Microsoft Learn: Blob Versioning in Azure Storage. Source retrieved September 9, 2026.