Restore and planning
First byte and final byte are different clocks
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. The surface reports the published latency first, labels every computed range as a model, and says the answer cannot be estimated when the evidence cannot support a wall-clock range.
Put your own numbers through the calculator to see what this meter does to a normal month and to the day you restore.
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 explicitly defines its one-hour figure as TTFB. [1] [2] [3]
The transfer clock needs the restore volume and an evidenced 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 honest default is therefore often two lines: the vendor's availability statement, followed by a statement that final delivery cannot be estimated. A single number is allowed only when the calculator can echo every input and label the result as a model.
| Clock | What it answers | Evidence class | Correct unknown treatment | Source ref |
|---|---|---|---|---|
| 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 | Modeled 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 unknown | [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 a user-input model 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 evidenced end-to-end throughput, not for the default case.
| Line | Value | Evidence class | What it does not prove | Source ref |
|---|---|---|---|---|
| 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 | Modeled from stated user inputs | Provider sustained throughput or object-processing time | does not apply; user-input arithmetic |
| Full wall clock | cannot estimate | Explicit unknown | 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 remain visible because 100 concurrent requests do not multiply an account-level 10 GiB/hour limit into 1,000 GiB/hour.
| Input or fact | Value | Treatment | Source ref |
|---|---|---|---|
| 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 | does not apply; user-input arithmetic |
| Full-volume rehydration result | At least 80 hours at the published ceiling | Modeled lower bound, not a range | [2] |
| Final delivery | cannot estimate until download throughput and reader bandwidth are known | Explicit unknown | [2] |
Restore time never replaces the destination-aware restore receipt
A time estimate does not change the price evidence. 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 meters; Wasabi publishes a fair-use guideline tied to active storage but no per-GB overage rate. [6] [7] [8]
The time surface passes destination and volume to the separate restore receipt. It does not infer throughput from an egress price, turn free egress into infinite bandwidth, or convert Wasabi's unpublished overage into $0. [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 | Price treatment | Time treatment | Source ref |
|---|---|---|---|
| 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 boundary | Overage rate not published | 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 machine-readable feed and the rest are re-checked by hand, which is why the dates are not uniform.
The source ledger9 sources
- 1AWS documentation: Restoring objects retrieval optionsdocs.aws.amazon.com · checked 2026-07-27
- 2Microsoft Learn: Archive rehydrate overviewlearn.microsoft.com · checked 2026-07-27
- 3Oracle documentation: Archivestorageoverviewdocs.oracle.com · checked 2026-07-27
- 4DigitalOcean documentation: Limitsdocs.digitalocean.com · checked 2026-07-27
- 5Vultr documentation: Storage performance object storagedocs.vultr.com · checked 2026-07-27
- 6Backblaze: Transaction pricingwww.backblaze.com · checked 2026-07-27
- 7Cloudflare developer docs: R2 pricingdevelopers.cloudflare.com · checked 2026-07-27
- 8Wasabi: Faqwasabi.com · checked 2026-07-27
- 9AWS documentation: Archived objectsdocs.aws.amazon.com · checked 2026-07-27