The storage math nobody does before buying more disk

Your backup repository is approaching its capacity threshold. Someone gets a quote for another shelf of disks. The quote is concrete; the alternative is usually a vague claim that deduplication could save "a lot."

That is the wrong comparison.

The useful comparison is between two measured outcomes: when your current storage will require expansion, and when it would require expansion after a realistic reduction project. Then you can ask whether moving that purchase date justifies the project's cost.

A spectacular reduction ratio can have little financial value if it describes savings you already get. A modest improvement can matter if it postpones an expensive capacity increment.

Here is how to assess that before calling a vendor.

Start with the bytes you actually pay to store

Storage dashboards can report several different quantities:

• Protected source data: The current dataset being backed up.
• Logical retained data: The data represented by all retained recovery points.
• Physical consumption: The space those backups actually occupy after existing efficiencies, with accounting boundaries that vary by platform.
• Usable capacity: The storage available after protection and system reservations, rather than the raw capacity printed on the drives.

For expansion planning, physical consumption and usable capacity matter most. Logical retained data helps explain efficiency, but it is not a substitute for measuring occupied space.

Write down what each counter includes. Does "physical used" include metadata? Are snapshots counted elsewhere? Is the ratio cumulative since installation or specific to the retained backups?

The usual overall reduction ratio is:

Reduction ratio = logical bytes / physical bytes

Space reduction = 1 - (physical bytes / logical bytes)

A 4:1 ratio means the physical footprint is one-quarter of the logical size, or a 75% reduction. It does not mean you can reclaim 75% of the storage currently occupied.

Suppose 200 TB of logical backups already occupies 50 TB. A proposed configuration would store the same recovery points in 40 TB. Your additional opportunity is 10 TB, or 20% of today's physical footprint. Calculating savings against 200 TB would count benefits you already have.

Use consistent units throughout. Mixing TB and TiB can introduce an apparent discrepancy that has nothing to do with deduplication.

Why data type changes the answer

Deduplication avoids storing repeated content multiple times. Compression encodes content in fewer bytes. They address different kinds of redundancy.

That distinction explains why "mostly video" does not automatically mean "no deduplication opportunity." Identical copies of an already-compressed video may still deduplicate, even when compressing the video again accomplishes little.

The following are assessment hypotheses, not promised ratios:

Workload	What might reduce well	What can limit the opportunity
VM backups	Shared operating-system content and unchanged blocks across recovery points	High change rates, dissimilar images, or existing backup efficiencies
Database backups	Repeated pages across backups and compressible content	Native backup compression, encryption, page rewrites, and backup format
Text-heavy archives	Repeated strings and uncompressed text	Archives already packaged in compressed containers
JPEG, video, and compressed packages	Duplicate copies of identical content	Little additional compression of unique, already-compressed files
Encrypted backup streams	Opportunities available before encryption, depending on architecture	A downstream storage layer may see little usable redundancy

Inspect what reaches the storage layer, not just the source application's name. A database exporting uncompressed backups presents a different workload from the same database exporting compressed, encrypted backups. Veritas documents this interaction in its data-type guidance for deduplication sizing.

Do not disable encryption merely to improve a ratio. Evaluate whether reduction can occur at an appropriate point in the supported backup path while preserving your security requirements.

Retention matters, too. Repeated full backups can expose considerable duplication. An incremental workflow may already avoid writing much of that repeated content. Thirty daily recovery points do not necessarily mean thirty full physical copies waiting to be eliminated.

Calculate the blend, not the average ratio

An illustrative pilot produces these results:

Sample	Logical size	Measured total reduction	Resulting physical size
VM backups	60 TB	6:1	10 TB
Database backups	30 TB	2:1	15 TB
Compressed media archives	10 TB	1:1	10 TB
Total	100 TB	About 2.86:1	35 TB

These numbers are hypothetical, not benchmarks.

Averaging 6, 2, and 1 gives 3:1, which is incorrect. Calculate physical consumption for each group, add those results, and divide total logical size by total physical size.

Also check whether reported deduplication and compression ratios describe consecutive stages. You can multiply stage ratios only when their definitions and measurement boundaries support it. A total reduction figure may already include both.

For a buyer, the more useful follow-up is: how much physical space does this same dataset occupy today?

A DIY storage reclaim assessment

1. Define an equal comparison

Record the protected workloads, backup schedule, and required retention. Include immutable retention periods where applicable.

