Why is my Backup Size BIGGER than the data itself, even with compression?

[fborup]

Why is my Backup Size BIGGER than the data itself, even with compression?

My scenario here is:
I have a WIndows 2025 VM, with two volumes/partitions:
C:- Drive, NTFS, 250GB in size, 45GB in use, 205 FREE SPACE
and
a Mount Point, C:\MyData, formatted as RefS and with DEDUP, reaching 46% in dedup, as seen below

Volume : C:\MyData
Capacity : 21.48 TB
FreeSpace : 13.27 TB
UsedSpace : 8.22 TB
UnoptimizedSize : 15.26 TB
SavedSpace : 7.04 TB
SavingsRate : 46 %
OptimizedFilesCount : 8400931
OptimizedFilesSize : 14.47 TB
OptimizedFilesSavingsRate : 48 %
InPolicyFilesCount : 60884
InPolicyFilesSize : 619.86 GB

As seen, the used space is around 8.22TB and considering a dedup ratio of 46%, it´s safe to estimate the full data (dehidrated) size of volume to be in the backup, as around 15TB
So, what the backup tool should do: Extrac the raw information, effectevely "undedupping" the data and submit arounf 15TB through the network for backup
am I right?

OK, until, now!

What is the expected role for AHV proxy, to get the data coming from Windows (15TB) and COMPRESS it (i´m using the DEFAULT COMPRESSION in the AHV Job)
What s expected to happen? The size of the full backup should be at least a little smaller, am I right?
Even considering the AHV Proxy compression worse than ReFS compression, the expected size of the backup should be SMALLER that 15TB, am I right?

BUT... practice killing theory.. the full backup size (Synthetic full) is.. 19,9TB, almost 20TB!
BIGGER than the current volume of information
WHy?
This doesn~t make any sense to me

Below, the size of the =~15TB, wth compression enabled, 21.345.920.135.168 Bytes.. 19.9TB!!!!!!!!!!!
seen here: 31/01/2026 08:43 21.345.920.135.168 VMBackup2026-01-31T010522_9E37.vbk

What am I losing here?

[Mildur]

Hello fborup

Why is my Backup Size BIGGER than the data itself, even with compression?

We can’t investigate environment-specific issues over the forum. Please provide a support case ID for this issue, as requested when opening a new topic (forum policy). Without a case number, the topic will eventually be deleted by the moderators.

So, what the backup tool should do: Extrac the raw information, effectevely "undedupping" the data and submit arounf 15TB through the network for backup am I right?

Yes, your understanding is correct. Our worker performs block-level backups and does not consider the “dehydrated” size — only the actual disk data blocks with content.
As mentioned, please start the investigation with our Customer Support Team and provide the case number once available.

Best,
Fabian

[Kochkin]

There are multiple factors which may affect your backup size

• If you have a forever incremental backup chain (no active or synthetic fulls), the VBK will accumulate some amount of garbage data. For AHV it is recommended to have periodical active or synthetic fulls scheduled if you want to keep your VBK small

• Deduplication block size is different on ReFS (4k/64k) and in Veeam (=backup block size, 1 MB by default). Deduplication efficency might be different because of that.

• When you back up an AHV VM, you may want to check the used size of hypervisor side. You can see it on Inventory tab in Veeam Backup & Replication. The size used on hypervisor might be bigger since dirty blocks are still taking some space. Veeam has a feature to exclude dirty blocks, but it works only for NTFS: https://helpcenter.veeam.com/docs/vbr/u ... tml?ver=13