Restore and planning
How long a restore takes: the wait, then the download
Prices checked
Calculate preparation and transfer time
Amazon S3 · S3 Glacier Flexible Retrieval
25.2 hEverything back, at the soonest
Vendor gets data ready3 h to 5 h
Download at your speedat least 22.2 h
The vendor's published wait plus the download at your full 1000 Mbps: the soonest it can all be back. The vendor does not publish how fast it serves a whole restore, so a real restore can take longer.
Restore time in detail
| Shortest wait | 3 h |
|---|---|
| Longest wait | 5 h |
| Download time (at least) | 22.2 h |
| Everything back, at the soonest | 25.2 h |
| With the longest wait, at the soonest | 27.2 h |
What each retrieval speed costs
Restoring 10 TB in 1,000,000 files. Each speed charges per GB retrieved and per file restored, so many small files make the faster speeds dearer. Downloads and the restored copy are on the restore bill as well. Everything back runs from the vendor's shortest to its longest published wait, plus the download at your speed.
| Speed | Vendor's wait | Retrieval | Restore requests | Everything back |
|---|---|---|---|---|
| Expedited | 1 to 5 minutes | $279.40 | $10,000.00 | 22.2 h to 22.3 h |
| Standard (drawn above) | 3 to 5 hours | $93.13 | $50.00 | 25.2 h to 27.2 h |
| Bulk | 5 to 12 hours | $0.00 | $0.00 | 27.2 h to 34.2 h |
Calculated from the published preparation window and the download speed above.
Does waiting for the vendor save money?
Restoring 10 TB at 1,000 Mbps, the download takes at least 22.2 h at every vendor. What changes is the wait before it starts, and what the month you restore costs.
Not on this restore. The cheapest month you restore, $55.83 at Telnyx Cloud Storage · Regular Storage, has no wait: everything back in 22.2 h at the soonest. No offer that makes you wait longer costs less that month. Rank every offer for this restore
Vendor-published retrieval latency answers when archived data may become readable. Final restore time also depends on provider throughput, object count, concurrency, destination, and the reader's own receiving bandwidth. This page reports the published latency first, labels every computed range as an estimate, and says the answer cannot be estimated when the inputs cannot support a wall-clock range.
Compare storage and restore costs for your workload
First byte and final byte are different clocks
Archive availability tells you when a provider expects an object or restored copy to become readable. It does not tell you when the last byte reaches the recovery destination. Amazon publishes different typical availability windows by retrieval tier, Azure publishes per-object rehydration guidance and a High-priority account limit, and Oracle says a restore from Archive takes at most an hour to its first byte, that how long the whole restore takes depends on the object's size, and that the object cannot be downloaded until it is fully restored. [1] [2] [3]
The transfer clock needs the restore volume and a documented sustained-throughput range. Object count and concurrency can bind through provider request limits before the network fills, while the reader's receiving bandwidth can be slower than the provider path. [1] [4] [5]
The usual answer is therefore two lines: the vendor's availability statement, followed by a statement that final delivery cannot be estimated. A single number is shown only when the calculator can list every input and label the result as an estimate.
| Clock | What it answers | Where this comes from | If the information is missing | Source |
|---|---|---|---|---|
| Archive availability or first byte | When the selected object or restore tier may become readable | Vendor-published fact with its original qualifier | not published when no numeric latency exists | [1] [2] [3] |
| Transfer to destination | How long the readable bytes take to cross the provider path and reader link | Estimated range from measured or bounded throughput | cannot estimate when either end of sustained throughput is missing | [4] [5] |
| Full wall clock | Time from restore request to the final byte at the named destination | Scenario estimate, never a price fact | cannot estimate when object-ready overlap or transfer inputs are missing | [1] [2] |
A 3-5 hour archive window can still precede days of transfer
Take 10,000 GB in S3 Glacier Flexible Retrieval, Standard without Batch Operations. Amazon says restore completion typically takes 3-5 hours. That is the sourced availability fact. [1]
If the reader supplies a measured receiving range of 100-1,000 Mbps, the link-only arithmetic is 22.2-222.2 hours for 10,000 decimal GB. Those numbers are an estimate from the reader's own inputs and exclude provider sustained throughput, object count, concurrency, retries, integrity verification, and overlap between object availability and download.
Because those missing variables can dominate, the complete wall-clock output cannot be estimated. Reporting 25.2-227.2 hours by simply adding the two ranges would be valid only for a stated after-all-objects-readable workflow with documented end-to-end throughput, not for the default case.
| Line | Value | Where this comes from | What it does not prove | Source |
|---|---|---|---|---|
| Standard retrieval availability | Typically 3-5 hours | Vendor-published fact | Time to receive the final byte | [1] |
| Reader-link-only transfer | 22.2-222.2 hours for 10,000 GB at an entered 1,000-100 Mbps | Estimated from stated user inputs | Provider sustained throughput or object-processing time | Arithmetic from the stated inputs, no vendor source |
| Full wall clock | cannot estimate | Not estimated | No duration is fabricated | [1] |
Per-object latency does not scale linearly to a full recovery
Azure says a High-priority object under 10 GB might complete in less than one hour, but also caps High-priority rehydration at 10 GiB per storage account per hour. Microsoft warns that the per-object timelines do not scale linearly for bulk operations. [2]
For a stated scenario of 100 objects at 8 GiB each, the 800 GiB total has a provider-limit lower bound of 80 hours before considering the reader download. The 80-hour result is arithmetic from a published account ceiling, not a promised completion time or an upper bound. [2]
Object count and concurrency matter because 100 concurrent requests do not multiply an account-level 10 GiB/hour limit into 1,000 GiB/hour.
| Input or fact | Value | What kind of figure it is | Source |
|---|---|---|---|
| High-priority per-object guidance | Might complete in less than 1 hour for objects under 10 GB | Vendor-published fact with demand and size caveat | [2] |
| High-priority account limit | 10 GiB/hour | Provider-published ceiling shared across the account | [2] |
| Scenario inputs | 100 objects x 8 GiB = 800 GiB | Stated model inputs | Arithmetic from the stated inputs, no vendor source |
| Full-volume rehydration result | At least 80 hours at the published ceiling | Estimated lower bound, not a range | [2] |
| Final delivery | cannot estimate until download throughput and reader bandwidth are known | Not estimated | [2] |
Restore time does not replace the restore bill
A time estimate does not change the prices. Backblaze B2 provides free egress up to three times average monthly storage and then publishes $0.01/GB; Cloudflare R2 publishes no internet-egress charge while Class A, Class B, and Infrequent Access retrieval remain separate charges; Wasabi charges no egress fee, under a fair-use guideline tied to active storage. [6] [7] [8]
This page passes destination and volume to the separate restore estimate. It does not infer throughput from an egress price, or turn free egress into infinite bandwidth. [6] [7] [8]
A restore is read-only in this model. Retrieval, requests, temporary-copy storage, and egress can apply. Early deletion is not one of those lines: does not apply, unless another action deletes, overwrites, moves, or transitions the source. [9] [2]
| Provider rule | Effect on price | Effect on time | Source |
|---|---|---|---|
| Backblaze B2 proportional egress allowance | 3x average monthly storage, then $0.01/GB | No throughput is inferred from the allowance | [6] |
| Cloudflare R2 no internet-egress charge | Class A, Class B, and possible retrieval remain separate | No-charge egress is not unlimited restore speed | [7] |
| Wasabi fair-use guideline | No fee; regular excess can get the account limited | Policy wording is not a throughput promise | [8] |
| Read-only restore | Early deletion does not apply | No destructive action is added to the model | [9] [2] |
Sources
Every figure above comes from one of these pages, on the date shown. Each numbered reference in the text links to its entry here. Vendors change prices; if a date looks old, check the source. Three vendors publish a downloadable price feed and the rest are re-checked by hand, which is why the dates are not uniform.
Source pages checked 9 sources
- 1 Amazon S3 docs: Understanding archive retrieval options docs.aws.amazon.com · checked 27 July 2026
- 2 Azure docs: Blob rehydration from the archive tier learn.microsoft.com · checked 27 July 2026
- 3 Oracle docs: Overview of Archive Storage docs.oracle.com · checked 12 October 2026
- 4 DigitalOcean docs: Spaces limits docs.digitalocean.com · checked 27 July 2026
- 5 Vultr docs: Object Storage performance docs.vultr.com · checked 27 July 2026
- 6 Backblaze: B2 API pricing (Class A, B, C, D) www.backblaze.com · checked 27 July 2026
- 7 Cloudflare R2 docs: Pricing developers.cloudflare.com · checked 27 July 2026
- 8 Wasabi: Pay as you go pricing FAQs wasabi.com · checked 12 October 2026
- 9 Amazon S3 docs: Working with archived objects docs.aws.amazon.com · checked 27 July 2026