Recommend a Backup and Recovery Solution for Unstructured Data — Lesson

Unstructured data — the documents, images, logs, scanned PDFs, video files, telemetry blobs, and SMB file shares your organization accumulates — is the bulk of what most enterprises store in Azure. It is also where the painful, headline-making losses happen: a misconfigured pipeline overwrites a year of analytics blobs, an angry contractor empties a file share before they leave, ransomware encrypts every container in a storage account at $03{:}14$ on a Sunday morning. As an Azure Solutions Architect Expert, your job in this lesson is to design a backup and recovery solution that addresses accidental deletion, logical corruption, insider threats, and ransomware, while meeting the recovery point and retention objectives the business agreed to.

We will work through the two surfaces that matter for unstructured data on Azure — Azure Blob Storage and Azure Files — and the two backup philosophies Microsoft offers for them: operational backup (lightweight, in-account, second-class "undo") and vaulted backup (durable, isolated, ransomware-resistant). By the end you will be able to size, configure, and defend a design covering Recovery Point Objective ($\text{RPO}$), Recovery Time Objective ($\text{RTO}$), retention, immutability, and Multi-User Authorization (MUA).

Why This Matters

The Azure shared-responsibility model is unambiguous: your data is your problem. Storage redundancy options like LRS, ZRS, and GRS protect you against hardware failure and zonal or regional outages, but they do nothing against the most common loss event — someone (or something) deleting the data on purpose. A DELETE issued through the data plane is dutifully replicated to every replica in milliseconds. If you do not have a backup, that data is gone.

For an architect preparing for AZ-305, this is one of the highest-leverage design decisions you make: every Well-Architected Framework review asks about it under the Reliability pillar, and every regulator (HIPAA, SOX, GDPR) expects evidence that you can restore. Get this design wrong and the operational team inherits a $10{,}000$-file restore-from-storage-explorer scramble at 2 AM. Get it right and your worst day becomes a 30-minute restore job documented in a runbook.

Prerequisites

• Storage account types and redundancy — You should know the difference between Standard_LRS, ZRS, GRS, RA-GRS, and GZRS. Self-check: Which redundancy option survives a regional disaster but does not give the application read access to the secondary?
• Blob types — Block, append, and page blobs behave differently under backup. Self-check: Why are page blobs (used by managed disks) excluded from blob operational backup?
• Soft delete and versioning for blobs — Operational backup depends on these. Self-check: What is the difference between blob soft delete and container soft delete?
• Azure Files share types — Standard (HDD/SSD) versus Premium; SMB versus NFS. Self-check: Which Azure Files protocol is currently unsupported by snapshot-based backup?
• Recovery Services Vault versus Backup Vault — Two distinct ARM resource types. Self-check: Which one would you use to back up an Azure VM, and which for Azure Blob Storage?
• RBAC scope — You should be comfortable assigning roles at storage-account scope. Self-check: What is the least-privilege role to allow Azure Backup to operate on a storage account?

Learning Objectives

By the end of this lesson you will be able to:

1. Analyse unstructured-data backup requirements (RPO, RTO, retention, immutability) and translate them into Azure Backup configuration choices.
2. Differentiate operational and vaulted backup for blobs, and recommend the right one (or both) for a given scenario.
3. Design an Azure Files backup strategy covering snapshot scheduling, share protection, and cross-region considerations.
4. Evaluate ransomware-resistance controls — immutable vaults, soft delete, MUA — and place them appropriately in a defence-in-depth design.
5. Recommend a retention policy that satisfies regulatory requirements without inflating storage cost unnecessarily.
6. Compare point-in-time restore, snapshot restore, and vaulted-backup restore in terms of granularity, latency, and security boundary.

Building Blocks

Define the foundational vocabulary before anything else — these terms appear repeatedly in the Deep Dive and on the exam.

Recovery Point Objective ($\text{RPO}$) — Analogy: how often you save a draft of a document. Definition: the maximum acceptable amount of data loss measured in time. Why it matters: drives backup frequency. A 1-hour RPO means a backup ran in the last 60 minutes.

Recovery Time Objective ($\text{RTO}$) — Analogy: how long the restaurant kitchen is closed after a fire. Definition: the maximum acceptable time to restore service after a failure. Why it matters: drives backup technology choice (snapshots restore in seconds, cross-region vaulted copies in hours).

