Backup Capacity Calculator
Plan backup repository capacity from retention and change rate with growth assumptions, copy tiers, operational reserves and raw storage overhead.| Measure | Current | Peak | Planning meaning | Copy |
|---|---|---|---|---|
| {{ row.label }} | {{ row.current }} | {{ row.peak }} | {{ row.note }} |
| Layer | Peak contribution | Basis | Copy |
|---|---|---|---|
| {{ row.label }} | {{ row.value }} | {{ row.note }} |
{{ note.title }}
{{ note.body }}
A backup repository holds versions, not just one copy of the current dataset. Full backups, daily change points, immutable retention, archive copies, and independent tiers can turn a modest protected dataset into a much larger storage commitment.
The first distinction is between logical data and stored backup data. Logical size describes the source before compression and deduplication. A reduced full is the modeled size after those ratios. Retention then multiplies that reduced size through full copies, daily changes, archives, and separate copy tiers.
- Retained footprint
- Fulls, daily restore points, archives, and independent copy tiers after the assumed reduction ratio.
- Composite usable capacity
- Retained data plus repository overhead, safety headroom, full-build workspace, and restore scratch.
- Raw capacity target
- Usable demand expanded for the selected fill ceiling and physical parity or replication overhead.
- Current usable budget
- Optional installed usable capacity used for a gap check against modeled usable demand.
Incremental and differential change tracking do not consume capacity in the same way. An incremental point represents one day's changed data. A differential point accumulates changes since the latest full, so its average modeled age rises with the full interval. Immutability can extend the effective daily retention period when it is longer than ordinary retention.
Forecast growth compounds the source dataset over time, while compression and deduplication reduce each modeled full. Those reduction ratios deserve special care: vendor dashboards may report logical, transferred, stored, or post-deduplication bytes under different labels. A ratio measured at the wrong stage can make every later reserve look precise but wrong.
Capacity is necessary but not sufficient for recoverability. A repository that fits the model may still miss backup windows, run cleanup slowly, lose access during an incident, or fail a restore. Treat the result as a purchasing and policy estimate, then verify it with repository telemetry and restore tests.
How to Use This Tool:
Build the plan from the protected dataset and retention policy before adding operational and hardware reserves.
- Enter the Protected dataset with the correct TB, TiB, PB, or PiB unit. Changing the unit preserves the same physical quantity.
- Choose Incremental or Differential change tracking, then enter the measured Daily change rate, daily retention, full interval, and retained full-copy count.
- Set the number of Independent copy tiers and the 12, 24, 36, or 60 month Planning horizon.
- Open Advanced to replace neutral assumptions with measured growth, compression, deduplication, repository overhead, headroom, immutability, archive, workspace, fill-ceiling, and physical-encoding values.
- Enter Current usable budget when an installed-capacity comparison is needed. Then compare Composite usable with usable capacity and Raw purchase target with the raw hardware quantity being procured.
Interpreting Results:
Peak raw capacity target includes retained data, operational reserves, fill-ceiling slack, and physical encoding. Composite usable stops before fill-ceiling and encoding expansion. Comparing one of those figures with capacity reported at the other layer can double-count protection or hide a shortfall.
The Reserve ledger shows why the target grew. Retained full copies and daily restore points reflect policy; repository overhead and headroom are percentages; full-build workspace and restore scratch are operational reserves; fill slack and encoding overhead bridge usable demand to raw hardware.
- Reduction is compression ratio multiplied by deduplication ratio. Confirm it with the same storage layer and workload being planned.
- Gap vs current usable compares installed usable capacity with the modeled peak usable requirement, not the raw target.
- Footprint runway samples the start, midpoint, and end of the selected horizon. It does not identify an exact month between those checkpoints.
If the model fits, rerun it after a material change in source growth, retention, copy count, or measured reduction. If it does not fit, do not shorten retention or remove a copy tier without checking recovery, security, and compliance requirements.
Technical Details:
This is a staged capacity model. Each forecast checkpoint grows the logical dataset, applies the combined reduction ratio, builds the retained policy footprint, adds usable reserves, and finally expands usable demand into raw capacity.
Formula Core:
Logical source bytes at month m and the reduced full size are:
D0 is the starting dataset in bytes, g is annual growth percent, c is compression ratio, and d is deduplication ratio. A ratio of 1 is neutral.
Effective retention E is the greater of daily retention and immutability days. Incremental tracking uses a daily-age factor of 1. Differential tracking uses the average modeled age shown below:
I is the full-backup interval in days. For incremental tracking, set A to 1. Retained bytes across all copy tiers are:
N is retained full copies, q is daily change percent, M is monthly archive full count, and T is independent copy tiers. Repository overhead is applied to R; safety headroom is then applied to retained bytes plus repository overhead.
The usable and raw targets add the remaining reserves in order:
O is repository overhead, H is safety headroom, B is the full-build factor, x is restore scratch percent, f is usable fill ceiling percent, and P is the physical encoding factor.
Lookup Core:
| Setting | Factor | Applied to |
|---|---|---|
| Fast-clone synthetic or appliance offload | 0 | One reduced full for build workspace |
| Active full | 1.00 | One reduced full for build workspace |
| Synthetic full | 1.25 | One reduced full for build workspace |
| No added physical overhead | 1.00 | Raw-before-encoding capacity |
| Dual parity | 1.25 | Raw-before-encoding capacity |
| EC 4+2 | 1.50 | Raw-before-encoding capacity |
| EC 3+2 | 1.67 | Raw-before-encoding capacity |
| 1+2 replication | 3.00 | Raw-before-encoding capacity |
Checkpoints occur at month 0, the rounded midpoint, and the selected horizon. TB and PB are decimal; TiB and PiB are binary. Full-precision bytes flow through the model and are rounded only for display.
Limitations:
The retention and differential-age equations are a planning model, not a vendor storage simulator. They do not model backup-chain compaction, block-size effects, metadata growth, garbage collection, failed-job remnants, synthetic-full implementation details, or temporary overlap beyond the selected reserves.
Compression, deduplication, daily change, and growth are assumptions until measured on representative jobs. Capacity output does not certify backup-window throughput, immutability enforcement, offsite independence, restore time, or recoverability.
Worked Examples:
Thirty daily incrementals across two tiers
A constant 10 TiB dataset with no compression or deduplication, four retained fulls, 3% daily change, and 30 incremental days needs 40 TiB for fulls plus 9 TiB for daily points per tier. Two independent tiers therefore retain 98 TiB. With every reserve neutral, a 100% fill ceiling, and no added encoding overhead, usable and raw targets both remain 98 TiB.
References:
- Definitions of the SI units: The binary prefixes, National Institute of Standards and Technology.