Context
Azure Blob soft delete keeps deleted data recoverable for a configured period. Blob versioning separately preserves earlier states of a blob. These features interact, but the buttons do not mean the same thing. Undeleting a versioned blob can restore its deleted versions without recreating the current object that the application expects to read.
Before recovery, confirm the account's namespace type, whether versioning was enabled at the incident time, and the remaining soft-delete window. Obtain data-owner agreement on the intended recovery point. You need permission to inspect object history and a controlled destination for checking recovered content.
1. Preserve the incident timeline
Record the account, container, exact blob name and approximate time of the unwanted operation in UTC. Pause the writer through the application's normal change process if it would immediately overwrite a repaired object. Preserve request identifiers and relevant storage logs. A recent modification time alone cannot establish which file contains the correct business data.
In the portal, include deleted blobs and deleted versions in the listing. Capture version identifiers, sizes and creation times. If the entire container was deleted, investigate container soft delete first; blob soft delete does not restore a deleted container by itself. Establish the affected scope before selecting any restore action.
2. Choose the correct recovery sequence
For a flat-namespace account with versioning enabled, identify the desired previous version. If that version is soft-deleted, undelete the object's deleted versions first. Then promote the chosen previous version to current, using the supported portal workflow or equivalent storage API. The promotion is the step that makes the selected content available at the base blob name.
Without versioning, an overwrite can have produced a soft-deleted snapshot. The relevant workflow is to undelete that snapshot and then promote it over the base blob. Do not assume the two cases have identical history views. Accounts with hierarchical namespace have different supported protections, so use the matching recovery instructions.
3. Validate content before reopening writes
Inspect the candidate through a separate validation path whenever practical. Compare its checksum with a trusted manifest, open the file with its real parser, and check business identifiers inside it. A matching filename and size are weak evidence for a document that changes in place.
After promotion, read the ordinary application URL using the application's normal access path. Check metadata, content type and any application-level cache that could retain the unwanted copy. Preserve the current incident evidence before another write creates further versions. Reenable the writer only after its input or deployment error has been corrected.
Diagnostic checkpoints
| Observation | What it suggests | Next check |
|---|---|---|
| Versions exist but base URL is absent | No current version | Promotion status |
| Candidate is listed as deleted | Recovery action needed first | Soft-delete deadline |
| File opens but records are wrong | Wrong recovery point | Business timestamps |
| Correct storage content, stale application | Cached response | Application cache identity |
Illustrative scenario
In a hypothetical catalog workflow, an import job replaces a valid product file with an empty export. An operator undeletes the object's history and still sees the empty current file. The missing action is to select the valid previous version and make it current. A parser check and a read through the catalog service then establish whether the repair restored the expected products. This scenario is illustrative, with no claimed production outcome.
Recovery SOP and follow-up
Close the incident only when a known-good reader consumes the current object and the corrected writer can complete its next expected cycle. Record the selected version identifier, checksum, recovery decision and validation result. Keep any temporary recovery copy under the same access controls as the original data.
Schedule recovery rehearsals using disposable objects that exercise both deletion and overwrite. Monitor changes to retention configuration, permanent-delete capability and lifecycle rules. Add a warning threshold for the time remaining to recover incident data; waiting for an ordinary change window can otherwise exhaust the protection you intended to use.
Explore Clouvenix backup disaster recovery for implementation and operational handover.