## TL;DR
Find the job and day the ratio changed, then compare it with what changed on the source that week: new encryption, compression, database reindexing, or a workload that rewrites whole files will defeat block deduplication overnight. Do not buy storage first. Isolate the offending job, restore its dedupe friendliness where you can, and only then re-baseline capacity.

```text
deduplication ratio drops suddenly backup storage fills
```

## Use this when
- Repository free space falls far faster than source data is growing.
- Dedupe ratio drops from a stable level, for example 4 to 1 down toward 1.2 to 1, within days.
- One job or one client accounts for most of the new unique blocks.

## Not for this skill when
- Storage fills because retention was lengthened or a new system was added on purpose. That is planned growth, not a ratio fault.
- The repository file system itself reports corruption. Run repository integrity checks first.

## Steps
1. Pull daily repository size, unique data written, and ratio per job for the last 30 days and find the first day the ratio moved. Verify: you can name the job, the client, and the date where the curve breaks
2. For that job, list source side changes in the same window: application upgrades, encryption turned on, compression turned on, database maintenance, antivirus scanning that touches files, and any migration between hosts. Verify: each candidate change is dated and can be matched or ruled out against the break date
3. Run a small controlled test: back up the same data set twice with no changes and confirm the second run adds near zero unique blocks. Then change one file in a typical way for that workload and measure again. Verify: unchanged data dedupes, which proves the engine works and the data pattern is the problem
4. Check alignment and block size settings after any restore, migration, or product upgrade. A shifted offset or a changed chunk size makes every block look new even when file contents are identical. Verify: block size and any seeding or repository format settings match the pre-drop configuration
5. Look for encrypted or pre-compressed sources, such as encrypted database backups, compressed video, or application level encryption, which produce unique blocks on every run by design. Verify: those sources are listed separately with an expected ratio near 1 to 1
6. Re-baseline retention and capacity using the new real ratio, expire or archive the bloated restore points created during the bad window where policy allows, and alert on ratio change, not just free space. Verify: the forecast to full uses the measured ratio and an alert fires on a test threshold

## Why it happens
Deduplication only saves space when the same data produces the same blocks in the same alignment. Anything that rewrites data changes the block stream: encryption produces different ciphertext each run even for identical plaintext, especially with changing initialization values; compression at the source destroys repeated patterns before the backup engine sees them; database reindex and defragmentation jobs rewrite pages in a new order; and file level moves to a new host can shift offsets so identical content lands in different blocks. A product upgrade that changes the default chunk size has the same effect across every job at once. The ratio therefore drops suddenly even though the backup job reports success and the source data volume barely moved, and the repository fills at the undeduped rate until the pattern is fixed.

## Variants and edge cases
### ratio drop after enabling database encryption
Transparent or backup level encryption makes each nightly database dump unique. Either dedupe before encryption inside the database backup tool, accept a near 1 to 1 ratio for that job and size it separately, or move that workload to its own repository so it does not distort reporting for the rest.
### ratio drop after a storage migration
Migrated or reseeded repositories can lose their block map or start with a different chunk size, so the first weeks look like a ratio collapse. Compare against a seeded test restore, check that the migration preserved the dedupe index, and do not judge the ratio until one full retention cycle has passed.
### one huge file rewrites every night
Mailbox databases, virtual disks used as file shares, and monolithic backup files from another tool change across their whole length every day. Split the workload, use application aware or block level backup for that source, or exclude the self-backup file that another tool keeps regenerating.
Edge cases: ransomware and mass encryption events also present as a sudden ratio collapse plus unusual change rates, so treat an unexplained drop as a security signal as well as a capacity one and check change rate per client before assuming a benign cause. Also watch global versus per job dedupe: turning off global dedupe or splitting repositories quietly removes cross job savings. Record the ratio per job weekly; a single repository wide average hides the one workload that is filling the disk until free space is already gone.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_kUeLH1mr8vxACLL52wb2Qw