Backup Capacity Planner
Plan backup repository capacity across incrementals and weekly, monthly or yearly GFS copies. Enter growth, change rate, retention, data reduction and overhead. Synthetic fulls may use less physical space.
Result
| Protected data at horizon | 23.00 TB |
|---|---|
| Retained full copies | 20 |
| Raw full capacity | 460.00 TB |
| Raw incremental capacity | 16.10 TB |
| Raw logical backup data | 476.10 TB |
| After 2.0x data reduction | 238.05 TB |
| Provisioned repository | 273.76 TB (248.98 TiB) |
Model and assumptions
| Growth | Future protected data = current data x (1 + annual growth)years. |
|---|---|
| Full backups | Every retained weekly, monthly, and yearly GFS point is modeled as one independent full-size logical copy at the planning-horizon dataset size. |
| Incrementals | Each retained daily incremental is modeled as planning-horizon data x daily change rate. Change is not compounded within a chain. |
| Data reduction | Raw logical backup data is divided once by the combined deduplication/compression ratio, then overhead is added. |
Note: This is a conservative logical-capacity plan, not vendor repository accounting. Synthetic fulls, forever-forward chains, block churn, active full schedules, immutability copies, replication, metadata, dedupe scope, compression, and retention pruning differ by product. Validate with job statistics and your backup vendor's sizing tool before purchase.
Learn more
How it works
The planner grows your data to the end of the planning horizon, then counts every restore point you keep:
- Fulls: each weekly, monthly and yearly (GFS) copy counts as one full-size copy.
- Incrementals: each daily restore point holds only the data that changed that day.
The raw total is divided by your dedupe and compression ratio, then overhead is added for free space and growth. The table under the calculator spells out each assumption.
Worked example
The default is 20 TB growing 15% a year, planned 1 year out, with 5% daily change, 14 daily, 5 weekly, 12 monthly and 3 yearly restore points, a 2:1 reduction ratio and 15% overhead:
- Data in a year: 20 x 1.15 = 23 TB
- Fulls: 23 x (5 + 12 + 3) = 460 TB
- Incrementals: 23 x 0.05 x 14 = 16.1 TB
- After 2:1 reduction: 476.1 / 2 = 238.05 TB
- With 15% overhead: 273.76 TB (248.98 TiB)
This is the conservative case. If your backup software shares blocks between fulls, real use can be far lower.
Worked workflow: repository size and backup window
Use the Backup Capacity defaults: 20 TB today, 15% annual growth, one-year horizon, 5% daily change, 14 daily points, 5 weekly, 12 monthly and 3 yearly fulls, 2:1 reduction and 15% overhead. The model gives 23 TB protected at the horizon and a 273.76 TB provisioned repository.
That repository estimate is not the amount sent each night. In this example, 5% of 23 TB is 1.15 TB of changed data. Enter 1.15 TB, 1 Gbps and 85% efficiency in Transfer Time: about 3.01 hours. A 23 TB full copy at the same speed takes about 60.13 hours.
The time model does not know your backup software's actual wire bytes, changed-block behavior, source disk speed or restore performance. Use measured job statistics to replace the example inputs. Test restores separately.
Why is this so much bigger than my vendor's estimate?
Most modern backup tools use synthetic fulls or block cloning, so a new full does not store every block again. This planner counts each full as a separate copy, which gives an upper bound. Use it for budgeting, and your vendor's sizing tool for the final number.
What daily change rate should I use?
Look at the size of your recent incremental jobs divided by the total protected data. File servers are often 1% to 3% a day. Databases and mail servers are often higher.
What is GFS retention?
Grandfather-father-son: keep a set number of daily, weekly, monthly and yearly restore points. It gives long history without keeping every day forever.
Maintained by the RACKCRUNCH team. Last reviewed October 26, 2026. How we calculate | Report a problem