Backup Capacity Calculator
Plan backup repository capacity from data size, retention, change rate, copy tiers, reserves, raw overhead, and budget runway checks.{{ summaryResult.summaryTitle }}
| Metric | Value | Copy |
|---|---|---|
| {{ row.label }} | {{ row.value }} |
| Layer | Value | Note | Copy |
|---|---|---|---|
| {{ row.label }} | {{ row.value }} | {{ row.note }} |
| Checkpoint | Primary Usable | Build Reserve | Stage Reserve | Composite Usable | Gap vs Current | Composite Raw | Copy |
|---|---|---|---|---|---|---|---|
| {{ row.checkpoint }} | {{ row.primaryFootprint }} | {{ row.buildReserve }} | {{ row.stageReserve }} | {{ row.recommendedUsable }} | {{ row.gapVsCurrent }} | {{ row.recommendedRaw }} |
| Lever | Usable Delta | Raw Delta | Effect | Tradeoff | Copy |
|---|---|---|---|---|---|
|
No modeled levers remain
Current settings are already tight on modeled capacity levers; adjust retention, copy tiers, or repository assumptions to compare alternatives.
|
|||||
| {{ row.label }} | {{ row.usableDelta }} | {{ row.rawDelta }} | {{ row.effect }} | {{ row.tradeoff }} | |
| Priority | Focus | Trigger | Action | Why | Copy |
|---|---|---|---|---|---|
| {{ row.priority }} | {{ row.focus }} | {{ row.trigger }} | {{ row.action }} | {{ row.reason }} |
| Field | Value | Copy |
|---|---|---|
| {{ row.label }} | {{ row.value }} |
Backup capacity planning starts after the recovery policy is known. The question is not only how large the protected workload is today, but how many recoverable points must survive, how long older copies stay protected, and how much spare room the repository needs while new jobs keep arriving.
A source system rarely maps to a same-sized backup repository. Compression and dedupe can reduce stored bytes, while retention, archive copies, immutable locks, independent copy tiers, repository overhead, staging space, and raw-storage protection can expand the purchase target. At multi-terabyte scale, a small change in daily churn or fill ceiling can move the final answer by many terabytes.
- Change rate decides how much new data enters the chain between full backups.
- Retention shape decides which fulls, daily points, monthly archives, and yearly archives remain.
- Copy tiers multiply the retained footprint when local, offsite, immutable, or regional stores hold independent data.
- Reserve policy adds headroom for repository metadata, temporary full builds, staged cloud uploads, restore scratch, and future growth.
- Raw storage design converts usable demand into raw disk or object capacity after fill limits, parity, erasure coding, or replication.
Full, incremental, and differential backups create different space curves. A full backup stores a complete protected copy after reduction. An incremental backup stores change since the previous job, so each daily point is usually smaller. A differential backup stores cumulative change since the last full, so it grows through the cycle until the next reset. Long full intervals can look quiet on the schedule while increasing the largest landing requirement.
Retention has dependency rules as well as dates. Grandfather-father-son archives, monthly fulls, yearly fulls, and manually protected restore points can remain after ordinary daily points have expired. Immutability adds a second constraint because locked data cannot be removed early, and chain dependencies can keep older backup data around until dependent restore points are safe to expire.
A capacity estimate cannot prove recoverability. It does not show whether a restore will finish inside the recovery time objective, whether backup administrators are isolated from production administrators, or whether the offsite copy is reachable during an incident. Repository reports, a backup-window check, and a real restore drill still belong in the same planning conversation.
How to Use This Tool:
Use the calculator as a planning model for a backup repository, then compare the result against real backup reports and recovery testing. Start with measured data where possible, especially source size, daily change rate, compression, dedupe, and current usable capacity.
- Choose a Preset if one matches the environment, or leave Custom. Presets are starting points only; editing a field switches the scenario back to a custom model.
- Enter Protected dataset with the correct TB, TiB, PB, or PiB unit, then set Daily change rate and Change tracking. Use Incremental for daily changes since the previous job and Differential for cumulative changes since the last full.
- Set the restore policy with Full restore points, Daily backup retention, Full backup interval, Copy tiers, Monthly archive fulls, Yearly archive fulls, and Immutability lock. Count only independent copy tiers that store backup data.
- Open Advanced for planning assumptions: forecast horizon, procurement lead time, current usable budget, annual growth, peak daily change, compression ratio, dedupe ratio, repository overhead, safety headroom, restore scratch, fill ceiling, repository target, full build method, physical encoding, and restore test interval.
- Use Backup link throughput together with Full backup window when landing a full copy is part of the decision. A repository can have enough capacity and still miss the backup window.
- Read Capacity Target, Reserve Layers, the runway table, charts, Capacity Levers, and Capacity Action Runbook. The tables can be copied or exported when you need a planning record.
- If a field was pasted or entered at an extreme value, check Input Snapshot before sharing results. Numeric fields are bounded, and the snapshot shows the values actually used.
Interpreting Results:
Recommended composite raw capacity is the headline number when the storage quote or appliance size is expressed as raw disk, raw erasure-coded capacity, or replicated physical capacity. Recommended composite usable budget is the repository-facing number before the fill ceiling and physical encoding factor are applied.
The source-to-raw envelope under the summary is a quick scale check. Source is the protected logical data, Retained is the retained backup footprint across configured tiers, Usable adds repository overhead and working reserves, and Raw adds fill slack plus storage protection overhead.
Peak checkpoint reports the largest modeled capacity point inside the forecast, which may occur before the final month when full builds, archive overlap, or staging reserve create a temporary high-water mark. Next storage action by subtracts procurement lead time from that checkpoint so the result can be used as an expansion trigger instead of only a size estimate.
Reserve Layers explains why the target grew. Large values in Archive overlap, Extra copy tiers, Temporary build reserve, Stage reserve, Restore scratch reserve, Fill ceiling slack, or Physical encoding overhead point to different corrective actions.
Capacity Levers compares a few single-policy changes against the current scenario. Treat those rows as review prompts, not automatic recommendations. Reducing copy tiers or shortening retention may save raw capacity, but it can also reduce resilience, rollback depth, or regulatory coverage.
A low Retention pressure score does not prove recovery health. It only means the modeled capacity pressure is low. Restore testing, backup security, offsite reachability, and administrative isolation still need separate evidence.
Technical Details:
The capacity path begins with logical source bytes and a reduction ratio. Compression and dedupe reduce the stored size of fulls and deltas, but those ratios are planning assumptions until real backup jobs prove them. Some products report logical, transferred, stored, and deduplicated bytes differently, so the ratio entered here should match the storage layer being sized.
The forecast walks through the retention policy day by day. Source data can grow over the forecast, full backups land on the configured interval, daily copies are stored as incremental or differential data, and monthly or yearly archives are retained as additional full copies. The result reports the peak inside the forecast rather than assuming the final month is always worst.
Formula Core:
Annual growth is compounded into a daily growth factor, so later fulls, deltas, archive copies, and reserves are sized from the grown dataset. Peak daily change affects the largest expected transfer and backup-window check even when average daily change controls ordinary retention growth.
| Mode or policy | Capacity behavior | Watch for |
|---|---|---|
| Incremental | Daily copies store change since the previous backup job. | Long chains can be operationally dense even when space use is efficient. |
| Differential | Daily copies accumulate change since the last full backup. | Large differentials when the full interval is long or change rate spikes. |
| Archive fulls | Monthly and yearly fulls stack on top of the working chain. | Archive overlap becoming the dominant peak driver. |
| Immutability | Locked restore points cannot expire until the lock and chain dependency allow removal. | Effective retention becoming longer than the visible daily setting. |
| Copy tiers | Independent local, offsite, immutable, or regional stores multiply retained bytes. | Counting metadata-only catalogs as full copy tiers, which overstates capacity. |
| Physical encoding profile | Planning meaning | Raw factor |
|---|---|---|
| No extra parity / already protected elsewhere | Usable and raw are treated the same after fill-ceiling slack. | 1.00x |
| Dual parity / RAID6-like | Raw capacity includes parity-style overhead below the repository. | 1.25x |
| EC 4+2 | Four data fragments plus two parity fragments. | 1.50x |
| EC 3+2 | Three data fragments plus two parity fragments. | 1.67x |
| 1+2 replicated / mirrored copies | Three physical copies underneath usable storage. | 3.00x |
The chain manageability warning uses a common 10 TB single-chain guide as a practical threshold. It is not a universal product limit. The point is to flag when one monolithic working chain may become harder to move, verify, seed, or recover from than several smaller jobs or a tighter full cadence.
Limitations, Accuracy, and Privacy:
The calculation runs from the values entered on the page. It does not connect to a backup product, repository, cloud account, or billing system, so it cannot verify real compression, dedupe, chain deletion behavior, failed job cleanup, provider minimum retention, or actual object-lock state.
Capacity numbers should be treated as planning targets, not recovery guarantees. A repository with enough space can still fail a recovery objective because the restore path is slow, the backup account is compromised, the offsite copy is unreachable, or no one has tested the runbook.
Settings can appear in the page URL when scenarios are shared or bookmarked. Avoid putting confidential asset counts, customer names, exact capacity budgets, or sensitive recovery assumptions into a URL that will be pasted into tickets, chat, or public documentation.
Use decimal and binary units deliberately. TB and PB are decimal storage units based on powers of 1000, while TiB and PiB are binary units based on powers of 1024. Mixing them can create visible differences at backup scale.
Worked Examples:
Balanced production repository with an 80 TiB current budget. A 12 TiB source dataset, 3% average daily change, 5% peak daily change, incremental mode, four retained fulls, 30 daily restore points, weekly fulls, two copy tiers, 20% annual growth, 1.7:1 compression, 1.6:1 dedupe, 12% repository overhead, 20% safety headroom, 10% restore scratch, 14 days of immutability, six monthly archive fulls, two yearly archive fulls, and an 80% fill ceiling produces a recommended usable budget near 166.14 TiB and a raw target near 207.67 TiB. With 80 TiB already available, the budget runway crosses demand around Month 2, and the full-window check calls for about 1,617 Mbps against an 8-hour target.
Compliance archive with long retention. A 12 TiB dataset with 2% average change, differential mode, six retained fulls, 45 daily points, a 14-day full reset, three copy tiers, staged cloud gateway uploads, 24 monthly archive fulls, seven yearly archive fulls, 30 days of immutability, 18% annual growth, 2.2:1 compression, 2:1 dedupe, EC 3+2 physical encoding, and a 75% fill ceiling reaches a raw target around 1.32 PiB over a 24-month horizon. The top modeled saving is usually one fewer copy tier, but that tradeoff only makes sense if another protected copy path remains.
Enough storage, failed backup window. An 80 TiB source dataset with weekly fulls, 21 days of incrementals, 4% daily change, 1.4:1 compression, 1.2:1 dedupe, dual-parity raw overhead, and an 80% fill ceiling can show a raw capacity target near 377.14 TiB. At 1000 Mbps, the largest full takes about 4d 20.4h, so an 8-hour full window would need about 14,544 Mbps. That is a throughput and scheduling problem, not only a capacity purchase problem.
FAQ:
Why is the raw target higher than the usable budget?
The usable budget is divided by the fill ceiling before raw protection is applied. An 80% fill ceiling keeps 20% slack, and parity, erasure coding, or replication can multiply the raw target again.
Should I choose incremental or differential mode?
Choose Incremental when daily backups store change since the previous job. Choose Differential when each daily point stores all change since the last full. Differential mode is easier to reason about in some restore designs, but it can grow quickly between full resets.
Why can immutability increase capacity?
Locked restore points cannot expire early. If the lock period or chain dependency extends beyond the ordinary retention setting, the effective retained footprint can be larger than the nominal daily retention window suggests.
How should I choose compression and dedupe ratios?
Use measured backup reports from a similar workload when available. Conservative ratios are safer for purchase planning because encrypted, compressed, media-heavy, or already deduplicated data may not reduce much further.
Does the estimate replace a restore test?
No. The estimate sizes capacity and highlights runway, windows, and reserves. A restore test proves whether selected recovery points can actually be restored, how long the process takes, and whether people and permissions are ready.
Glossary:
- Backup repository
- The storage location that holds backup data, metadata, and restore points.
- Restore point
- A recoverable point in time, usually represented by a full backup plus related incremental or differential data.
- Full backup
- A complete stored copy of the protected dataset at a point in time.
- Incremental backup
- A backup that stores changes since the previous backup job.
- Differential backup
- A backup that stores all changes since the last full backup.
- GFS retention
- Grandfather-father-son retention, where selected daily, weekly, monthly, or yearly points are kept for longer periods.
- Immutability
- A protection period during which backup data cannot be deleted or modified through normal expiration.
- Copy tier
- An independent storage copy, such as local, offsite, immutable, or regional backup storage.
- Usable fill ceiling
- The planned maximum fill percentage before expansion or cleanup is considered due.
- Physical encoding
- The parity, erasure-coding, or replication overhead that converts usable demand into raw capacity.
References:
- Backup repositories, Veeam Backup & Replication Best Practice Guide.
- Keeping Recovery Points, NAKIVO Help Center.
- Comparison of Backup Repository Types, NAKIVO Help Center.
- Secure and encrypt backups, AWS Well-Architected Framework.
- Restore testing, AWS Backup Developer Guide.
- Contingency Planning Guide for Federal Information Systems, NIST SP 800-34 Rev. 1.
- Prefixes for binary multiples, NIST Reference on Constants, Units, and Uncertainty.