Backup repository sizing: How much storage do you need?

Sizing a backup repository starts with a deceptively simple question: How much data do you need to protect?

The answer is only the starting point. A company with 500 TB of production data may need considerably more than 500 TB of backup capacity once retention periods, daily change rates, backup frequency, data growth and immutable retention are taken into account. The amount can also change significantly depending on the backup software and data reduction technologies in use.

That makes backup repository sizing a capacity-planning exercise rather than a direct copy of production storage requirements. The goal is to understand how much backup data will accumulate over time, how long it must remain available and how much room the repository needs to operate and grow reliably.

This guide explains the major variables involved and provides a practical framework for estimating backup storage requirements.

What is backup repository sizing?

Backup repository sizing is the process of estimating the storage capacity required to hold backup data over a defined period.

Protected data volume is the foundation of the calculation, but it is rarely the final number. Backup capacity is also affected by:

• The amount of data protected
• How quickly that data changes
• How often backups run
• How long recovery points are retained
• The backup method being used
• Compression and deduplication
• Immutable retention requirements
• Expected data growth
• Additional recovery or secondary copies
• Capacity reserved for operational headroom

These variables explain why two organizations protecting the same amount of production data can have very different backup storage requirements.

A 500 TB environment with a low daily change rate and 30-day retention policy has a different capacity profile from a 500 TB environment generating large volumes of new data every day and retaining recovery points for a year.

The right question is therefore not simply, “How much production data do we have?” It is, “How much backup data will we need to retain at any given time?”

7 factors that determine backup storage capacity

A useful backup storage estimate starts by understanding the variables that cause stored backup data to accumulate.

1. Protected data volume

Protected data volume is the amount of source data included in the backup environment.

This might include virtual machines, databases, file systems, applications, user data and other workloads. It is important to distinguish total production storage capacity from the data actually protected. A 1 PB storage environment, for example, may contain unused capacity or datasets excluded from backup.

Use the amount of data that will actually be protected as the baseline for sizing.

2. Daily change rate

The daily change rate measures how much protected data is created or modified between backup cycles.

This is one of the most important variables in repository sizing because incremental backups generally store changes rather than another complete copy of every protected dataset.

If 500 TB is protected and approximately 2% changes each day, that represents roughly 10 TB of changed data before accounting for compression, deduplication or other data reduction.

A workload with a 10% change rate would produce a very different capacity requirement despite having the same initial protected capacity.

Change rates can also vary substantially between workloads. Databases, virtual machines, media repositories and general file storage should not automatically be assigned the same assumptions.

3. Backup frequency

Backup frequency determines how often new recovery points are created.

An organization taking one backup per day will generate a different amount of backup data from one protecting critical systems several times per day.

Frequency becomes especially important when backup policies vary by workload. Tier-one applications may have much more aggressive recovery point objectives than less critical systems, resulting in more recovery points and potentially greater storage consumption.

Repository sizing should therefore reflect actual protection policies rather than using one backup frequency for the entire environment.

4. Retention period

Retention determines how long backup data remains in the repository.

A 30-day policy maintains a much smaller recovery history than a 90-day, one-year or multi-year policy. Some organizations also use tiered retention policies, such as keeping daily backups for several weeks, weekly backups for several months and monthly or annual recovery points for longer periods.

Regulatory, legal and business requirements can extend retention further.

The important point is that backup capacity is cumulative. The repository must accommodate the recovery points that remain within the retention window at the same time.

5. Backup method

Backup architecture affects how much physical capacity is consumed.

Common approaches include full backups, incremental backups, synthetic full backups and combinations of these methods. Backup platforms may also apply compression, deduplication or other data reduction techniques.

As a result, logical backup volume and physical repository consumption are not necessarily the same.

When sizing a repository, use realistic assumptions based on the backup application, workload and protection policy instead of assuming a universal reduction ratio.

6. Data growth

Production environments rarely stay the same size.

If an organization is protecting 500 TB today and its data grows 20% annually, repository requirements will increase even if the backup policy itself does not change.

Growth compounds over longer planning periods:

• Today: 500 TB
• After one year at 20% growth: 600 TB
• After two years: 720 TB
• After three years: 864 TB

Sizing only for today’s environment can therefore create a repository that reaches its limits much sooner than expected.

7. Immutability and recovery requirements

Cyber resilience introduces another important consideration: some backup data may intentionally be impossible to modify or delete for a defined period.

Immutable backup retention protects recovery points from ransomware, compromised administrator credentials and accidental deletion. It also means capacity cannot simply be reclaimed whenever an administrator wants to make room.

