I'm curious as to why a backup would result where the Backup Size would be larger than the Data Size. I have a job that has one large vm in it and the daily backup specs look like this:
Not sure but perhaps check CBT function? Do you have an entry in the backup job stats for the VM that says "CBT data is invalid, failing over to legacy incremental backup..."? If so Veeam KB1113 links a VMware procedure for resetting.
No, not seeing anything like that. I ran a new Active Full 12 days ago which reset the CBT and have run Incremental jobs since. This job is using storage snapshots as the source. I have seen a correlation of that and this behavior.
Hey @squebel, what's the target repository? Is it a deduplication repository by chance?
And is this an incremental run/Synthetic Full or an Active Full?
The reason I ask is that most Deduplication appliances are append-only, so any "overwrites" are actually appended to the file instead of overwriting older deleted data.
If it's not, a support case is almost certainly needed. Check Veeam KB 1832 and select the first option, selecting this job as the job to export.
David Domask | Product Management: Principal Analyst
Seems like the deduplication is the problem. Your VBK looks OK, but the VIBs have a deduplication of 0,9x which means the backup size increases.
I would suggest that you let Veeam Support check that.
any chance, that your source data are deduplicated (lying on a volume, that is already deduplicated?
BR
Robert
Disclaimer: This posting is provided "AS IS" with no warranties or guarantees, and confers no rights. "Every once in a while, declare peace. It confuses the hell out of your enemies"
We did have the same question in "Mismatch in VM size - Case # 05744673" and got the answer that Veeam rethe size from vCenter and therefore this mismatch.
In our case the data size = 2.6TB and the original size = 3.93TB and therefore the Customer did have problems during a restore.
So far Support's answers haven't been very helpful. What would cause the deduplication number to be less than 1? It's like there's some kind of processing being done to the file that's actually making it larger than the amount of backed up data. I've never really seen that before.
I had exactly the same scenario some years ago. VM size was 500 GB and backup size was 700 GB. It was really simple: I had to run defrag on the windows vm. Nowadays we don't think about it as we have no control over where the data gets written by the RAID-controller or the datastore itself. So why did defrag help? Turned out that the cluster size in windows was smaller than on the hypervisor and now windows had spread many small chunks of data on these (bigger) hypervisor blocks and that's why the final backup size was much smaller. So to make a small (extreme) example:
Windows holds 1 byte in cluster A
vmware writes that cluster into its own block X with size of 512 bytes => results in a waste of 511 bytes
In this example case defrag wouldn't help either, but if bigger files are spread across the whole virtual disk where one half of the block is full and the other half is empty, you are wasting a lot of space. Hope it helps.
Yes. It is worth giving it a try - that defrag might also lead to a bigger increment size on the next run as probably a lot of blocks are changing but after that you should be fine. If that was the reason then your vbk shouldn't be bigger than the source vm, if not then you "only" wasted a bit of space for the increment...
It was about saving store space when using thin based disks on VMs. In which I made the following statement "This is generally only required on spindle discs, if your system is using SSD, or a logical unit based on RAID this won’t matter." If mcz is right, then my statement.... is wrong... oh dear god no...
...run an application/script that generates lots of files of different sizes, say 400 GB in total, do a backup and then delete 80 % of them (via script). See what happens
I haven't tested it but I'm sure that it will result in a difference IF the clustersize of vm and hypervisor is different.
