Restore and planning
How much backup storage your retention policy needs
Prices checked
10 TB growing 20% a year becomes 19.20 TB of stored backups by month 12 once 30 days of changed data are kept: $85.73 a month at OVHcloud Object Storage Infrequent Access.
Estimate retained capacity and its bill
Capacity through the next year
19.20 TB retained at month 12
$85.73 normal-month bill for the selected offer: $77.93 to store the data, $7.80 for downloads, requests and minimums
$933.25 paid over the next 12 months
Monthly capacity and bill
| Month | Retained TB | Monthly USD |
|---|---|---|
| 0 | 16.000 | 71.44 |
| 1 | 16.245 | 72.53 |
| 2 | 16.494 | 73.64 |
| 3 | 16.746 | 74.77 |
| 4 | 17.003 | 75.91 |
| 5 | 17.263 | 77.08 |
| 6 | 17.527 | 78.26 |
| 7 | 17.795 | 79.45 |
| 8 | 18.068 | 80.67 |
| 9 | 18.345 | 81.91 |
| 10 | 18.625 | 83.16 |
| 11 | 18.910 | 84.43 |
| 12 | 19.200 | 85.73 |
More capacity settings
The full copies you keep plus each day's changed data for the retention window. Compression and deduplication count only through the ratio you enter from your own backup tool; 1 means none is assumed. Growth is compounded to each month and held through that month's retention window. Each month's bill prices the space retained plus, for every TB of it, 100 GB downloaded, 100,000 files, 50,000 uploads and listings and 200,000 reads; with nothing stored, only a vendor's minimum charge is left.
For photo files kept by shoot, use the photographer storage budget calculator to turn shoot size, file counts and retained months into monthly and restore bills. To price the same space on drives of your own, compare your own NAS with the cloud.
A capacity model that begins with the protected workload rather than a preselected storage total. Every assumption is stated, 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 charge does to a normal month and to the month 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 a 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 |
|---|---|---|---|---|
| Protected workload | How large will the source be at each month of the next year? | Initial size, annual growth | Protected GB at months 0 to 12 | [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? | No reduction, or one combined ratio you measured | Reduced payload GB (not known until a reduction is entered) | [4] [5] |
| Object adjustment | What does the provider count as capacity? | Selected provider class; the calculator assumes 100,000 files per stored TB | Minimum-object and metadata-adjusted capacity | [6] |
| Provider bill | What does that capacity cost? | Billable capacity plus selected offer | Storage and complete monthly bill | [6] |
The model keeps growth, retained bases, and increments separate
Protected capacity at month m is the initial size multiplied by the annual growth factor raised to m / 12, so the calculator shows every month of the next year. Each month's size is then applied across the whole retention window, which is a conservative simplification: summing each day's smaller size would retain a little less when growth is positive. [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]
| Quantity | Formula | What you can change | Source |
|---|---|---|---|
| Protected at month m | initial x (1 + annual growth) ^ (m / 12) | Initial size and growth percent; months 0 to 12 are shown | [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 month m x retained full copies + retained changed data | Independent full-copy count | [3] |
| Reduced payload | gross logical x named reduction multiplier | No reduction, or your measured combined ratio | [4] [5] |
| Provider-billable capacity | Apply object minimum, metadata overhead, unit system, and capacity minimum | Provider class; 100,000 files per stored TB are assumed | [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 stating the interpretation outright. [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 not known. Run the calculator once with each basis to see both bounds; it does not pick the larger or smaller result for you. [1]
| Input example | Daily-unique interpretation | Per-recovery-point interpretation | What frequency changes | Source |
|---|---|---|---|---|
| 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 | The result is not known until you choose the basis | [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]
The calculator takes one combined ratio. Separate deduplication and compression figures can be multiplied into it only when they were measured independently: applying both to a figure your tool already reports as combined would count the savings twice. [5] [8]
| Assumptions | Default values | Formula | What you need to see | Source |
|---|---|---|---|---|
| No reduction | Combined billable ratio = 1.00 | Billable payload = gross retained logical capacity | None; this is the conservative model baseline | [1] |
| Measured combined ratio | Not set until you enter it | 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 | Not a separate field: enter their product as your ratio | Gross logical x (1 - dedup) x (1 - compression) | Independent measurements that do not already combine the two effects | [8] [5] |
Worked example: 10 TB protected becomes 19.2 TB retained
Use an illustrative 10,000 GB initial workload, 20 percent annual growth, the calculator's 12-month view, 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 except the 12-month view is an editable example input, not a claim about a typical environment. [1] [1]
Protected size at month 12 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 | Working | Daily-unique result | Per-recovery-point result | Source |
|---|---|---|---|---|
| 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 file count and sizes, class metadata, minimum capacity, and unit system | Not known until file layout and provider class are selected | Not known until file layout and provider class are selected | [6] |
File count and size can increase billable 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. We also list provider-level minimum billable capacities where vendors publish them. [6] [6]
An average object size can estimate object count only under a stated 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's bill applies the vendor's rate to each bucket rather than multiplying every byte by one archive rate. [6]
| Provider adjustment | Capacity formula | If you leave it out | Source |
|---|---|---|---|
| Minimum billable object size | Sum max(actual object bytes, class minimum bytes) | Capacity cannot be calculated when object distribution cannot be estimated | [6] [1] |
| Per-object metadata | Object count x published metadata bytes | Capacity cannot be calculated when object count is not known | [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 a stated unit label | not comparable when a conversion basis is omitted | [6] |
| Provider rule not published | No arithmetic | not published, never counted as zero | [6] |
Synthetic fulls, GFS copies, and immutability add capacity you must count yourself
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 treated 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 included by default because their amounts depend on product configuration and how the system is operated. [3] [2]
The result is a directional capacity estimate until the user replaces the examples with measured source growth, change rate, reduction, file count, and file sizes. The bill names anything still unknown instead of implying precision the inputs do not support. [7] [4]
| Outside the default chain | How to represent it | Why it is not included | Source |
|---|---|---|---|
| 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 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 | Treat the final provider capacity as 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 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 Seagate: Lyve Cloud backup calculator www.seagate.com · checked 26 July 2026
- 2 Veeam guide: Short-term retention policy helpcenter.veeam.com · checked 26 July 2026
- 3 Veeam guide: Backup copy space requirements helpcenter.veeam.com · checked 26 July 2026
- 4 restic manual: Getting information about repository data restic.readthedocs.io · checked 26 July 2026
- 5 Veeam guide: Viewing backup properties helpcenter.veeam.com · checked 26 July 2026
- 6 AWS: Amazon S3 pricing aws.amazon.com · checked 25 July 2026
- 7 Veeam ONE guide: Data change rate history helpcenter.veeam.com · checked 26 July 2026
- 8 Kopia docs: Frequently asked questions kopia.io · checked 26 July 2026
- 9 Veeam guide: Capacity tier retention policy helpcenter.veeam.com · checked 26 July 2026