Most teams using cloud backup storage have never calculated what a full-site restore would cost to pull back. The monthly storage bill is visible and stable, so it gets attention, while the read charge stays theoretical until the week it is not. The calculation is not difficult, but it does require knowing which volume moves, which operations are billed alongside the bytes, and where the published rates change.
The obstacle is usually the first input rather than the arithmetic. Teams reach for the size of the repository, which is the wrong number by a wide margin, since a repository holds months of retained history and a recovery reads a specific and much smaller subset of it. Starting from the repository size produces an estimate large enough to be dismissed as unrealistic, which is how the question gets dropped.
The opposite error is as common. Estimating only the size of the latest full ignores the incremental chain that has to be read with it, the metadata operations the restore issues, and any data read more than once because an attempt failed. A defensible figure sits between the two and is built from the recovery plan rather than from a rule of thumb.
The starting point is scope: which machines and which datasets have to come back for the site to function. That list is shorter than the protected estate in almost every environment, because some workloads can wait days and some no longer need to exist at all. Work on planning a recovery of many machines at once usually produces this list already, and if it does not exist, the estimate has no legitimate scope.
For each machine in scope, the volume is the data required to reconstruct one restore point, not the sum of every restore point retained. In a chain-based layout that means the relevant full plus every incremental between it and the chosen point, and in a layout using synthetic fulls it means the blocks the chosen point references. The distinction between those two behaviors is the subject of the tradeoff between full and incremental recovery, and it changes the read volume materially.
Two adjustments follow. Compressed and deduplicated data is stored and therefore transferred in its reduced form, so the number that moves is the stored size rather than the original size of the protected data. Against that, if the same blocks are referenced by several machines, they may be read once or many times depending on how the restore is executed, which is a question for the backup software rather than the storage provider.
Bytes leaving the provider are the largest item in most estimates but never the only one. A restore is also a long sequence of individual operations, and the structure of the bill has several places where a rate changes according to conditions set when the data was written.
| Charge | What triggers it | Where to find the rate |
|---|---|---|
| Data transfer out | Bytes leaving the provider network toward the recovery target | The provider's data transfer page, checked for the specific region and destination |
| Retrieval from a colder tier | Reading data held in an archive or infrequent access class | The storage class table, which lists retrieval separately from transfer |
| Read and list requests | Every object read, plus the listing operations a restore performs first | The request pricing section, priced per block of operations |
| Expedited retrieval | Choosing a faster option than standard for archived data | The retrieval options table, where each speed carries its own rate |
| Early deletion | Removing data before a class minimum duration has elapsed | The storage class terms, where minimum durations are stated |
| Transfer between regions or zones | A recovery target in a different location from the repository | Inter-region transfer rates, which differ from internet egress rates |
The request line is the one most often forgotten and the one hardest to guess, since it depends on how the backup software segments data into objects rather than on the volume. The object count for a given restore is usually visible in the repository, and multiplying it by the published per-operation rate is more reliable than assuming requests are negligible.
The early deletion term catches teams that copy data back and then clean up. If restored data is deleted from the cloud repository afterward, or if a temporary copy was created to stage the recovery, the minimum duration attached to the storage class may still apply.
Two recoveries moving the same volume can produce different totals because of how the read is performed. Restoring machines one at a time over several days, restoring everything in parallel, and streaming machines directly from the repository while they run all issue different numbers of operations and may draw on different retrieval options.
Running workloads directly from the repository rather than copying them down first is the clearest example. It reads far less data initially, since only the blocks a machine touches are fetched, but it keeps reading for as long as the machines run that way, and the total depends on workload behavior rather than on machine size. That is a genuinely different cost profile, not a smaller version of the same one.
Retries are the other shape effect. A restore that fails near the end and is repeated has already transferred most of the volume once, and that charge stands. Estimates therefore benefit from an explicit allowance for one partial attempt, stated as an assumption rather than folded silently into the total.
An illustrative structure helps keep these separate. If V is the volume in scope, N the object count, and the estimate uses published rates for transfer, retrieval and requests, then the total is transfer applied to V, plus retrieval applied to whatever portion of V sits in a colder class, plus the request rate applied to N, plus a stated retry allowance. The letters are placeholders, and the numbers come from the provider's own tables.
ARTESCA is object storage software used as a backup target, presenting an S3-compatible API and deployed on infrastructure the customer runs, in capacities from roughly 50 TB upward into the petabyte range. Because the platform is owned and sits on the customer's own network, reads performed during a recovery are not metered transactions, so the transfer, retrieval and request lines above do not appear.
What replaces them is a capability question. The volume still has to move, and the time it takes is determined by the platform, the network between repository and recovery target, and the concurrency the backup software is configured for. That figure is measurable in the environment rather than published, and it belongs in the recovery plan in place of the charge lines.
Where a cloud copy is retained alongside a local one, which is a common pattern for keeping a copy off site, the estimate still matters for the cloud tier. The relevant question becomes which recovery scenarios read from which copy, since a local first recovery leaves the metered copy for the cases where the site itself is gone.
A defensible estimate is one page and cites its sources. It states the scenario, the machines in scope, the volume derived from restore points rather than repository size, the object count, the storage class of the data, the retrieval option assumed, the retry allowance, and the date each published rate was read. Rates change, so the date is part of the estimate rather than a footnote.
The figure should be produced twice, once for the worst case where everything is recovered under time pressure and once for a staged recovery over a longer period, because the two answer different questions and the gap between them is the value of planning. Both belong next to the broader comparison of what a recovery costs in each storage model rather than in a separate document.
Refreshing it annually, and after any change in retention, storage class or estate size, keeps it usable. The same figure belongs in a multi-year storage budget as a contingency line rather than a forecast, since it is a cost the organization hopes never to incur but should not discover during the incident that causes it.