10.4 Storage Data Protection: Soft Delete, Versioning, Point-in-Time Restore & Backup

Matching the Control to the Threat

Each protection feature answers a different failure mode. The exam tests whether you can pick the minimum set that satisfies a stated requirement.

Versioning stops overwrites. Soft delete stops deletes. Neither stops a determined administrator — that is what a locked time-based retention policy is for. Say the requirement out loud and the answer usually names itself.

---

Point-in-Time Restore and Its Prerequisites

Point-in-time restore (PITR) is the flagship recovery feature and the one with the most testable constraints.

You must enable all three prerequisites before PITR can be turned on:

1. Blob soft delete
2. Change feed (the ordered transaction log of every change)
3. Blob versioning

Account and data constraints:

• Supported for block blobs in standard-performance general-purpose v2 accounts only. Append blobs, page blobs, and premium block blobs are never restored, and accounts with a hierarchical namespace (Azure Data Lake Storage) are not supported at all.
• Only data in the hot and cool tiers can be restored. If a container in the requested range holds archive-tier blobs, the whole operation fails — partial restores do not exist.
• The restore period must be at least one day less than the blob soft delete retention period. A 7-day soft delete therefore permits a restore period of 1–6 days; setting the two equal is rejected.
• The window starts a few minutes after you enable PITR, so a 30-day policy switched on May 1 can still only reach 15 days back on May 15.

Operational constraints worth memorizing:

• One restore specifies up to 10 lexicographical container or blob-name ranges; omit the range to restore every container in the account.
• The operation is atomic — it either restores every change or fails — and only one restore may run on an account at a time. It cannot be cancelled, although a second restore can undo the first.
• Read, write, and delete operations against the affected ranges are blocked in the primary region for the duration.
• The caller needs write access to every container; Microsoft names the Storage Account Contributor role at account, resource group, or subscription scope.
• PITR does not restore containers. Deleting a container is not a block-blob operation, so it cannot be rolled back, and a range that includes a deleted container makes the restore fail outright. That is exactly why container soft delete is a separate mandatory control and not a duplicate of blob soft delete.

Change feed is independently useful: it is an append-only, immutable log of create, update, and delete events with the identity that made the change, stored in a system container. Security teams read it for forensic reconstruction of an incident.

---

Immutable Storage: Container-Level and Version-Level WORM

Immutable (write-once, read-many) storage is the only control that stops a subscription Owner from destroying data. It ships in two forms, and choosing between them is a routine exam decision.

Time-based retention intervals run from a minimum of 1 day to a maximum of 146,000 days (400 years). A new policy is created unlocked, which is a testing state: an unlocked policy can be shortened, extended, or deleted outright, and Microsoft recommends locking it within roughly 24 hours. Once locked, the policy can never be deleted and the retention interval can only be increased — at most five times over the lifetime of a container-level policy, while version-level policies have no such limit. Only a locked policy meets SEC 17a-4(f), CFTC 1.31(c)-(d), and FINRA 4511.

Legal holds have no expiry at all: data stays immutable until the hold is explicitly cleared, which is the right answer whenever the required retention period is unknown. A container-level legal hold must carry one or more user-defined alphanumeric tags — typically a case or matter ID — and every container with a policy keeps a policy audit log recording user ID, command type, timestamps, and retention interval.

The trap: immutability and point-in-time restore do not coexist. PITR is not supported when version-level immutability is enabled on a storage account or on a container in that account. With a container-level policy, a restore can be started, but blobs the policy protects are not modified, so the account never reaches a consistent state at the chosen timestamp. Pick one model per account, and give compliance-retention data its own storage account when a scenario appears to demand both.

---

Soft Delete for Azure Files

File shares have their own soft delete, configured on the file service rather than the blob service, and the differences are testable:

• It is a storage-account-level setting that applies to every classic share in the account, and it is enabled by default on new storage accounts.
• Retention defaults to 7 days and can be set anywhere from 1 to 365 days. The clock starts when the share is deleted, and shares deleted before a retention change expire on the value that was configured at deletion time.
• Undeleting restores the share and all of its contents, including its snapshots.
• It protects only at the share level. Recovering an individual file needs share snapshots or Azure Files backup — a distinction that separates a correct answer from a plausible one.
• Purging a soft-deleted share early is deliberately awkward: undelete the share, disable soft delete, delete it again, then re-enable soft delete for the account.

---

Azure Backup for Blobs and Files

Azure Backup adds a management layer with its own access boundary.

The security argument for vaulted backup is separation of blast radius: an attacker who compromises the storage account or its subscription still cannot delete the copies held in the vault, especially with the vault protections covered in the backup security section.

---

Putting It Together: A Ransomware-Resistant Blob Configuration

A defensible baseline for a business-critical container:

1. allowSharedKeyAccess = false and allowBlobPublicAccess = false — remove the credential-theft path first, because no recovery feature helps if the attacker has legitimate write access.
2. Blob versioning on.
3. Blob soft delete at 30 days, container soft delete at 30 days.
4. Change feed on, PITR at 29 days — on an account that does not use version-level immutability, since the two are mutually exclusive.
5. Vaulted backup with retention that outlives your incident-detection time.
6. Immutable storage with a locked time-based retention policy for compliance-relevant data, held in a separate storage account so it does not disable point-in-time restore for the rest of the estate.
7. Diagnostic logs to Log Analytics with an alert on mass-delete patterns and on any AuthenticationType = AccountKey request.
8. Resource lock (CanNotDelete) on the storage account so the account itself cannot be removed in a single API call.

Note the ordering: identity and access hardening first, recovery second. A ransomware operator with a valid account key can disable versioning and shorten retention before encrypting, which is why allowSharedKeyAccess = false and least-privilege data roles do more for resilience than any single recovery toggle.