Azure / Basic: scope, identity, location, and resources / Lesson 6

Storage models, redundancy, and data protection

Choose object, file, or disk storage from access and lifecycle requirements. Separate durability, availability, replication, retention, and recoverability before selecting redundancy.

About 4 min readContent reviewed 2026-10-25

On this page

Lesson goals

Compare Blob Storage, Azure Files, and managed disks.
Explain primary-region and cross-region redundancy tradeoffs.
Model retention without claiming a price or recovery guarantee.

A data object, shared file, and attached disk differ

Azure Blob Storage serves object-oriented data such as documents and media, Azure Files provides managed file-share scenarios, and managed disks support virtual-machine storage needs. They have different protocols, naming, concurrency, performance, access, and backup assumptions. A storage account is a management resource for supported storage services and settings; account kind, tier, region, and redundancy choices affect available features. Do not use an object store as a transparent replacement for every shared filesystem or database. Start with data size, update pattern, metadata, consistency needs, and the clients that must read or write it.

Redundancy has a geographic and operational contract

Locally redundant, zone-redundant, and geo-redundant storage options protect against different failure domains under service-specific rules. Cross-region replication can be asynchronous, so recovery may involve a nonzero data-loss window. Read access to a secondary copy is another capability with supported options and constraints, not a universal property of every redundant account. Verify exact service and regional support instead of selecting an acronym as a guarantee. The planning model below declares a document workload’s needs and unresolved questions. It is not an Azure Storage account definition, and it does not prove a redundancy SKU is available or configured.

json Data-protection requirements, not a storage deployment

{
  "model": "storage-requirements-only",
  "data": "synthetic-course-documents",
  "needs": {
    "private_access": true,
    "zone_failure_tolerance": true,
    "recover_deleted_version": true
  },
  "verify": [
    "service-region-support",
    "retention-policy",
    "restore-procedure"
  ]
}

Expected output

replication and deleted-version recovery require separate decisions

A redundancy choice alone cannot establish recoverability after deletion or corruption. This model creates no account or container.

Retention capacity needs its own arithmetic

For an invented workload adding ten gigabytes daily and retaining seven daily versions of that amount, a simple uncompressed model retains seventy gigabytes. It excludes metadata, duplicates, snapshots, incremental behavior, lifecycle movement, transaction counts, and replication overhead, so it is not a bill estimate or account sizing guarantee. Use the model to expose what was included and omitted. Real data protection also needs expiration rules, legal or business retention, deletion permissions, and evidence that restores preserve the application’s required structure. Keeping bytes somewhere is not the same as recovering a usable service.

python Offline logical-retention arithmetic

daily_gb = 10
retained_days = 7
logical_gb = daily_gb * retained_days
print(logical_gb)
assert logical_gb == 70

Expected output

Seventy is a synthetic logical amount before overhead. No Azure price, tier, compression, or backup behavior is inferred.

Access policy and exposure are separate from replication

Prefer an explicit identity-based access design where supported, and review any shared-key or signed-access path as a separate capability. A private endpoint changes network reachability; it does not decide who may read a blob. Public-access settings, role scope, token audience, encryption/key choices, and client behavior all affect the complete path. Avoid embedding credentials in teaching snippets or storing secrets in tags and filenames. If a time-limited link is issued, define who may create it, which operation and object it allows, expiration, and how disclosure is handled. An unguessable object name is not authorization.

Test the failure that matters to the data owner

Define accidental deletion, overwrite, corruption, zone outage, and regional loss as different scenarios. Replication can propagate an unwanted change, while versioning, soft deletion, backup, or immutability policies address distinct retention and recovery risks depending on service support. Review how key loss, access revocation, or missing metadata could prevent restoration even when content remains. A future authorized test should recover selected synthetic data and validate application use, not merely report a successful backup job. This course performs no storage writes, account inspection, restore, or live availability test; all protection claims remain design intentions until separately verified.

Common errors and fixes

Geo-replication is treated as a recoverable history

Why it happens: Continuity copies are confused with versioned retention.
How to fix it: Design and verify deletion/corruption recovery separately.
Prevent it next time: Include restore validation and retained metadata.

A private endpoint is assumed to grant blob access

Why it happens: Network path and data authorization are conflated.
How to fix it: Review endpoint reachability and data permissions independently.
Prevent it next time: Test both denied and allowed synthetic access cases later.

Logical retained gigabytes are presented as the Azure bill

Why it happens: Overheads and service pricing dimensions are omitted.
How to fix it: Label the model and obtain current scoped estimates separately.
Prevent it next time: Never attach a universal price or free-tier promise to the example.

Check your understanding

1. Does seventy logical gigabytes prove the needed account capacity or cost?

Show worked solution

No. The model includes only ten times seven. It omits overhead, actual version behavior, replication, transactions, tier movement, and other dimensions. State those omissions, then evaluate the real service design and current scoped cost assumptions without claiming the arithmetic is a live quote.

2. Why might a replica fail to solve accidental deletion?