A backup deduplication ratio describes what one product achieved on one set of backup data, held for one retention period. It is not a property of the product. Before a quoted ratio can size a purchase, the quote has to state the workload mix, the retention, the chain type, where the figure was measured and whether compression is folded in.
The usual response to an inflated ratio is to discount it and buy extra capacity. That works until the budget is fixed, which it usually is. The ratio is still the only figure joining protected data to raw capacity. Assume too little reduction and money goes into shelves nobody needed. Assume too much and the repository fills partway through a three year purchase. Arguing about whether a number is plausible gets nowhere. Making it testable does.
Where a deduplication ratio comes from
Deduplication finds repeated content and stores one copy of it. How much it finds depends on the data, not the product. Two estates of identical size running identical software report different ratios when one holds many near identical virtual machines built from a common template and the other holds unrelated application servers. The engine did the same work on different raw material.
Retention matters as much as content. Most of the repetition in a backup set sits across successive backups of the same machines, not within a single backup. A repository holding a few weeks of restore points has fewer copies of the same operating system files to collapse than one holding a year of monthly and yearly points. Extending retention therefore often improves the reported ratio while increasing the capacity consumed. The ratio moves in the flattering direction and the invoice moves in the other.
Five things a quoted ratio has to disclose
- Workload mix. Described by what the machines do, not how many there are. Virtual desktops, file servers, databases and media archives reduce very differently, and the proportions decide the blended result.
- Retention and restore point structure. A ratio measured across a year of weekly, monthly and yearly points cannot be compared with one measured across a fortnight of dailies.
- Chain type. Forever forward incremental, periodic active fulls and synthetic fulls each present a different pattern of repeated blocks.
- Reduction already done upstream. Backup applications typically deduplicate and compress within a job before data leaves the proxy, as Veeam's documentation on compression and deduplication describes. Repetition removed there never reaches the storage, so a storage ratio stacked on an application ratio counts the same saving twice.
- Whether compression is included. A combined reduction figure is legitimate when labeled as one and misleading when called a deduplication ratio, since the two mechanisms move independently. Compression behaves differently by workload, which is why a combined figure shifts even when deduplication does not.
Why the same backups report different ratios
One set of backups will honestly report several ratios at the same moment, because each layer measures against a different denominator. A quote rarely says which one it used.
| Where the number comes from | What it compares | What has to be stated alongside it |
|---|---|---|
| Backup job report in the backup console | Source data read against data written for that job | Whether compression is included, and whether the job is a full or an incremental |
| Repository or appliance dashboard | Logical data presented to the repository against physical capacity used | Whether the backup software had already reduced the stream before it arrived |
| Storage layer beneath the repository | Blocks written against blocks stored after its own reduction pass | Block size, and whether the scope is per volume or global across the system |
| Front end terabytes on the quote | Protected data against purchased raw capacity | Whether protection overhead, headroom and locked restore points are inside the figure |
The last row causes most disputes after delivery. Front end terabytes describe what is protected. Raw capacity describes what was bought. Between them sit deduplication, compression, the data protection scheme, reclaim behavior and immutability. Comparing usable capacity across competing quotes has to start by agreeing what each number counts. For an object storage target, the safer basis is the post reduction stream: the bytes that actually arrive and are stored, measured over a full retention cycle.
Locked restore points change the arithmetic
Immutability adds a capacity commitment that no reduction ratio captures. Restore points held under S3 Object Lock occupy capacity until the lock expires, whatever job retention says. The stored footprint of a locked repository reflects the longest lock applied rather than the shortest retention configured, and that figure belongs beside the reduction assumption in any sizing.
Turning the claim into a contract term
A ratio that arrives as marketing cannot be enforced. One with a defined input, measurement point and date can be, and the conversion takes four sentences in the purchase paperwork.
- Input: the protected set the claim applies to, by workload class and front end terabytes, measured on the estate being quoted rather than a reference estate.
- Retention: the restore point schedule, including long term points, and the chain type the jobs will use.
- Measurement point: which console reports the figure, what it counts, and on which day of the retention cycle it is read. A ratio taken the morning after an active full differs from one taken a week later.
- Consequence: what happens if the measured figure falls short once a full retention cycle has completed. Additional capacity at the original unit price is one answer. A revised sizing at no charge is another. Nothing at all is also an answer, and it is better known before signing.
Three records make the term usable. A measured baseline from the current environment, with front end terabytes by workload class and the stored footprint the repository reports, costs an afternoon. The vendor's assumption sheet behind the quote, in the vendor's own words, shows what was promised; if it cannot be supplied, that is a finding in itself. A recheck date set one full retention cycle after go live, once the first long term points exist, closes the loop. Read the same figure from the same console, record the variance either way, and reset the clock after any change to chain format, retention depth or workload mix, in the same way that sizing from measured change rate turns a growth assumption into something auditable.