Work out how much repository storage your backups actually need — from source size, change rate, compression, dedup and your retention policy.
8.5 TB
8.5x your source data · 31 restore points
Use the size of the live data, not the size of your current backups. If you protect several servers, total them — the maths is linear, so one figure is fine.
The share of that data which changes in a day. This is the number people guess worst, so presets are provided: file servers and document stores usually sit near 2%, mixed office data nearer 5%, an active database 10% or more. If you can measure it from one incremental, do that instead of guessing.
Enter these as savings, not ratios — a 2:1 compression ratio is a 50% saving. Leave either at 0 if your target does not do it. They are applied independently, which is optimistic when both are high, and the tool says so.
Incremental stores only what changed since yesterday. Differential stores everything changed since the last full, so it grows across the cycle but restores need only two files. Full-every-time is simplest to restore and by far the most storage.
Fill in how many daily, weekly, monthly and yearly restore points you keep — the classic grandfather-father-son shape. The result updates as you type, with the breakdown showing which part of the policy is actually consuming the space. Usually it is the monthly fulls.
Daily, weekly, monthly and yearly points are sized separately, because they behave differently: dailies are deltas, the rest are fulls. Collapsing them into one number is what makes most estimates wrong.
The two savings multiply rather than add. 50% compression plus 50% dedup leaves a quarter of the original, not nothing — a mistake that produces impossibly small estimates.
Every line shows count, size each, and subtotal, so you can see which part of the retention policy to argue about when the number comes back too big.
Storage is bought ahead of need. Apply an annual growth rate and see the repository compound, so the capacity you buy covers the plan rather than today.
The model is shown alongside the answer. A sizing figure without its assumptions is false precision, and this is a number people spend real money on.
It is arithmetic in your browser. Your data volumes, change rates and retention policy — all of which say something about your infrastructure — never leave the page.
Anyone buying storage. The question "how much do we need" has to be answered before a purchase order, and the honest answer depends on four things that interact: how much data there is, how much of it changes, how well it reduces, and how long you keep it. Change any one and the total moves substantially.
The common failure is sizing for one full copy plus a margin. That is roughly right for a single nightly full with short retention, and badly wrong for grandfather-father-son. Keeping twelve monthly fulls means twelve near-complete copies, and on a 1 TB source that is twelve terabytes before a single daily increment is counted. The breakdown here exists to make that visible early rather than at renewal.
It is also useful in reverse. If the budget is fixed, the interesting question is what retention fits inside it — and the answer is usually to cut monthly fulls rather than dailies, because the fulls dominate. Seeing the per-line subtotals makes that trade obvious.
A note for anyone comparing quotes: check whether a vendor prices on source data or on stored data. Those differ by the multiplier this tool calculates, which is frequently 5x or more, so quotes on different bases are not comparable until you convert one to the other.
A 2 TB file server, roughly 3% of it changing daily, backed up incrementally to a target doing 40% compression and 20% dedup, retained 14 daily / 4 weekly / 12 monthly / 1 yearly.
Repository: about 16.7 TB — roughly 8.4x the source data. Note that the 14 daily increments account for only 2.4% of it; the monthly fulls are where the storage goes.
What a repository typically costs relative to the data you are protecting, for an incremental schedule with 40% compression and 20% dedup. Multiply your source size by the figure in the last column for a quick sanity check before opening the calculator.
| Retention policy | Fulls kept | Daily points | Repository multiple |
|---|---|---|---|
| 2 weeks of dailies only | 1 | 14 | 0.82x |
| 30 days + 4 weekly | 4 | 30 | 2.6x |
| GFS 14 / 4 / 12 / 1 | 17 | 14 | 8.5x |
| GFS 30 / 4 / 12 / 7 | 23 | 30 | 11.76x |
| Nightly full, 30 days kept | 30 | 0 | 14.4x |
Calculated with this tool at 5% daily change, 40% compression and 20% dedup. Your figures will differ — the point is the shape: retained fulls dominate, and a full-every-night policy costs an order of magnitude more than dailies alone.
It depends far more on retention than on data size. As a rough shape: dailies alone for two weeks costs about the same as your source data, while a full grandfather-father-son policy with twelve monthly fulls costs roughly 8 to 12 times it. Multiply your source size by the figure in the table above for a first estimate, then use the calculator to adjust for your own change rate and reduction.
For file servers and document stores, 1–3% is common. Mixed office data tends toward 5%. Active databases and mail servers are often 10% or more, and media production can exceed 15%. These are starting points, not facts about your environment — if you already run backups, divide the size of one incremental by your source size and use that instead.
No, they multiply, and this trips people up constantly. 50% compression followed by 50% dedup does not eliminate your data; it leaves 25% of it (0.5 x 0.5). Be aware the two also interfere: deduplicated data has already had redundancy removed, so it compresses less well than the raw original. Treating them as independent — which this tool does, and says so — is therefore slightly optimistic when both figures are high.
Almost always retained full backups. Each weekly, monthly and yearly restore point is a near-complete copy of the data, so keeping twelve monthly points means keeping twelve copies. Daily increments are usually a rounding error by comparison. If the total is too big, cutting monthly retention moves it far more than cutting dailies.
An incremental stores what changed since the previous backup, so each one stays about the same size. A differential stores everything changed since the last FULL, so it grows through the cycle — day five holds roughly five days of change. Differentials cost more storage and buy faster, simpler restores, because recovery needs only the full plus one differential rather than the whole chain.
Enter your uncompressed source size and let the tool apply the reduction — that is the figure you can actually measure. It matters when comparing vendor quotes, because some price on source data ("protected data") and others on what lands in the repository. Those two differ by the multiplier shown here, so quotes on different bases cannot be compared directly.
No, and that makes it conservative. Products that synthesise a full from blocks already in the repository do not store a fresh complete copy per retained full, so their real requirement is lower than this estimate. The figures here assume each retained full occupies its own space, which is the safe direction to be wrong in when you are buying capacity.
Convert the result between GB, TB and PB — and between the 1024 and 1000 conventions.
Now work out how long that first full backup takes to reach the cloud.
Work out change rates and reduction percentages from raw before-and-after sizes.