A lifecycle policy quietly moved a set of blobs to Archive tier months ago, and now someone urgently needs one back within the hour. What are your actual options?

A blob in Archive tier is offline — it cannot be read directly at all until it's explicitly rehydrated back to Hot or Cool, and standard-priority rehydration typically takes up to 15 hours, not minutes. The only way to get it back within an hour is requesting rehydration with High priority, which is faster but not guaranteed for large blobs and costs meaningfully more — and if High priority still can't reliably meet the deadline, the honest answer is that the data isn't actually recoverable in time, which is exactly the constraint that needed to be designed around before archiving it.

This isn't a malfunction — Archive tier is deliberately an offline storage class, priced far below Hot or Cool specifically because the data isn't kept in a directly-readable state. The lifecycle policy did exactly what it was configured to do; the gap is that nobody accounted for this specific access pattern when deciding what should be eligible for archiving in the first place.

• A direct read or download attempt against the blob fails or returns an error indicating the blob is not in a readable state.
• The blob is confirmed to still exist (visible in a container listing) — this isn't a missing-data problem, it's an availability-state problem.
• The urgency is discovered only when access is attempted, not before — the lifecycle policy's tiering decision from months earlier had no visibility into this specific future need.

• The blob is in Archive tier, which is fundamentally an offline tier — unlike Hot or Cool, data in Archive cannot be read in place; it must be explicitly rehydrated to an online tier first.
• No rehydration request has been made yet, or one was made at Standard priority without accounting for the actual time budget the incident has.
• The team assumed "cold storage" meant "slower to access" rather than "not accessible until an explicit, time-consuming operation completes" — a common and costly misunderstanding of what Archive tier actually is.

Confirm the blob's current access tier via the Portal, az storage blob show, or the SDK — this immediately confirms whether Archive-tier offline status is actually the blocker, rather than a permissions or networking issue that happens to coincide.

Check whether a rehydration operation is already in progress for this blob — rehydration is asynchronous once requested, and re-requesting it doesn't make an in-progress rehydration faster; confirming current status avoids wasted duplicate effort under incident pressure.

Determine the blob's actual size, since rehydration time (especially for High priority) is influenced by size — a large blob may not realistically complete within an hour even at High priority, which changes the conversation from "how do we get this back" to "what's the actual realistic ETA, and does the incident response need to proceed without it."

Initiate rehydration with High priority rather than Standard — this targets faster retrieval (often within an hour for smaller blobs) at a higher cost per operation, which is the correct trade to make under genuine incident urgency. Rehydrate to Hot or Cool tier depending on whether the data will need continued fast access afterward or can return to a warmer-but-not-Hot tier once the immediate need passes. If the realistic rehydration time — even at High priority — doesn't fit the incident's actual deadline, that needs to be communicated honestly and immediately, rather than treated as solvable by simply "trying harder."

If any data has a plausible future need for fast, unplanned access — even data that's genuinely accessed rarely — don't default it to Archive tier via a blanket lifecycle policy; use Cool or Cold instead, which remain immediately readable, or explicitly document and accept the retrieval-time trade-off for whatever does go to Archive. Build the "what if we need this back urgently" question into the lifecycle policy design conversation up front, not into an incident.

• Archive tier is offline, not just slow — a blob there cannot be read at all until an explicit rehydration operation completes.
• Rehydration priority (Standard vs. High) is the only lever to influence retrieval speed, and even High priority isn't a guaranteed fit for every deadline, especially for large blobs.
• The failure here isn't a bug or misconfiguration — the lifecycle policy did exactly what it was designed to do; the gap was not accounting for this access pattern when the policy was designed.
• Any data with even a plausible urgent-access scenario shouldn't be archived by default — Cool or Cold tier keeps data immediately readable while still reducing storage cost.

• Azure Blob Storage: Rehydrate blob data from the Archive tier