Larger .VBK sizes for single disks vs. combined disks?

[awiesen]

I'm well aware that Veeam does deduplication when you're combining VMs and probably must do it across disks as well. But I'm seeing very odd sizing behavior.

For a VM I have, here's my .VBK sizes. All backups are using Best compression.

C: drive only: 3.7 gigabytes.
D: drive only: 32 gigabytes.
C and D drive combined: 27 gigabytes.

Huh? I can imagine a situation where C and D combined are maybe a little bigger than the largest drive. But smaller?

My hunch is that there's some nice optimization or deduplication that happens only when working with more than one disk. This deduplication can take advantage of say, the same blocks being stored multiple times even on a single disk. This probably never gets executed when doing a single disk backup, so the single disk backups wind up being larger than they need to be. (That's just my hunch as a software engineer.) There's no reason you can't do this for a single disk backup. It seems really weird that in a situation like this, it would be more efficient for me to store extra data along with the D drive in order to get a smaller backup file of the D drive.

(Now that I think about it, I bet I could test my theory out by cloning disks and making backups with the cloned disks + original vs. just the original by itself. Maybe I'll do that if I don't hear anything.)

Any ideas? We like storing our backups on a disk-by-disk basis, even though it means no deduplication (between disks) because it makes it easier to work with the backup files when shuffling them around our different datacenters.

- Alex

[Gostev]

Alex, please re-create all 3 jobs with Best compression selected at the time of job creation. I suspect that you did not have D: drive only job created with Best compression, but rather changed it to best later, which would have no effect on VBK file.

[awiesen]

I did re-create the job actually, because I did exactly as you described at first, and figured that too. (Which by the way -- you should disable the compression option when editing an existing job so users don't get the impression that it can be changed. It's misleading to leave it enabled.)

However, the new job created a backup exactly the same size as the first one. (Exactly!) Which was a bit surprising.

I wonder if the new job ignored the Best compression type and used the compression type for the older job that was still around?

- Alex

[Gostev]

Actually changing compression setting does have effect, just on VRB files only, thus it is not disabled.
But I will ask devs on their opinion about the size issue.

[Gostev]

Alex, developers would like to view the logs for these 3 jobs. Could you please send all files from Help | Support information to support@veeam.com, and lets us know the job names in question.

[awiesen]

I sent the logs to support. I also deleted old jobs, created yet another new one, rebooted the server, and ran it again. Same big 32 gigabyte size again.

This is holding up our rollout of Veeam so it'd be nice to have an answer (even if it's "Sorry, that's just how it is") in the next 24 hours from Support. Thanks in advance.

- Alex

[Gostev]

Alex, no - of course this is not "normal" or expected behavior... can you please also confirm if you take VBK size numbers from Veeam Backup statistics, or are these actual file sizes as seen in Windows Explorer?

[awiesen]

These are actual file sizes taken from Windows itself (as well as on Linux, where I copy them.)

Thanks, I look forward to hearing more.

- Alex

[Gostev]

Alex, from the logs it appears that combined disks backup was performed on 21st, while individual disk jobs were performed later, on 22nd-23rd. Between these events, according to backup file statistics, there was significant change in the amount of "white" space on these drives. This explains the difference.

Does it make sense?