If a recovery point must remain immutable for 30 days, the infrastructure needs enough capacity to maintain that protected window while new backups continue arriving.

Immutability does not necessarily mean that every organization needs dramatically more storage. It means retention and capacity policies need to be aligned so the repository can honor the required protection window without creating capacity pressure.

A simple backup storage sizing formula

There is no single formula that accurately models every backup architecture, but a basic estimate can help establish the scale of the requirement.

For an incremental backup model, a simplified starting point is:

Estimated backup capacity = Initial protected data + retained changed data + long-term recovery points + growth + operational headroom

For example, consider an organization with:

• 500 TB of protected data
• 2% average daily change rate
• One daily incremental backup
• 30 days of retained daily changes

The daily changed data would be approximately 500 TB × 2% = 10 TB per day. Thirty days of changed data would represent 10 TB × 30 = 300 TB.

Before considering data reduction, additional full recovery points, growth or headroom, the simplified logical requirement would therefore be approximately 500 TB + 300 TB = 800 TB.

This is deliberately a simplified example. Actual repository consumption will depend on how the backup platform stores recovery points and how effectively data can be reduced.

The useful part of the calculation is not the 800 TB figure. It is understanding which assumptions produced it.

How retention changes backup storage requirements

Retention can have a greater effect on long-term capacity than the initial full backup.

Using the same simplified example, 500 TB of protected data with a 2% daily change rate produces approximately 10 TB of changed data per day.

Ignoring data reduction and other full copies for illustration:

This does not mean every 500 TB environment requires these exact capacities. Real backup software may store data differently, and deduplication or compression can significantly alter physical consumption.

It does demonstrate why retention assumptions matter.

Organizations should also separate short-term operational recovery from long-term retention. Keeping every daily recovery point for years may be unnecessary when the actual requirement is to maintain frequent recent recovery points and a smaller number of monthly or annual copies.

Retention design and repository sizing should therefore be performed together.

How immutability affects backup capacity planning

Immutable backup storage prevents protected data from being modified or deleted until its retention period expires.

That capability has become an important part of ransomware resilience because attackers frequently target backup infrastructure in an attempt to eliminate recovery options before encrypting production systems.

From a sizing perspective, immutability makes accurate capacity planning more important.

In a conventional repository, administrators may sometimes respond to capacity pressure by deleting older backup data. That option may not exist for data still inside an immutable retention period.

Suppose an organization requires 30 days of immutable backups. The repository needs enough usable capacity to accommodate the entire active immutable window while continuing to ingest new backups.

The relationship can be thought of as:

Immutable capacity requirement = backup data entering the immutable window faster than data becomes eligible for expiration

If backup volumes increase unexpectedly, retention policies change or production data grows faster than forecast, capacity consumption can rise accordingly.

This is why immutable backup design should consider both security policy and storage economics. The objective is not to retain everything forever. It is to maintain enough protected recovery history to satisfy recovery and compliance requirements without creating an unsustainable capacity model.

Don’t forget future data growth

One of the easiest ways to undersize a backup repository is to calculate requirements from today’s protected capacity and stop there.

Consider a company protecting 1 PB of data with annual growth of 25%. Its production data could reach approximately:

• Year 1: 1.25 PB
• Year 2: 1.56 PB
• Year 3: 1.95 PB

Backup capacity requirements will generally grow alongside it.

The effect can be even larger when increased production capacity is accompanied by longer retention, additional workloads or higher backup frequency.

A useful repository sizing exercise should therefore include at least three scenarios:

• Expected growth — the organization’s most likely forecast
• High-growth case — a faster-growth scenario that tests how easily the repository can expand
• Policy-change case — the effect of extending retention or adding additional protected workloads

The goal is not to predict capacity requirements perfectly several years into the future. It is to avoid choosing an architecture that becomes difficult or expensive to expand when those forecasts inevitably change.

Raw capacity and usable capacity are not the same thing

Storage systems are often described using raw capacity, but raw capacity is not necessarily the amount available for backup data.

Capacity may be consumed by data protection mechanisms, system overhead and other architectural requirements. The amount available to applications after these factors are taken into account is the usable capacity.

Backup teams should therefore avoid comparing storage platforms solely on raw terabytes or petabytes.

Ask how much usable capacity will actually be available for backup data and how that figure changes as the system expands.

Operational headroom also matters.

Running a storage system continuously at its theoretical maximum capacity leaves little room for unexpected growth, maintenance operations or sudden increases in backup volume. Capacity planning should include a buffer rather than assuming every available byte can be consumed.

