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

[fborup]

Ticket is still under investigation, some new information here:

1) At hypervisor level, the volume size is 20TB, but the actual used space in hypervisor is 8TB, pretty consistent with what we see inside the operating system (allocated size 21.48TB, used Size 8.48)

2) Just a coincidence, I found an old volume group (probably a failed backup, the temporary volume group was left there) and the size of the volume group is 20TB, consistent with the whole volume size. AHV reports (allocated size 21.48TB, used Size 20.65)

3) TRIM is enabled in AHV (default Wi2012+, the proof is the used size os 8.48TB)

4) The weekly full is not synthetic, is ACTIVE full

5) fsutil behavior is ZERO DisableDeleteNotify , as exptected, default

6) NGT ins installed (probably nothing to do with the issue)

next weeked is the next full, what I did to test if there is some improvement:

A) deleted all my shadowcopies and disabled shadow copy at all
B) defrag
C) sdelete -c
D) sdelete -z
E) Optimize-Volume -path -Retrim –SlabConsolid


Any other idea?