Operational backup (blobs) — Analogy: the Recycle Bin on your desktop — same disk, fast undo. Definition: a backup that lives inside the source storage account, leveraging blob versioning, change feed, and soft delete to provide continuous point-in-time restore. Why it matters: it is cheap and fast, but shares the blast radius of the source.

Vaulted backup (blobs) — Analogy: an off-site safety deposit box. Definition: a backup that is copied out of the source account into a Microsoft-managed Backup Vault, isolated from the customer's storage plane. Why it matters: this is the only option that survives total source-account loss (deletion, compromise) and is the foundation of ransomware resistance.

Backup Vault — Analogy: a modern, multi-tenant safe room. Definition: an ARM resource (Microsoft.DataProtection/backupVaults) that stores vaulted backups for blobs, disks, PostgreSQL flexible servers, AKS, and Azure Files (vaulted tier). Why it matters: this is the newer vault type and the one Microsoft is investing in for new workloads.

Recovery Services Vault — Analogy: a slightly older safe room with a different lock. Definition: an ARM resource (Microsoft.RecoveryServices/vaults) that stores backups for VMs, classic Azure Files snapshot protection, SQL in VM, SAP HANA, and Azure Backup Server. Why it matters: still required for IaaS VM and snapshot-based Azure Files backup.

Snapshot (Azure Files) — Analogy: a read-only photo of the share at a point in time. Definition: a file-share-level, in-place snapshot stored in the same storage account. Why it matters: 200 snapshots maximum per share, instant restore at the file/folder level.

Soft delete — Analogy: a 14-day grace period before the trash truck collects. Definition: a per-resource flag that defers the physical destruction of a deleted blob/container/share/vault by a configurable number of days. Why it matters: it is defence, not backup; an attacker with sufficient permissions can purge during the soft-delete window.

Immutable vault — Analogy: a one-way deposit slot — you can put things in but you cannot take them out before the timer expires. Definition: a Backup Vault setting that prevents anyone, including subscription owners and Microsoft, from shortening retention or deleting recovery points before expiry. Why it matters: this is the WORM-equivalent control for backup data, and is the heart of ransomware-proof design.

Multi-User Authorization (MUA) — Analogy: a nuclear submarine's two-key launch system. Definition: a feature that requires a second principal (the Resource Guard owner in a different subscription) to approve high-privilege backup operations. Why it matters: it neutralises a single compromised admin account.

Change feed — Analogy: the storage account's transaction log. Definition: an append-only log of every blob create/update/delete, stored in a hidden $blobchangefeed container. Why it matters: it is the substrate that powers blob operational backup and point-in-time restore.

Deep Dive

Azure Files Backup

Azure Files is the SMB/NFS-as-a-service offering. Its native protection model is file-share snapshots, and Azure Backup provides a managed lifecycle layer on top.

A share snapshot is a read-only, point-in-time copy of an entire share. It is space-efficient — only changed 4 MiB blocks consume additional capacity — and instant to create. Restores can be performed at three levels: the entire share (revert), an individual file or folder (item-level recovery), or via a SAS URL exposed for the snapshot. There is a hard ceiling of 200 snapshots per share, so retention scheduling matters.

Azure Backup for Azure Files has historically run only in snapshot tier: snapshots stay inside the source storage account, and a Recovery Services Vault simply orchestrates the schedule and tracks recovery points. Microsoft now offers a vaulted tier for Azure Files, where snapshots are also copied into a Backup Vault for off-account durability — this is the protection model you choose when you need to survive deletion of the storage account.

Four scheduling cadences — daily, weekly, monthly, yearly — stack to give you grandfather/father/son retention. Every recovery point counts against the 200-snapshot share limit, so if you set both daily and hourly schedules naively you may exhaust the limit in a week.

[!IMPORTANT] Snapshots are intra-account. If the storage account is deleted (accidentally, maliciously, or through a botched IaC apply), every snapshot is gone with it. Use the vaulted tier, or the storage-account-level resource lock plus storage-account soft delete, if loss of the account itself is in scope.

Azure Blob Operational Backup

Operational backup for blobs is a local protection model that uses three pre-existing storage features as its substrate: container soft delete, blob versioning, and the change feed. When you enrol a storage account into operational backup, all three are turned on (and held on) automatically. The result is continuous point-in-time restore: at any moment within the configured retention window (up to 360 days), you can revert one or more containers — or the entire account's block blobs — to any point in the past.