Scale-up vs. scale-out backup repositories

How a backup repository expands can be as important as its initial capacity.

A scale-up architecture generally increases capacity by adding resources to an existing storage system. This can work well within the limits of the platform, but large environments may eventually encounter hardware or architectural boundaries.

Scale-out storage distributes data across multiple nodes and allows capacity to increase by adding additional nodes to the system.

For growing backup environments, this changes the sizing question.

Instead of trying to purchase enough capacity on day one for every possible future requirement, organizations can establish an initial deployment and expand as protected data grows.

That can be particularly useful when growth is difficult to predict. Acquisitions, new applications, regulatory requirements and changing cyber-resilience policies can all alter backup capacity requirements faster than expected.

The important consideration is whether expansion can occur without creating new storage silos or requiring disruptive migrations.

How much headroom should a backup repository have?

There is no universal percentage of free capacity that is appropriate for every backup environment.

Instead, headroom should reflect how quickly the environment can consume additional storage and how quickly new capacity can be added.

An environment ingesting several terabytes of new backup data every day has less time to react to a capacity shortage than a smaller environment with relatively static data.

Teams should consider:

• Typical daily backup ingestion
• Peak ingestion periods
• Expected data growth
• Immutable data that cannot yet expire
• Time required to procure and deploy additional capacity
• Capacity required during maintenance or failure scenarios
• Unexpected changes to retention policies

A useful operational threshold should provide enough time to identify increasing consumption and add capacity before the repository becomes constrained.

This makes capacity monitoring an ongoing part of backup operations rather than a one-time calculation performed during deployment.

Questions to ask before buying backup storage

Repository sizing should ultimately help determine whether a storage architecture can support the backup environment over its expected life.

Before selecting backup storage, ask:

How much data are we protecting today?

Measure actual protected capacity rather than total production storage.

How quickly does that data change?

Use workload-specific change rates when possible.

How long do recovery points need to be retained?

Separate short-term recovery requirements from long-term retention.

How long must backups remain immutable?

Make sure the storage system can maintain the required protection window as new data arrives.

How quickly is production data growing?

Model future capacity instead of purchasing solely for today’s footprint.

What data reduction should we realistically expect?

Use measured or vendor-validated assumptions rather than idealized ratios.

How much usable capacity will the system provide?

Compare usable rather than raw storage capacity.

How does the repository expand?

Understand whether growth requires additional nodes, replacement hardware, migrations or new storage systems.

What happens when capacity begins running low?

Determine how capacity is monitored, how quickly the system can expand and whether immutable retention could restrict emergency cleanup.

Can the repository continue scaling without increasing operational complexity?

Capacity is only one dimension. Infrastructure that becomes progressively harder to operate as it grows can create its own costs.

Planning backup storage for the next three years

A practical backup capacity plan does not need to predict the future precisely. It needs to expose the variables that could materially change the requirement.

Start with current protected capacity and then model expected change rates, backup policies and retention. Apply realistic data-reduction assumptions based on the backup environment. Add forecast production growth and sufficient operational headroom.

Then test the model against less comfortable scenarios:

• What happens if data grows 30% instead of 15%?
• What happens if the organization changes its immutable retention policy from 14 days to 30 days?
• What happens if another 500 TB of workloads is brought under protection?
• What happens if regulatory requirements force certain recovery points to be retained longer?

The answers reveal something more useful than a single capacity figure: how resilient the backup architecture is to change.

A repository that is perfectly sized for today’s requirements but difficult to expand may ultimately be a poorer choice than one designed to scale as backup requirements evolve.

How ARTESCA supports scalable backup storage

Scality ARTESCA is object storage designed for backup environments where cyber resilience, scalability and operational simplicity are core requirements.

ARTESCA provides S3-compatible object storage for backup applications and supports immutable data protection designed to help preserve recovery data against ransomware and other attempts to modify or delete backups.

Its scale-out architecture allows organizations to expand storage as backup requirements increase rather than treating the initial deployment as a fixed capacity ceiling. That can help infrastructure teams accommodate growing protected datasets, changing retention policies and expanding immutable backup requirements without creating separate storage silos.

For backup repository sizing, the broader principle is simple: don’t select storage based only on the capacity you need today.

Start with the data you protect. Understand how quickly it changes. Define how long it must be retained and protected. Model growth over the expected life of the environment. Then choose a backup storage architecture capable of growing with those requirements.

That produces a much more useful answer to the question “How much backup storage do we need?” than multiplying today’s production capacity by an arbitrary number.