Free tools · Backup

Backup storage calculator: how much space do your backups and retention need?

Enter how much data you protect, how fast it changes and how long you keep restore points. The calculator shows the storage each copy needs today and for the next three years, with the formula written out, and an optional cloud bill at public list prices. It is vendor-neutral, needs no sign-up, and every default is either cited below or marked as an assumption to change.

Prices and sources last checked: 16 October 2026. The calculator runs in your browser and sends nothing anywhere.

Disclosure: the author works in the data protection industry. This tool is independent: no vendor paid for it, reviewed it or supplied data for it, and it uses only publicly available information and list prices.

Your data
Backups and retention
Data reduction
Copies (3-2-1)

How to read the result

  • Backup storage now is the usable capacity all your copies need on the day the oldest restore point you keep is created. Provision headroom on top of it: a repository that fills up stops taking backups.
  • The table splits that into each copy (local, offsite, a separate immutable copy) and grows it with your data for three years. Use the year that matches your hardware or contract term.
  • Storage per TB protected is the quickest sense check. The worked example below comes to 4.7x. If yours is far higher, check the working set, the "storage handles repeated data" setting and the number of long-term points.
  • The cloud line is storage at list price only. Add requests, restores and any minimum-duration charges before you put it in a budget.

How is backup storage calculated?

A backup copy holds two kinds of restore point: a chain of daily points, and long-term points kept for weeks, months or years (the grandfather-father-son, or GFS, scheme). The calculator works out the raw size of each, then divides by data reduction.

  1. Daily chain, incremental forever. One full backup plus one incremental for every other day: size + (daily points - 1) x size x change rate. Synthetic fulls are built from data already in the repository, so they add nothing new.
  2. Daily chain, weekly full. A chain (a full and its six incrementals) can only be deleted when its newest point expires, so up to six extra days are kept: days kept = daily points + 6, fulls = days kept / 7 rounded up, and the rest are incrementals. On storage that cannot share blocks, every full is the whole data set again; on block-cloning or dedup storage a later full only adds that day's changes.
  3. Long-term points. Without block sharing, each weekly, monthly or yearly point is a full copy. With it, a point only stores the blocks that changed since the previous one. If changes land at random inside a working set (the share of data that ever changes), the unique data after d days is size x working set x (1 - (1 - change rate / working set)^d), using 7 days for weekly points, 30 for monthly and 365 for yearly.
  4. Data reduction. The raw total is divided by compression x dedup.
  5. Immutability. An immutable copy cannot delete a point until its lock expires, so its daily chain holds max(daily points, immutability days) points.
  6. Growth. Year n repeats every step with size x (1 + growth)^n.

The result card prints these sums with your numbers in them, so you can check any figure by hand.

Worked example: 10 TB with a 3-2-1 policy

A business protects 10 TB that changes 3 percent a day (Microsoft's "moderate" churn), concentrated in a working set of a quarter of the data. It runs incremental-forever backups to block-cloning storage, keeps 14 daily points locally, and sends an immutable copy offsite with 14 daily, 4 weekly, 12 monthly and 1 yearly point and a 30-day lock. Compression is 1.5:1 and there is no extra dedup. These are the calculator's defaults.

  • Local copy: 10 TB + 13 x 0.3 TB = 13.9 TB raw, / 1.5 = 9.27 TB.
  • Offsite daily chain: the 30-day lock keeps 30 daily points: 10 TB + 29 x 0.3 TB = 18.7 TB raw.
  • Offsite long-term points: the working set is 2.5 TB and 12 percent of it changes a day. A weekly point stores 2.5 x (1 - 0.88^7) = 1.48 TB, a monthly point 2.5 x (1 - 0.88^30) = 2.45 TB, and the yearly point the whole 2.5 TB. That is 4 x 1.48 + 12 x 2.45 + 2.5 = 37.8 TB raw.
  • Offsite copy: (18.7 + 37.8) / 1.5 = 37.6 TB.
  • Total: about 46.9 TB today, 4.7 times the protected data. At 20 percent growth it reaches about 81 TB in year 3.
  • Cloud cost: the 37.6 TB offsite copy at Amazon S3 Standard-IA's list price of $12.50 per TB-month is about $471 a month in storage alone.

Two settings move this the most. On storage that cannot share blocks, every long-term point is a full 10 TB copy and the total rises to about 135 TB. With a working set of 100 percent (changes spread across all the data) it is about 81 TB.

Assumptions and data

Every default and price in the calculator comes from the table below, checked on . Where no neutral public figure exists, the row says it is an assumption: change it to match your own backup reports.

ItemValueSource

What are the calculator's limitations?

  • Change is not random. Real systems rewrite some blocks every day (logs, databases, swap) and never touch others. The working-set setting approximates that; your backup software's job reports give the real daily change.
  • Product behaviour differs. Some products add metadata, keep extra points around a GFS boundary, or extend object-lock periods to protect blocks shared between points. Treat the result as a planning estimate and use your vendor's own tool for the final quote.
  • Minimum storage durations. Cool, cold and archive tiers bill deleted objects for a minimum period (30 to 180 days). Incremental-forever chains that merge or delete daily are a poor fit for the 90 and 180 day tiers.
  • Cloud prices are list prices in USD for one US region, first capacity tier, on the date shown. Other regions, committed-use discounts, requests and egress change the bill.
  • Not covered: backup of the backup server itself, transaction log backups, snapshots on primary storage, and replicas used for failover rather than restore.

Frequently asked questions

How do I calculate backup storage size?

Add one full backup to the daily incrementals you keep (full size x daily change rate x number of incrementals), add your weekly, monthly and yearly points, then divide by compression and deduplication. On storage that cannot share blocks each long-term point is a full copy; on block-cloning, dedup or object storage it only stores what changed since the previous point. Repeat for every copy you keep under the 3-2-1 rule.

How much backup storage do I need for 10 TB of data?

With 3 percent daily change, 14 daily points locally, an immutable offsite copy with 4 weekly, 12 monthly and 1 yearly point, and 1.5:1 compression, about 47 TB across both copies today, or about 81 TB after three years of 20 percent growth. Without block cloning or dedup the same policy needs about 135 TB, because every long-term point is a full copy.

Is there a free, vendor-neutral alternative to vendor backup sizing tools?

Yes, this one. The sizing calculators from backup vendors such as Veeam, Rubrik and Commvault are built around their own products, and several sit behind a sign-up form or a partner portal. This calculator uses only public figures, shows the formula, and needs no account. Use it to plan and sanity-check, then confirm the final figure with your vendor's tool.

What daily change rate should I use for backup sizing?

Use the average daily incremental size from your backup reports divided by the protected size. Without reports, Microsoft's Azure Backup pricing guide suggests 1 percent for low churn, 3 percent for moderate and 5 percent for high, with file servers at low to moderate and databases at high.

How does an immutable backup copy change the storage needed?

An immutable copy cannot delete a restore point until its lock expires, so if the lock is longer than your daily retention, the copy keeps one point per day for the whole lock period. A 30-day lock with 14-day retention keeps 30 daily points. A separate immutable third copy adds a full set of points on top.

Why do vendors quote 10:1 or 20:1 deduplication ratios?

Those ratios count the repeated data in many full backups of the same systems. A study of more than 10,000 production backup appliances (Wallace et al., USENIX FAST 2012) found a mean of 10.9x and a median of 8.7x, most of it from repeated fulls. This calculator models repeated data across restore points directly, so enter only the duplication inside a single backup, usually 1.0 to 1.5, or it will be counted twice.

Sources

Related

Changelog

  • 16 October 2026: first release. Prices checked on 16 October 2026.