Because every byte of recovery data lives inside the source storage account, operational backup is fast, cheap, and supports very fine-grained restore (folder, prefix, single blob). It is also not isolated: a sufficiently privileged principal can disable it, and a deletion of the storage account takes the operational backup with it. Operational backup is the "undo" layer, not the "safe" layer.

Important constraints to design around: only block blobs are protected (page blobs / managed disks need disk backup; append blobs are excluded), only the Hot and Cool tiers participate (Archive blobs are skipped until rehydrated), and a single storage account cannot be protected by more than one operational-backup policy at a time.

[!TIP] Operational backup is essentially "free" in compute terms but you still pay for the change-feed storage and version capacity. For an account with high write churn, the version count can blow up; tune the retention down if your backup-storage line item starts dominating.

Azure Blob Vaulted Backup

Vaulted backup for blobs is the answer to "what happens if the storage account itself is gone?" and "what if the attacker has Owner on my subscription?" It works by copying blob data out of the customer-owned storage account into a Microsoft-managed Backup Vault. The customer cannot access this storage directly: the vault hands back recovery points, not raw blobs.

Vaulted backup runs on a discrete-schedule basis (daily) rather than continuously. Retention is configured per recovery point — daily, weekly, monthly, yearly — up to 10 years. Restore granularity is per-container (or per-blob with prefix filters), and the restore target can be a different storage account in any region — critical for ransomware playbooks where the source account is potentially compromised.

Because vaulted backup data lives outside the customer's data plane, deleting the source storage account does not delete the backup. Combined with an immutable vault and MUA, this is the only configuration on Azure that meaningfully resists a fully compromised customer admin.

Vaulted backup costs more than operational — you pay for protected-instance fees plus vault-tier storage — and restores are slower because data must transit out of the vault. Use it as the durable tier in a two-tier design: operational backup gives you sub-second "oops, undo"; vaulted backup gives you the safe room.

Immutability and Ransomware Protection

Ransomware playbooks against Azure typically follow this pattern: compromise an identity that has Owner or Storage Blob Data Contributor on a target storage account, generate a SAS, exfiltrate or encrypt blobs, issue an account-wide deletion or change the tier to Archive, then wipe backups so the victim has no choice but to pay. Defending against this means the attacker must be unable to delete the recovery points, even with full subscription Owner.

Four controls combine:

