highAdvancedSymptom-first#blob#soft-delete#versioning#restore#data-recovery

Blob soft-delete vs versioning — recovering the wrong data

Undelete blob returns a version that does not match the expected data

Likely source:data-lossconfiguration

Focused incident mode — strips away everything but this runbook.

Symptoms

  • Undelete blob returns a version that does not match the expected data
  • az storage blob list shows multiple versions of the same blob
  • Restored blob has different content than the version deleted minutes ago

When both soft-delete and versioning are enabled, az storage blob undelete returns the soft-deleted marker, not necessarily the version you want. Always list versions explicitly before restoring.

Evidence to grab

Collect these artifacts before you change anything — they prove (or rule out) each cause.

  • Blob versions listed

    az storage blob list --account-name <STORAGE-ACCOUNT> --container-name <CONTAINER> --include-v --prefix <BLOB-NAME> --query "[].{name:name,version:versionId}" -o table
  • Soft-delete and versioning status

    az storage account blob-service-properties show --account-name <STORAGE-ACCOUNT> --query "{softDelete:deleteRetentionPolicy.enabled,versioning:isVersioningEnabled}" -o json

Diagnostic flow

Run the steps in order, marking each claim confirmed or refuted. The evidence you gather feeds the ranked causes below.

Guided decision tree is ready.

Steps with commands, expected output, and pass/fail branches.

Ranked root causes

Evidence checklist

  • az storage blob undelete restores a different version than expected
  • Blob has multiple versions after a delete/undelete cycle

Confirm before fixing

az storage blob list --account-name <STORAGE-ACCOUNT> --container-name <CONTAINER> --include-v --prefix <BLOB-NAME> --query "[].{name:name,version:versionId}" -o table
READ

Show all versions

Fix

az storage blob copy start --account-name <STORAGE-ACCOUNT> --source-container <CONTAINER> --source-blob <BLOB-NAME> --source-version-id <DESIRED-VERSION> --destination-container <CONTAINER> --destination-blob <BLOB-NAME>-restored
CHANGE

Copy the correct version to a new blob

Expected: COPY IN PROGRESS

Resolution runbook

Apply from top to bottom after the cause is confirmed. Review every command before running it — risk tags are shown on each.

1
az storage account blob-service-properties show --account-name <STORAGE-ACCOUNT> --query "{softDelete:deleteRetentionPolicy.enabled,versioning:isVersioningEnabled}" -o json
READ

Check the current configuration

2
az storage blob list --account-name <STORAGE-ACCOUNT> --container-name <CONTAINER> --include d --prefix <BLOB-NAME> --query "[].{name:name,deleted:deletedTime,version:versionId}" -o table
READ

Find the soft-deleted blob

3
az storage blob list --account-name <STORAGE-ACCOUNT> --container-name <CONTAINER> --include-v --prefix <BLOB-NAME> --query "[].{name:name,version:versionId}" -o table
READ

Identify the correct version

4
az storage blob copy start --account-name <STORAGE-ACCOUNT> --source-container <CONTAINER> --source-blob <BLOB-NAME> --source-version-id <DESIRED-VERSION> --destination-container <CONTAINER> --destination-blob <BLOB-NAME>-restored
CHANGE

Restore the correct version explicitly

Prevention

  • Choose one recovery mechanism: soft-delete OR versioning, not both for the same container.
  • Set a short soft-delete retention (7 days) and monitor for accumulation.
  • Use az storage blob list --include-v to verify versions before any restore.
  • Test restore procedures regularly in a non-production container.

Commands marked READ CHANGE DESTRUCTIVE — never run DESTRUCTIVE commands against production data you cannot restore. Copy → verify → execute.