Every backup appliance quote contains a deduplication assumption, and that single figure moves the capacity requirement more than anything else in the model. It is also the input with the widest legitimate range.

Where the ratio comes from

Deduplication finds repeated blocks. In backup the repetition comes from two places.

Across time. Backing up the same system every night, where most blocks are identical to yesterday. This is where the large ratios come from, and it grows with retention: thirty daily backups of slowly-changing data dedupe far better than seven.

Across systems. Fifty virtual machines from the same template share most of their operating system blocks.

Both are real. Both depend entirely on your data.

Why the headline numbers are so large

A quoted ratio of 30:1 or 50:1 usually reflects long retention of highly redundant data — virtual machines, file servers, long daily chains. The number is arithmetically true for that scenario.

Apply it to a dataset that does not have those properties and it is fiction.

What dedupes badly

Already compressed data. Images, video, audio, compressed archives, most modern database backups with compression enabled. The redundancy has already been removed.

Encrypted data. Ciphertext is designed to look random. It does not dedupe, at all. This one catches people badly, because encryption at rest is now common and often invisible to whoever is doing the sizing. An estate that encrypts its database backups will not achieve anything near the quoted ratio on that portion.

Unique data. Scientific datasets, media libraries, log archives where every day is genuinely new.

Short retention. Most of the ratio comes from the repeated daily chain. Cut retention to seven days and the ratio falls sharply.

The honest way to size

Segment the estate. For each segment, state what it is and what ratio you expect.

  • Virtualization estate, 30-day retention: high ratio, this is the best case
  • File shares: good ratio, driven by retention rather than cross-system similarity
  • Databases with native compression: modest, perhaps low single digits
  • Encrypted or media data: assume close to 1:1 and be pleasantly surprised

Then produce a blended figure with the segments visible, not a single number from a slide.

The test that settles it

Most vendors will run an assessment against a sample of your real data. Do it. It takes a few days and it replaces the most contested assumption in the quote with a measurement.

If a vendor will not, or wants to size entirely from a default, that tells you something about how the quote was produced.

Where this bites

Under-sizing on dedupe does not fail on day one. The appliance fills gradually over months as retention builds, and then you are buying an expansion shelf in year two that was not in the budget, or quietly cutting retention to fit, which is a compliance conversation nobody wants.

That delayed failure is why the assumption gets waved through. Nobody is proved wrong in the sales cycle.

The sentence to put in the document

“Sized assuming an aggregate 12:1 reduction, derived from a 30-day retention on a virtualization-dominated estate. The encrypted database segment is modelled at 2:1 separately. At an aggregate 8:1, usable capacity requirement rises by approximately 50%.”

One sentence, and the next person to read your sizing can check it.