Archive storage tiers for backups: minimum durations, retrieval time and the recovery bill

About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not lab validation. Check the stated versions and your own requirements before making changes.

Cloud storage providers offer colder, cheaper tiers for data you rarely read. Backup copies look like a perfect fit: written once, seldom read. So proposals often place long-term backups, and sometimes all off-site backups, in an archive tier.

Two details can turn that saving into a problem. First, colder tiers often have a minimum storage period, and deleting or moving data early is charged as if it had stayed. Second, the coldest tiers are offline: the data must be retrieved before it can be read, which can take hours. This guide is for buyers comparing storage options for backups. It sets out how three major providers describe those details, and how to check what they mean for your recovery time and your bill. Prices change too often to quote; check each provider's pricing page.

Why it matters

A recovery time objective covers the whole restore, not just copying data back (our reading). If the only clean copy after a ransomware attack sits in a tier that takes 12 hours to retrieve before the restore can even start, the plan has a 12-hour hole in it.

Minimum durations matter for retention design. Backup software often deletes old copies on a schedule, or merges and rewrites them. If those copies sit in a tier with a 180-day minimum and are deleted after 30, the business may pay for 180 days anyway (our understanding of how the charges apply to backup patterns).

Amazon S3

AWS describes its archive classes as "designed for low-cost, long-term data storage and data archiving", noting: "These storage classes require minimum storage durations and retrieval fees making them most effective for rarely accessed data."

The three Glacier classes differ mainly in how fast data can be read:

• S3 Glacier Instant Retrieval: "Use for long-term data that's rarely accessed and requires milliseconds retrieval." AWS's comparison table lists a 90-day minimum storage duration.
• S3 Glacier Flexible Retrieval: AWS's table describes it as "Long-lived archive data accessed once a year with retrieval times of minutes to hours", with a 90-day minimum.
• S3 Glacier Deep Archive: "Long-lived archive data accessed less than once a year with retrieval times of hours", with a 180-day minimum in the table.

The last two are offline: "S3 Glacier Flexible Retrieval and S3 Glacier Deep Archive objects are archived, and not available for real-time access."

AWS's retrieval page gives typical times. For Flexible Retrieval, "Standard retrievals typically finish within 3–5 hours", "Bulk retrievals typically finish within 5–12 hours", and expedited retrievals of smaller objects are "typically made available within 1–5 minutes". For Deep Archive, "Standard retrievals typically finish within 12 hours" and bulk retrievals "typically finish within 48 hours." AWS adds that "Expedited retrievals are a premium feature and are charged at the Expedited request and retrieval rate."

Large objects take longer. AWS says objects over 5 terabytes "will take longer to be restored with up to 300 megabytes per second of retrieval throughput", and gives an example: "a 50-terabyte S3 Glacier Flexible Retrieval object could take up to 48 hours to complete."

Azure Blob Storage

Microsoft describes the archive tier as "An offline tier optimized for storing data that is rarely accessed, and that has flexible latency requirements, on the order of hours."

For general-purpose v2 accounts, Microsoft specifies 30-day minimum retention for cool-tier objects and 90 days for cold-tier objects. Its table distinguishes Blob Storage accounts, which have no minimum retention duration for cool or cold. Archive has a 180-day minimum. Check the account type and applicable pricing terms before predicting an early-deletion charge.

Early changes are charged: "Blobs are subject to an early deletion penalty if they are deleted, overwritten or moved to a different tier before the minimum number of days required by the tier have transpired."

Reading archived data needs rehydration first: "An archived blob is offline and can't be read or modified." The rehydration page describes standard priority as possibly taking up to 15 hours and high priority as possibly completing in under one hour for objects under 10 GB. High priority costs more and can exceed an hour depending on blob size and current demand. These are qualified per-object examples, not a bound on all objects in a backup or a guaranteed completion time.

Microsoft also notes that copying an archived blob to an online tier, rather than changing its tier, can avoid "the early deletion fee that is assessed if you change the tier of a blob from the archive tier before the required 180-day period elapses."

Throughput and scale limits

Typical times describe a single request. A full recovery usually means many objects, and the limits differ.

AWS says that after restore requests are made, "S3 Glacier supports restoring large datasets at a throughput of up to 1–2 petabytes per day per customer account." For urgent work it offers reserved capacity: "Provisioned Capacity helps ensure that Expedited retrieval capacity is available when you need it." Each unit "provides that at least three Expedited retrievals can be performed every 5 minutes, and it provides up to 300 megabytes per second of retrieval throughput."

Microsoft sets a ceiling on its faster option: "A maximum of 10 GiB per storage account can be rehydrated per hour with priority retrieval." In our reading, that means high priority suits a few urgent files, not a whole server's backup.

Microsoft also warns about a quieter trap. Copying, rather than changing tier, "can also prevent a lifecycle management policy from moving a rehydrated blob back to the archive tier." A lifecycle rule that re-archives data during a long restore could, in our understanding, undo part of the recovery.

Taken together (our recommendation): estimate retrieval for your total data size and object count, not one object, and confirm whether any emergency option has a per-hour or per-account limit.