Keep those requirements constant between baseline and candidate measurements. Shortening retention may reclaim space, but it is a separate change and should not be credited to compression.

Define success before testing: for example, enough verified capacity relief to move expansion past a specified planning date while meeting existing backup and restore requirements.

2. Capture the current baseline

Export repository consumption over a representative period. Include normal backup cycles and any periodic full backups or maintenance events.

Record:

• Usable capacity and the operational threshold at which you would expand.
• Current physical consumption and peak consumption during backup processing.
• Net physical growth after normal retention expiry and reclamation.
• Existing deduplication, compression, and encryption settings.

Daily ingestion is not net growth. A repository can ingest substantial data while staying nearly flat because older recovery points expire.

Check whether unused space is actually available for reuse. In deduplicated systems, deleting a backup does not free blocks still referenced by another backup. Dell explains this distinction in its guidance on estimated cleanable space.

3. Choose a representative sample

Group workloads by backup format and reduction settings as well as application type.

Include large consumers and fast-growing workloads. Sample multiple recovery points from the same workload so the test can reveal repetition over time. Include a high-change period when practical.

Do not extrapolate from one quiet VM to an entire repository. If a workload cannot be tested, leave its projected savings at zero in the conservative case.

4. Test the proposed storage path

Use an isolated test target and copies or supported test backups. Keep production recovery points protected.

Feed the candidate configuration the same kind of backup stream it would receive in production. Compressing a folder of source files with a command-line utility can screen for compressibility, but it does not establish a backup repository's deduplication ratio.

Measure both logical input and the physical allocation attributable to the test. Include metadata and operational overhead where measurable. Compare equal retention sets, and account for reclamation timing.

Do not assume newly written backups' results apply immediately to existing data. Establish whether old backups require migration or rewriting, and what temporary capacity that would need.

5. Restore from the result

Measure backup completion time, resource use, and restore performance against your operational requirements. Restore an older recovery point as well as a recent one, and validate the recovered data.

Reduction can exchange storage consumption for processing and reconstruction work. Whether that trade is acceptable depends on the implementation and hardware.

A repository that fits but cannot support your recovery deadline has failed the assessment.

6. Build conservative and expected forecasts

Use measured physical results to estimate current reclaim and future growth separately.

Keep a margin for workload changes and imperfect sampling. Report a range rather than a ratio with false precision. Record which assumptions would invalidate the forecast, such as a new encrypted backup format or a large media archive arriving next quarter.

Turn reclaimed space into a purchase-date decision

Consider another hypothetical environment, using TB consistently:

Usable capacity:                 100 TB
Operational expansion threshold: 80 TB
Current physical usage:          70 TB
Current net physical growth:      2 TB/month

Without changes:

Months to threshold = (80 - 70) / 2 = 5 months

Suppose testing supports a reduction of current usage to 50 TB, and separately supports future net growth of 1.5 TB per month:

Months to threshold = (80 - 50) / 1.5 = 20 months

That suggests a 15-month expansion deferral, assuming the reduction is implemented promptly and growth behaves as modeled. Migration time and temporary capacity requirements can change that result.

Now suppose the project only reclaims 2 TB and leaves growth unchanged:

Months to threshold = (80 - 68) / 2 = 6 months

One additional month may have little value. It could still matter if it bridges a procurement delay, but that is a specific business case.

Do not treat a deferred purchase as permanently avoided spending. Compare costs over the same planning horizon, including project work, internal labor, any ongoing charges, and the remaining expansion purchase. If expansion still occurs within that horizon, count it.

Storage often comes in discrete purchase increments. Reclaiming 10 TB does not necessarily return the price of 10 TB; its value depends on whether it changes the purchase you must make.

Where our own product lands on this

Adaptive Compression front-ends existing backup and archive storage with managed deduplication and compression. We assess your data, implement it on hardware you already own, and hand it over. It is a one-time project scoped to your environment, starting with a free Storage Reclaim Assessment.

The case for that project should rest on additional physical capacity reclaimed and a credible change to your expansion timeline. If your existing backup system already captures most of the opportunity, the remaining savings may not justify a project.

Bring your baseline, representative workload results, and expansion threshold to the assessment. Those make the discussion about a purchase decision you can verify.

Disclosure: I work at Adaptive IP Services, a Dallas based IT and security firm.

David J. Boggs
Founder and CEO, Adaptive IP Services

Adaptive Compression