The pattern most architects use for high-value data: vaulted backup into a Backup Vault that is enabled-and-locked for immutability, with MUA pointing at a Resource Guard in a separately-owned subscription (often the central security team's). At that point the only way to lose the backup is to compromise two completely separate identity boundaries.

[!WARNING] Immutable vault has two states: enabled (reversible by an Owner) and locked (irreversible — even Microsoft cannot disable it). Designs that quote "immutable vault" but only enable, never lock, are common audit findings. The lock is the whole point.

Retention, MUA, and Soft Delete

Retention is a regulatory question first and a cost question second. Common minimums you should recognise:

Build your retention policy bottom-up: hourly/daily for operational restores, weekly/monthly for medium-term recovery, yearly for compliance. Retention longer than 5 years should almost always sit on vaulted, immutable, archive-tiered backup.

MUA deserves a closer look. The Resource Guard is an ARM resource in a different subscription (and ideally a different tenant for the highest-assurance designs). When MUA is enabled on a vault, the following operations require the resource-guard owner to grant approval:

• Disable soft delete on the vault
• Disable MUA itself
• Modify a backup policy in a way that reduces retention
• Delete a backup instance
• Stop protection with delete data

Soft delete on the Backup Vault is a complement: when a recovery point is deleted, it goes into a 14–180 day soft-delete window before physical destruction. Combined with immutability, this is your final safety net against well-intentioned mistakes.

Worked Examples

Example 1 — Easy: Pick the right backup type for a finance team's Azure Files share

Problem. Contoso Finance keeps their working Excel models on a 2 TiB Azure Files Premium share. They want to recover individual files for 30 days and weekly snapshots for 1 year. They are not concerned about losing the entire storage account — it is locked with CanNotDelete and only the platform team can touch it.

Solution.

1. Provision a Recovery Services Vault in the same region as the share.
2. Discover the storage account; register it with the vault.
3. Configure the file-share backup policy: daily snapshot at $22{:}00$, retain 30 daily + 52 weekly recovery points.
4. Verify total snapshot count $= 30 + 52 = 82$, comfortably under the 200-snapshot limit.
5. Test an item-level restore using the AzureFileShare restore wizard targeting an alternate path.

[!NOTE] Snapshot tier is correct here because the source-account loss is out of scope. The CanNotDelete lock plus storage-account soft delete handles "oh no, someone deleted the account." Vaulted Azure Files backup would add cost without addressing a real risk.

Example 2 — Medium: Ransomware-resistant blob backup for a legal e-discovery archive

Problem. A law firm stores 40 TiB of client documents in RA-GZRS block-blob storage. Compliance requires 7 years retention and immutability. Yesterday, a competitor in the same city was hit by ransomware that deleted both source and backups. Design a backup that survives an Owner-level compromise of the workload subscription.

Solution.

1. Provision a Backup Vault in a different subscription owned by the security team (call it sub-security-vaults). Use cross-region GeoRedundant storage on the vault.
2. Enable vault soft delete with 180-day retention; enable and lock immutability on the vault.
3. Create a Resource Guard in sub-security-vaults and configure MUA on the Backup Vault, naming the resource guard.
4. In the workload subscription, register the storage account with the vault and assign the vault's managed identity the Storage Account Backup Contributor role (least privilege).
5. Apply a vaulted-backup policy: daily backup, retain 30 daily / 12 weekly / 24 monthly / 7 yearly. Store the yearly tier on archive-equivalent vault storage to keep cost down.
6. Layer operational backup on the source storage account with a 14-day window so day-to-day restores never touch the vault.
7. Document the restore runbook: in a ransomware event, restore vaulted backups to a new storage account in a different resource group; never reuse the compromised account name.

[!NOTE] The two-subscription split is the load-bearing detail. An Owner role on the workload subscription cannot delete or shorten retention on a backup that lives in a vault they don't own, because MUA gates the destructive operation behind the security team's resource guard.

Example 3 — Hard: Cross-region unstructured backup with mixed RTO and compliance constraints

Problem. Northwind Healthcare runs a mixed unstructured-data estate in westeurope:

• 200 TiB of imaging blobs (DICOM): 24-hour RPO, 4-hour RTO, HIPAA 6-year retention, must survive regional loss.
• 5 TiB of nightly database exports as block blobs: 24-hour RPO, 30-minute RTO for most-recent backup.
• 1 TiB of an Azure Files SMB share (clinician documents): 1-hour RPO, 1-hour RTO, 30 days retention.

Design one cohesive solution.

Solution.

1. DICOM imaging blobs — storage account is Standard_GZRS. Enable vaulted backup into a cross-region Backup Vault in northeurope; daily schedule, retention 30 daily / 12 monthly / 7 yearly. Lock immutability. The combination of GZRS (regional resilience for the live data) plus a cross-region vault (ransomware resilience and regional-loss insurance for the backup) meets both the 4-hour RTO and the 6-year retention.
2. Nightly DB exports — these only need short-term "undo". Enable operational backup with 14-day retention. The 30-minute RTO requirement is met because operational backup restores in seconds for small blob sets. Do not layer vaulted backup; redundancy of the source storage account already covers BC/DR for 24-hour-old data.
3. Clinician SMB share — use Recovery Services Vault snapshot-tier backup. To meet the 1-hour RPO, configure four snapshots per day at $00{:}00$, $06{:}00$, $12{:}00$, $18{:}00$. With 30 days retention that is 120 snapshots; under the 200-share limit. For HIPAA, add an Azure Policy denying deletion of the storage account.
4. Cross-design controls — single Backup Center dashboard for monitoring, alerts on missed backup jobs, RBAC giving Backup Operators read-only access by default, MUA only on the imaging vault (highest value).

[!NOTE] The exam loves designs that mix protection models intentionally. Junior architects often vault-back-up everything; a senior architect picks the cheapest model that meets the requirement and reserves vaulted-immutable for genuinely high-value data.

Visual Explanations

Decision tree for picking blob backup model.

Caption. Use this tree as the default mental model for the exam. The first branch is the security boundary question; the second is the retention question. Most production designs eventually land in Both.

Architecture: Defence-in-depth backup for high-value blob data.

Caption. Three boundaries protect the backup: the vault lives in a different subscription, immutability is locked, and a resource guard enforces multi-user approval on destructive operations.

Ransomware-recovery flow for vaulted blob backup.

Caption. Isolation feeds both recovery and forensics. Rushing to restore over the compromised account often re-infects the data.

Operational vs vaulted blob backup at a glance.

Caption. The two are complements, not alternatives. Operational gets restored on a Tuesday afternoon. Vaulted gets restored on the worst day of your professional life.

Azure Files protection options.

Caption. Azure Files is the older sibling — snapshot-based protection is the default; the vaulted tier is catching up but you should validate GA in your target region.

Restore-target decision matrix (vaulted blob backup).

Caption. The exam tests "which restore target" under a ransomware framing — the answer is almost always not the original location.

Common Mistakes

❌ Myth: "Soft delete is a backup." ✅ Reality: Soft delete is a deferred-deletion feature. It buys you a window (typically 7–365 days) to recover from accidental deletion, but a sufficiently privileged principal can purge during the window, and it does not protect against modification, encryption, or account-level deletion. Why it's tricky: Soft delete shows up in the same Storage > Data Protection blade as actual backup, and the marketing language uses words like "recoverable." Many junior engineers conflate the two.

❌ Myth: "Vaulted backup and operational backup are alternatives — you pick one." ✅ Reality: They are designed to layer. Operational backup gives you fine-grained, fast, in-account restore for the 99% of incidents that are accidents; vaulted backup gives you the off-account, immutable, long-retention copy for the 1% that is a disaster. Production-grade designs almost always use both. Why it's tricky: The Azure portal makes you choose between them in some flows, and the docs sometimes describe them as parallel options rather than complementary tiers.

❌ Myth: "If I enable immutability on the Backup Vault I am safe from ransomware." ✅ Reality: Only if you also lock the immutability setting. The default state is enabled (reversible by a vault Owner). An attacker with sufficient privilege can flip it back to disabled and then start deleting recovery points. Locked + MUA is the safe configuration. Why it's tricky: The blade shows a green check the moment you enable immutability, and there is no obvious red badge reminding you to lock.

❌ Myth: "Azure Files snapshots survive deletion of the storage account." ✅ Reality: Snapshots are intra-account objects. Deleting the storage account deletes the snapshots. To survive account loss you need either vaulted-tier Azure Files backup, an off-account copy (AzCopy to immutable blob), or storage-account-level resource locks plus storage-account soft delete. Why it's tricky: A snapshot "feels" separate from the live share — you mount it as a different share — but it shares the underlying account's lifecycle.

Practice Exercises

Exercise 1. 🟢 Easy. Northwind Bank has a 500 GiB block-blob container of regulatory disclosures that must be retained for 10 years and immutably so. Which Azure backup product should you recommend, and which two settings are non-negotiable?

▶💡 Hint

Think about the maximum retention of operational backup and the meaning of "immutable."

▶✅ Solution

Vaulted backup in a Backup Vault. Operational backup tops out at 360 days, which is short of 10 years. The two non-negotiable settings are vault-tier immutability set to Locked and MUA via a Resource Guard.

Exercise 2. 🟢 Easy. Why are page blobs (and therefore managed disks) excluded from blob operational backup?

▶💡 Hint

What backup product covers managed disks?

▶✅ Solution

Managed disks have their own backup model (Azure Disk Backup via the same Backup Vault resource) that uses incremental disk snapshots. Page-blob restore semantics differ from block-blob versioning, so they are intentionally split into a separate workload type in Azure Backup.

Exercise 3. 🟡 Medium. Contoso wants 1-hour RPO for an Azure Files share with 30-day retention. They are nervous about hitting the 200-snapshot limit if they use sub-daily snapshots. Design a snapshot schedule that meets the RPO, fits under the limit, and explain the trade-off.

▶💡 Hint

1-hour RPO means a snapshot every hour, which gives $$24 \times 30 = 720$$ snapshots — over the limit. Stagger retention.

▶✅ Solution

Use a tiered schedule: hourly snapshots retained for 48 hours (48 snapshots), then four daily snapshots retained for 14 days (56 snapshots), then weekly for 12 weeks (12). Total around 116 — under 200 with headroom. Trade-off: anything older than 48 hours has a 6-hour effective RPO. If the business cannot accept this, use vaulted-tier Azure Files or layer in a separate AzCopy job into immutable blob.

Exercise 4. 🟡 Medium. A storage administrator with Owner on the workload subscription is pressured by an attacker into deleting all backups. The vault has immutability enabled but not locked, and MUA is not configured. Walk through what the attacker can do.

▶💡 Hint

The order matters — what does the attacker need to flip first to make destruction possible?

▶✅ Solution

With Owner privilege the attacker (or coerced admin) can: toggle vault immutability from enabled back to disabled (reversible because the lock was never applied), shorten the backup policy retention to a small value, then wait for retention to flush or explicitly delete recovery points. Without MUA there is no second-pair-of-eyes step. Lesson: locking immutability removes the first step and MUA removes the second being doable unilaterally.

Exercise 5. 🔴 Hard. A healthcare archive needs 7-year retention, must survive a region loss, and must be restorable by a different operations team than the one that owns the workload subscription. Sketch the subscription topology, vault placement, and RBAC for the design.

▶💡 Hint

Think about whose Owner role you are protecting against, and what residence the data needs.

▶✅ Solution

Subscriptions: sub-workload-prod (storage accounts) and sub-security-backup (Backup Vault). Vault: Backup Vault in sub-security-backup, GeoRedundant storage, paired-region replication, immutability locked, MUA enabled with a Resource Guard in sub-security-backup. RBAC: workload-team identities get Storage Blob Data Contributor on the source account but only Backup Reader on the vault; the operations team gets Backup Operator on the vault, allowing restore but not deletion. Restores triggered by the ops team go to a different storage account in sub-workload-prod.

Exercise 6. 🟡 Medium. Distinguish between container soft delete, blob soft delete, blob versioning, and point-in-time restore. Which depend on which?

▶💡 Hint

Only one of them lets you go back to any moment in time.

▶✅ Solution

Container soft delete defers physical deletion of an entire container for 1–365 days. Blob soft delete defers deletion of an individual blob. Versioning creates a new immutable version on every write. Point-in-time restore (PITR) uses change feed + versioning to reconstruct any past state within retention. PITR depends on blob soft delete, versioning, and the change feed; container soft delete is independent. Operational backup turns on all of these automatically.

Exercise 7. 🔴 Hard. The CISO asks: "If I enable immutable storage with a 7-year time-based retention on the source container, do I still need vaulted backup?" Defend your answer in two sentences.

▶💡 Hint

What happens to the immutable container if the storage account is deleted?

▶✅ Solution

Yes — immutable storage protects against modification of existing blobs, but if the storage account itself is deleted (either accidentally during cleanup or by a compromised Owner), the immutable container is destroyed with it (after the soft-delete window). Vaulted backup in a separate subscription is the only control that survives loss of the source account.

Exercise 8. 🟡 Medium. Choose the cheapest backup configuration that satisfies: 7-day operational restore window for a 1 TiB block-blob account with low write churn, no compliance mandate, no ransomware concern beyond what soft delete provides.

▶💡 Hint

Do you actually need any vaulted product here?

▶✅ Solution

Enable container soft delete (7 days), blob soft delete (7 days), versioning, and operational backup with 7-day retention via a Backup Vault. No vaulted backup, no immutability, no MUA. Cost is dominated by version-storage overhead; with low write churn this is small. If risk appetite later changes, layer vaulted backup on top without disturbing this baseline.

Summary & Concept Map

• Unstructured data on Azure means block blobs and Azure Files; both have first-party backup products that are different and must be designed separately.
• The two-tier mental model — operational backup for fast in-account undo, vaulted backup for durable off-account safety — is the default for any production block-blob workload.
• Snapshot tier is the workhorse for Azure Files; vaulted tier extends protection to survive storage-account loss, with a 200-snapshot per-share ceiling driving schedule design.
• Immutability must be locked (not merely enabled) to be ransomware-resistant; MUA with a separately-owned Resource Guard adds the final defence against compromised Owner privilege.
• Soft delete is not backup; it is a deferred-deletion feature that complements, but does not replace, vaulted protection.
• Retention design is regulatory-first (6 years HIPAA, 7 years SOX, 10-year long-term archive); cost optimisation comes from tiering retention across operational, vaulted, and archive-tier vault storage.
• The restore target in a ransomware playbook is never the original storage account; restore to a new account, in a new resource group, ideally in a different region until forensics clear the source.