Google Cloud Storage

Google's colder classes are online. Its documentation says of Archive storage: "Unlike the "coldest" storage services offered by other Cloud providers, your data is available within milliseconds, not hours or days."

The trade-off is cost and minimums. Nearline has "a 30-day minimum storage duration", Coldline "a 90-day minimum storage duration", and Archive "higher costs for data access and operations, as well as a 365-day minimum storage duration." Google describes Archive as "the best choice for data that you plan to access less than once a year."

Side by side

As described in each provider's documentation on 14 November 2026 (our summary; check current pages):

Choosing a tier for each copy

The following is our recommendation, not provider guidance.

• The copy you would restore from first should sit where it can be read immediately. An offline tier adds its retrieval time to every restore.
• Long-term copies kept for months or years, and rarely restored, are a better fit for offline tiers, provided the retention is longer than the tier's minimum.
• Short-retention or frequently rewritten copies should avoid tiers with long minimums, or early deletion charges can outweigh the saving.
• Ask your backup software or provider how it writes to the tier: whether it rewrites, merges or deletes objects before the minimum period.
• Include retrieval in the recovery bill. Retrieval, request and transfer charges apply when you need the data most.

Read-only checks

These checks read settings and documents; they change nothing. If you use the AWS command-line tool in a Linux or macOS shell, you can read a bucket's lifecycle rules:

aws s3api get-bucket-lifecycle-configuration --bucket example-backup-bucket

The output lists rules that move objects to colder classes and when. The account needs read permission; an error saying no configuration exists means no lifecycle rule is set.

Without command-line access, use each provider's console or ask your provider for:

1. Tier per copy. Which storage tier holds each backup copy?
2. Retention per copy. How long is each copy kept, and is that longer than the tier's minimum?
3. Retrieval time. For an offline tier, which retrieval option would be used in an emergency, and how long would it take for your data size?
4. Retrieval cost. What would a full restore of your largest system cost to retrieve and transfer?

These checks show the design. They do not prove the retrieval time; a test does (our recommendation).

Safe restore rehearsal

Use an authorised isolated environment and synthetic or approved non-sensitive test data. Provider retrieval can incur charges; agree the exercise scope and budget first.

1. Sample a representative backup set in the intended tier using the real retrieval option. Record its size, object count, account/region, concurrent work and request time.
2. Measure when the sampled objects become readable, the transfer, restoration and application checks. Record each observed interval and the sample's scope.
3. Estimate separately if scaling that sample to a larger system. State assumptions about object count, quotas, available throughput, service demand and dependencies. Advertised throughput and linear scaling are planning inputs, not proof of the recovery objective.
4. Validate the objective with an authorised representative end-to-end exercise at the intended volume and object count, including retrieval, transfer, restore and application checks. Compare measured results only with the matching objective; record untested scale or dependencies as unknown.
5. Reconcile actual charges for retrieval, requests and transfer against the estimate, and separately assess storage and early-deletion charges over the intended retention cycle.

Diagnosing what you find

• Retrieval took far longer than expected: the slowest retrieval option was used; the data was split into many small objects; or demand on the service was high.
• The bill shows early deletion charges: retention is shorter than the tier minimum; backup software rewrites or merges objects; or lifecycle rules move data back and forth.
• The restore could not start until retrieval finished: the first-restore copy is in an offline tier; no online copy exists; or the restore tool needs all data present.
• Retrieval cost was a surprise: expedited options were used; data was transferred out of the provider; or many small requests were made.

Worked example (illustrative)

In this invented decision scenario, a firm keeps 35 days of daily backups and 12 monthly copies in an archive tier with a 180-day minimum. It identifies a risk of early-deletion charges and retrieval delay. A small retrieval trial would provide evidence for that sample only; it would not establish whole-server recovery time. The firm proposes an online tier for daily copies and archive for suitable monthly copies, subject to an authorised exercise at representative volume/object count and a comparison of actual charges. The revised recovery time and cost outcome remain unverified until those checks finish; no successful retest or saving is claimed.

Risks and limits

• Durations, times and fees change; check current pages.
• Typical retrieval times are not guarantees.
• Backup software may handle tiers differently from direct storage use.

Sources

All accessed 14 November 2026.

• AWS, Understanding and managing Amazon S3 storage classes: https://docs.aws.amazon.com/AmazonS3/latest/userguide/storage-class-intro.html
• AWS, Understanding archive retrieval options: https://docs.aws.amazon.com/AmazonS3/latest/userguide/restoring-objects-retrieval-options.html
• Microsoft, Access tiers for blob data: https://learn.microsoft.com/en-us/azure/storage/blobs/access-tiers-overview
• Microsoft, Blob rehydration from the archive tier: https://learn.microsoft.com/en-us/azure/storage/blobs/archive-rehydrate-overview
• Google Cloud, Storage classes: https://cloud.google.com/storage/docs/storage-classes

Related future topics

• Sizing backup retention and capacity
• Restore time from cloud storage over the internet
• Lifecycle rules and backup software

This article was originally published on 14 November 2026.