Full back of a VM, VBK size and free space in VM

[lightsout]

My Veeam server is running on 2012 R2, and is using Microsoft deduplication for backups. So inline dedup is on for my jobs, compression is off and I'm using the LAN target. This is v7 patch 4 version.

I'm backing a 2012 R2 file server, which is 4TB VM in total size. This also has deduplication on! What surprises me, is that VBK that this job created (only VM in the job) is 4TB in size too. Yet the VM, has ~1.5TB of free space spread out over several disks. I'm using an application aware backup too in Veeam for this server.

So my question is, why is the VBK so large? Isn't it meant to skip the free space?

Thanks.

[dellock6]

double deduplication of Windows 2012 R2 is not a good practice, the changed blocks of the deduplicated VM are going to be too many, thus impacting the performances and the size of the backup. If you need to keep the guest OS deduplication on, I'd suggest to disable the one on the Veeam server. Double processing duties with no advantage.

[lightsout]

I agree it isn't ideal, but I don't see the harm. The file server is reduced greatly in physical disk usage by using deduplication. Deduplication does an excellent job in Veeam for the backups. Maybe not for this VM, but for the others I'm sure it does.

Regardless of double deduplication, I don't see why a 4TB VM with 2.5TB disk usage should generate a 4TB VM for a full backup. The change logs the deduplication causes won't be a problem for a full backup after all I'd have thought.

[chrisdearden]

Free space isn't nessesarily zero'd blocks. While windows may mark them as free, of they are a used block on the virtual disk, we will back it up.

[veremin]

Most likely, the situation is related to dirty blocks being present inside operating system. Thanks.

[lightsout]

I'm sure that is it. I was hoping the VSS would help the situation, but when I thought about it more, I'm not surprised it doesn't.

So I'll work on sdelete then.

I also have a different option. I have, for better or worse, have Condusiv (aka Diskeeper) V-Locity installed for virtual machine optimization. One thing it can do is zero out the disk when it optimizes the file. Whilst this doesn't do what sdelete does, it means it does help keep NTFS clean, and it does so without filling up the disk like sdelete does. It can also just write zeros to all slack space too without writing a file.

[dellock6]

Be careful, in both situations those cleaned blocks will be freed from an OS perspective, but still marked as modified at the CBT layer. We suggest usually to run a full backup after an sdelete (or like) operation so you can then beenfit of the reduced number of used blocks.

[lightsout]

Yeah, I see that. On the tests I'm running, I'm suddenly seeing a much higher deduplicate rate on those jobs!