8.5 Unstructured Data Backup & Recovery Design

Why This Topic Matters

This section closes out the official skill "Recommend a backup and recovery solution for unstructured data" -- the Blob Storage and Azure Files half of the compute/database/unstructured-data trio that makes up "backup and disaster recovery" in Domain 3. Unstructured data protection looks deceptively simple (it's "just files"), but AZ-305 tests a specific, layered set of features -- soft delete, versioning, point-in-time restore, and vaulted backup -- and expects you to know which combination actually satisfies a stated requirement, especially around ransomware resilience.

The Three Native Blob Protection Features

These live directly on the storage account and are the first line of defense, often before any backup product is even involved:

• Soft delete -- when a blob, snapshot, container, or (with container soft delete) an entire container is deleted, it is retained in a recoverable state instead of being purged immediately. Retention is configurable from 1 to 365 days, and is off by default -- a scenario requiring "protect against accidental deletion" is incomplete until soft delete is explicitly enabled.
• Blob versioning -- automatically keeps a previous version every time a blob is overwritten or deleted, letting you retrieve any prior version, not just recover from deletion.
• Change feed -- an ordered, durable log of every create/update/delete transaction on the storage account, which is the mechanism that makes point-in-time restore possible.

Point-in-Time Restore for Block Blobs

Point-in-time restore (PITR) for block blobs lets you restore a container (or a subset of blobs matching a prefix) to a specific timestamp in the past, undoing accidental overwrites or bulk deletions in one operation instead of restoring blob-by-blob. PITR requires versioning, change feed, and blob soft delete to all be enabled on the storage account -- Microsoft's "operational backup" feature for Blobs is really a managed wrapper that turns on exactly these three capabilities together and adds a delete lock on the storage account to reduce the risk of the whole account being deleted. Operational backup retains restorable data within the source storage account itself for up to 360 days -- it does not copy data to a separate vault.

Vaulted Backup: The Independent Copy

Vaulted backup for Blobs is the complementary, periodic backup that copies blob data into a Backup vault, independent of the source storage account. Because the copy lives outside the source account, vaulted backup survives even if the entire source storage account is deleted or compromised -- something operational backup (which lives inside the source account) cannot protect against. Vaulted backups restore to a different storage account, not back to the original in place. A scenario that requires resilience against the entire storage account being deleted or ransomed is describing vaulted backup, not operational backup or soft delete alone.

Immutable Storage (WORM) as a Ransomware Control

Immutable blob storage enforces write once, read many (WORM) policies -- either time-based retention (data cannot be modified or deleted until a set retention period expires, even by an account owner) or legal hold (indefinite, until explicitly removed). Immutability is the strongest available control against ransomware and insider deletion because, unlike soft delete, it cannot be bypassed by someone with full storage account permissions during the retention window.

Azure Files Backup

Azure Files is protected through the Recovery Services vault using share-level snapshots:

• Snapshot tier -- local, storage-account-resident snapshots; protects against accidental deletion only, similar in spirit to blob soft delete.
• Vault tier (Vault-Standard) -- copies snapshot data into the Recovery Services vault for comprehensive protection, including protection if the storage account itself is compromised, with retention configurable up to 10 years across daily/weekly/monthly/yearly tiers -- mirroring the same retention hierarchy used for VM backups.

Requirement-to-Feature Mapping

Common Decision Traps

• Recommending soft delete alone as protection against ransomware -- an attacker with sufficient permissions and enough time can still permanently purge soft-deleted data before the retention window's protections meaningfully help; immutability is the control that cannot be overridden.
• Forgetting that point-in-time restore for block blobs is not free-standing -- it requires versioning, change feed, and soft delete to already be enabled, and candidates sometimes list PITR as if it were an independent toggle.
• Assuming operational backup protects against full storage-account deletion -- it protects data within the account (with a delete lock as a deterrent) but does not maintain an independent copy; only vaulted backup provides that independent copy.
• Using Azure Files' Snapshot tier alone when the requirement calls for multi-year retention or protection against the storage account being compromised -- that combination requires the Vault tier.

Exam Scenario

A media company stores critical unstructured assets in Blob Storage and needs: (1) the ability to undo a bad batch-delete job affecting thousands of blobs from 2 days ago, and (2) guaranteed survivability even if the entire storage account is deleted by a compromised credential. The design: enable blob versioning, change feed, and soft delete to support point-in-time restore for requirement 1, and configure vaulted backup to a separate Backup vault for requirement 2, since only a copy stored outside the source account survives the account's own deletion.