Capacity with the assumptions left visible

Free backup storage estimator.

Estimate capacity for growing source data, retained changes, full seeds, immutable history and independent backup destinations. The result is a planning allowance you can challenge—not a vendor quotation.

Estimate backup capacity

Editable examples

Model what you retain, not only what you protect.

Start with an example, then replace every figure with your own measurements and policy. All capacity figures use decimal GB, TB and PB.

01 Protected data and growth

Forecast the source at the end of your planning horizon. This is the protected data—not the current size of an existing backup repository.

GB
Count the used data that must be recoverable today.
GB
Use measured history or a cautious business forecast.
months
The estimate sizes the source at this future point.
%
Changed, added or deleted data each day—not total writes.
02 Backup schedule and retention

Long-term tiers are treated as additional history only after the shorter tier stops, which avoids simply counting the same recovery point twice.

runs
Used for restore-point count and approximate change per run.
days
How long the frequent recovery points remain available.
weeks
Set to zero if the policy has no weekly tier.
months
Monthly recovery points kept beyond shorter retention.
years
Check legal and business reasons before keeping data indefinitely.
fulls
Include active full or synthetic-full sets your design needs to hold.
03 Protection and storage behaviour

These assumptions can materially change the result. Confirm them with the chosen product, repository and real job statistics.

days
A longer locked window extends the effective daily hold.
copies
Capacity is multiplied; independence still needs an architecture review.
%
Use zero until you have evidence; encrypted media may reduce poorly.
%
Room for growth variance, pruning delays and operational work.

Capacity is only one part

Prove that the design can recover.

A repository can be large enough and still fail the business. Use the estimate alongside a measured restore and resilience review.

    Transparent method

    A forecast, not a magic ratio.

    The model starts with the future source size, adds full seeds and changed data for non-overlapping retention tiers, applies a stated reduction assumption, then adds reserve and independent destinations.

    Full seedsfuture source × full copiesChange historyretention without overlapReduction + reservethen destinations
    01

    Project the source

    Current protected data plus expected monthly growth over the chosen horizon.

    02

    Retain change

    Daily change feeds shorter history; weekly, monthly and yearly tiers add only their extra coverage.

    03

    Adjust carefully

    Compression and deduplication are explicit assumptions to replace with measured job statistics.

    04

    Separate copies

    Capacity is repeated per destination, while genuine independence is confirmed in the architecture.

    Official backup guidance

    Retention, changed data and recovery all matter.

    The model reflects common incremental-backup behaviour, but product support and storage billing differ. Use the linked guidance to validate policy and resilience choices.

    NCSC ransomware-resistant backup principlesSeparate control, protected deletion, restore access, monitoring and regular testing. Microsoft backup storage planningProtected instance size and retained backup growth are separate planning elements. AWS backup plans and incrementalsSupported resources begin with a full copy and then store changes; not every resource behaves this way.

    Backup capacity questions

    Know where the estimate stops.

    Is this an exact backup storage figure?

    No. It is a transparent planning allowance. Backup format, changed-block tracking, compression, deduplication, metadata, synthetic or active fulls, pruning and provider billing can all alter actual use.

    Why does the daily change rate matter so much?

    Incremental systems commonly store an initial full copy and then changed data. A small live dataset with heavy daily change can therefore need more retained capacity than a larger, mostly static archive.

    Does immutability create another backup copy?

    Not necessarily. Here it extends the effective daily hold when the immutable period is longer. The actual effect depends on repository architecture, retention locks and the backup product.

    Do several destinations automatically make a resilient backup?

    No. Copies should sit across appropriate failure and administrative boundaries. Access separation, deletion protection, monitoring and successful restore tests matter as much as the number of destinations.

    Need a backup design you can test?

    Turn the estimate into a recoverable service.

    ACA can review workloads, retention, security boundaries, connectivity and recovery objectives, then help design and operate a backup service with practical restore testing.

    Explore managed servers