Backup Copy GFS full files seems too big, never reduce

[torteflo]

Hello,

I have a big question about our Backup Copy GFS full files still bigger than expected
I am looking for suggestions/ideas/assistance, but still unsure what is the source of our problem

The environment :
2 sites
vSphere 6.7 stretched cluster and 3PAR with continuity plan
Veeam Server 9.5 in a VM
Veeam SQL standard in a VM
1 Veeam Proxy per site, physical windows 2016 server, with SAN access
Repository are also on the same physical proxy server with internal drives with ReFS

There is 2 big Syslog VM, 1 each site, each with the same problematic. So lets talk about 1 of these 2 VMs
At start this year we had a VMDK on this VM with all logs, 25 TB used space by these logs (for 40 TB VMDK total size)
The OS VMDK is negligible
When backuped by Veeam a full backup file for this VM was around 6 TB, from january to may

Then, in may, we "cut" the logs on the source VM, in 2 parts, between 2 VMDK
Today we have :
- VMDK 1, the original one, now only have 13 TB used by logs datas
- And new VMDK 2, where around 60% of all logs are now stored, have 17 TB used by logs datas

Logs size is stable since january, but we get 5 TB more in total (25 vs 13+17) because logs retention in source VM was increase

In Veeam we have now 2 jobs too for one of this Syslog VM :
- Backup Job 1 (original Job) : backup VMDK 1 only > VBK is still around 6 TB !
- Backup Job 2 (new job) : backup VMDK 2 only > VBK is arount 2,7 TB

The VBK for job 1 seems too big, as there is only 40% of initial data stored on the VMDK, and a VBK is still the same size than before

Could it be that the Full of Backup Copy still only grow and can never reduce ?
Could it be that we have some data blocks still not released by the VM guest OS, or something like that, and could it have consequence with Veeam ? it is really a shot in the dark for this idea, but also I don't really think Veeam is the main part of the issue here.
Because I also note that this VMDK1, which is thin, and which total size is 40 TB, is using 40 TB on the datastore

Doing a new full for Backup Job 1 is the last solution, we really would like to avoid

[foggy]

Could it be that we have some data blocks still not released by the VM guest OS, or something like that, and could it have consequence with Veeam ? it is really a shot in the dark for this idea, but also I don't really think Veeam is the main part of the issue here.

This is actually it, unless you have Bitlooker enabled. NTFS does not zero out disk blocks when file is deleted, but rather just marks them empty, so they still contain data when are backed up by image-level solutions like Veeam B&R.

[torteflo]

Foggy, by NTFS you mean the backuped VM filesystem ?
These 2 Syslog VM are Linux ones, in fact, CentOS 7
Same behaviour you think ?

This explanation is my only guess/hypothesis here, so I wonder if it was The good one or I could miss other thing related to Veeam and Backup Copy..
Thank you

[foggy]

Yes, it might be it as Bitlooker works for NTFS only.

[torteflo]

Sorry for delay
Thanks

Actually I think we'll try a fstrim on these in a few weeks
I will try to do a feedback here

[torteflo]

Hi,

fstrim done and it worked like a charm
Now the VBK of the Backup Job 1 is around 2,8 TB !
Thanks for your time