Restore and planning
How much backup capacity a retention policy really creates
A capacity model that begins with the protected workload rather than a preselected storage total. Every assumption is visible and editable, recovery-point frequency is separated from unique daily change, and deduplication or compression never receives a universal default ratio.
Put your own numbers through the calculator to see what this meter does to a normal month and to the day you restore.
Protected data is the input; stored capacity is the result
Backup buyers normally know the size of the protected workload, expected growth, daily change, recovery-point schedule, and retention policy before they know cloud capacity. Seagate's backup calculator asks for initial full size, retention, annual growth, daily change, recovery points per day, and object chunk size, which are the same upstream variables this model exposes. [1]
The first output is retained logical capacity: the bases and changed data that the policy keeps. The second is reduced payload capacity after an explicit no-reduction, measured-combined, or custom-separate assumption. The third is provider-billable capacity after minimum object size, per-object metadata, minimum account capacity, and the provider's GB or GiB unit are applied. [6]
Storage price is deliberately downstream. Pricing a user-entered 10 TB without deriving whether the policy creates 6 TB, 19 TB, or 40 TB of billable objects skips the job named by the domain. [1] [3]
| Stage | Question answered | Required inputs | Output | Source ref |
|---|---|---|---|---|
| Protected workload | How large will the source be at the planning horizon? | Initial size, annual growth, horizon | Protected GB at horizon | [1] |
| Retention | How much base and changed data remains? | Change rate, change-rate basis, points per day, retention, full-copy count | Gross retained logical GB | [1] [2] [3] |
| Reduction | How much unique compressed payload is actually written? | Named assumption set and measured or custom values | Reduced payload GB or unknown | [4] [5] |
| Object adjustment | What does the provider meter as capacity? | Object count or chunk size, selected provider class | Minimum-object and metadata-adjusted capacity | [6] |
| Provider receipt | What does that capacity cost? | Billable capacity plus selected offer | Storage and complete monthly receipt | [6] |
The model keeps growth, retained bases, and increments separate
Protected capacity at the horizon is initial size multiplied by the annual growth factor raised to horizon days divided by 365. The default growth method then applies that horizon size across the retention window, which is visible as a conservative simplification. An editable daily-compounded option instead sums each day's smaller or larger protected size. [1]
Gross retained logical capacity is retained full bases plus retained changed data. The model defaults to one base because adding weekly, monthly, or yearly independent fulls without an input would fabricate a backup chain. Veeam's capacity guidance separately counts full copies and incremental restore points, so the full-copy count remains editable. [3]
Reduction comes after logical retention. Provider object rules come after reduction because a backup tool can pack or deduplicate data before writing objects. The final output keeps metadata capacity separate when a provider bills metadata at another class rate. [6]
| Derived value | Formula | Editable assumption | Source ref |
|---|---|---|---|
| Protected at horizon | initial x (1 + annual growth) ^ (horizon days / 365) | Growth percent, horizon, growth method | [1] [1] |
| Retained recovery points | points per day x retention days | Frequency and retention | [1] [2] |
| Retained changed data | protected size x daily change x retention days x change-frequency factor | Daily-unique or per-recovery-point basis | [7] [1] |
| Gross retained logical capacity | protected at horizon x retained full copies + retained changed data | Independent full-copy count | [3] |
| Reduced payload | gross logical x named reduction multiplier | No reduction, measured combined, or custom separate | [4] [5] |
| Provider-billable capacity | Apply object minimum, metadata overhead, unit system, and capacity minimum | Object shape and provider class | [6] |
Four recovery points do not automatically mean four times the changed bytes
A daily change rate often describes total change observed across a day. Under the daily-unique interpretation, four recovery points divide that day's changed bytes among four snapshots, so frequency changes point count and request shape without multiplying logical changed capacity. Veeam's change-rate reporting exposes average change per day, which supports keeping this interpretation explicit. [7]
Some operators instead measure change between every recovery point. Under the per-recovery-point interpretation, the entered percentage applies four times per day and capacity grows with frequency. Neither meaning is universal, so the input asks which one the user measured. [1]
If the source measurement cannot distinguish unique daily churn from repeated rewrites of the same blocks, the change-rate basis is unknown. The calculator can show both bounds but must not silently select the larger or smaller result. [1]
| Input example | Daily-unique interpretation | Per-recovery-point interpretation | What frequency changes | Source ref |
|---|---|---|---|---|
| 12,000 GB protected, 2% change, 4 points/day | 12,000 x 2% = 240 GB changed per day | 12,000 x 2% x 4 = 960 GB changed per day | 120 retained points over 30 days in both cases | [1] |
| 30-day retained changes | 240 GB x 30 = 7,200 GB | 960 GB x 30 = 28,800 GB | Capacity differs by the stated measurement basis | [1] |
| Basis is not known | Lower model bound: 7,200 GB | Upper model bound: 28,800 GB | Result state remains unknown until the basis is selected | [1] |
Deduplication and compression begin as measurements, not promises
No universal deduplication or compression ratio is published on this page. Workload content, encryption order, chunking, retention overlap, tool design, and repository history can change the result, so the safe default is the named no-reduction set with a 1.00 billable multiplier. That multiplier is a conservative model definition, not a claim that tools fail to reduce data. [4] [8]
The preferred assumption is the measured combined ratio. Restic's stats command distinguishes restore-size from raw-data stored in repository blobs, while Veeam displays data size before and backup size after compression and deduplication. Dividing the observed stored measure by the matching logical measure produces a workload-specific combined multiplier. [4] [5]
Custom separate reductions stay blank until the user supplies them. Applying a deduplication reduction and then a compression reduction to a combined tool-reported ratio would double count savings, so the model allows either one measured combined multiplier or two independently supported reductions, never both. [5] [8]
| Named assumption set | Default values | Formula | Evidence required | Source ref |
|---|---|---|---|---|
| No reduction | Combined billable ratio = 1.00 | Billable payload = gross retained logical capacity | None; this is the conservative model baseline | [1] |
| Measured combined ratio | unknown until entered | Billable payload = gross logical x observed repository bytes / observed logical bytes | Matching tool statistics from the intended workload and retention set | [4] [5] |
| Custom separate reductions | Dedup reduction unknown; compression reduction unknown | Gross logical x (1 - dedup) x (1 - compression) | Independent measurements that do not already combine the two effects | [8] [5] |
A visible example turns 10 TB protected into 19.2 TB retained
Use an illustrative 10,000 GB initial workload, 20 percent annual growth, a 365-day horizon, 2 percent total unique daily change, four recovery points per day, 30-day retention, one retained full base, and the no-reduction assumption. Every number is an editable example input, not a claim about a typical environment. [1] [1]
Protected size at the horizon is 10,000 x 1.20 = 12,000 GB. Daily unique change is 12,000 x 2 percent = 240 GB, retained changed data is 240 x 30 = 7,200 GB, and gross retained capacity is one 12,000 GB base plus 7,200 GB of changes, or 19,200 GB. [1]
Four recovery points per day create 120 retained points but do not multiply the 240 GB daily-unique change. Selecting the per-recovery-point interpretation instead changes retained data to 12,000 + 28,800 = 40,800 GB. The capacity result therefore names the interpretation next to the number. [1]
| Line | Visible arithmetic | Daily-unique result | Per-recovery-point result | Source ref |
|---|---|---|---|---|
| Protected at one year | 10,000 GB x (1 + 20%) ^ (365 / 365) | 12,000 GB | 12,000 GB | [1] |
| Retained recovery points | 4 per day x 30 days | 120 points | 120 points | [1] [2] |
| Changed data per day | 12,000 GB x 2% x frequency factor | 240 GB | 960 GB | [1] |
| Retained changed data | Changed GB per day x 30 days | 7,200 GB | 28,800 GB | [1] |
| Gross retained logical | One 12,000 GB base + retained changes | 19,200 GB | 40,800 GB | [1] |
| Reduced payload under the no-reduction assumption | Gross logical x 1.00 | 19,200 GB | 40,800 GB | [1] |
| Provider-billable capacity | Apply object shape, class metadata, capacity minimum, and unit system | unknown until object shape and provider class are selected | unknown until object shape and provider class are selected | [6] |
Object shape converts reduced payload into metered capacity
Reduced payload is not always provider-billable capacity. S3 Glacier Instant Retrieval bills at least 128 KB per object, while Glacier Flexible Retrieval and Deep Archive add 40 KB of metadata per archived object. The dataset also records provider-level minimum billable capacities where vendors publish them. [6] [6]
An average object size can estimate object count only under a visible uniform-object assumption. Heterogeneous repositories should enter an observed object count or size histogram because the exact minimum-object formula is the sum of max(actual object size, class minimum) across objects. [1]
Metadata that is billed at another storage rate remains a separate output bucket. The calculator may show total represented capacity for planning, but the provider receipt applies the source dataset's rate to each bucket rather than multiplying every byte by one archive rate. [6]
| Provider adjustment | Capacity formula | Missing-input behavior | Source ref |
|---|---|---|---|
| Minimum billable object size | Sum max(actual object bytes, class minimum bytes) | unknown when object distribution cannot be estimated | [6] [1] |
| Per-object metadata | Object count x published metadata bytes | unknown when object count is unknown | [6] [6] |
| Minimum billable capacity | max(adjusted capacity, provider minimum) | does not apply when the provider publishes no minimum | [6] |
| GB versus GiB | Retain the provider's unit and convert only with an explicit unit label | not comparable when a conversion basis is omitted | [6] |
| Unknown provider rule | No arithmetic | unknown or not published, never zero | [6] |
Synthetic fulls, GFS copies, and immutability need explicit additions
The default model retains one full base plus rolling incrementals. Weekly, monthly, yearly, active-full, synthetic-full, or GFS policies can retain additional full copies, and Veeam's capacity guidance counts those fulls separately. Each additional retained full copy has to be counted, or the schedule modelled as a separate retained chain, because the default model does not add them for you. [3]
Temporary merge workspace, immutable blocks held beyond normal retention, failed-retention cleanup, replicas, and provider-side versions can all increase real capacity. Those are not silently included because their amounts depend on product configuration and operating state. [3] [2]
The result is a directional capacity estimate until the user swaps illustrative defaults for measured source growth, change rate, reduction, and object shape. The receipt names any remaining unknown instead of implying precision the inputs do not support. [7] [4]
| Outside the default chain | How to represent it | Why it is not assumed | Source ref |
|---|---|---|---|
| Weekly, monthly, yearly, or active fulls | Count each additional retained full copy, or model a separate retained chain | Schedules differ by policy | [3] |
| Merge or transformation workspace | Add explicit temporary workspace capacity | Veeam notes an extra full can exist during processing | [3] |
| Immutability beyond ordinary retention | Extend effective retention for immutable data | Deletion can wait until the immutability period ends | [2] |
| Provider versioning or replication | Add observed retained bytes as a separate chain | No universal relationship to source capacity | [1] |
| Unmeasured reduction or object layout | Keep the final provider capacity unknown and show the unreduced logical result | Unknown is not zero | [4] [6] |
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
- 1Seagate: Cloud backup tco calculatorwww.seagate.com · checked 2026-07-26
- 2Veeam help centre: Retention policyhelpcenter.veeam.com · checked 2026-07-26
- 3Veeam help centre: Backup copy space requirementshelpcenter.veeam.com · checked 2026-07-26
- 4restic documentation: Manual restrestic.readthedocs.io · checked 2026-07-26
- 5Veeam help centre: View backup copy propertieshelpcenter.veeam.com · checked 2026-07-26
- 6Amazon Web Services: S3 pricingaws.amazon.com · checked 2026-07-25T15:34:44Z
- 7Veeam help centre: Vm change rate historyhelpcenter.veeam.com · checked 2026-07-26
- 8Kopia: Faqskopia.io · checked 2026-07-26
- 9Veeam help centre: Capacity tier retentionhelpcenter.veeam.com · checked 2026-07-26