Increased incremental backupsize after migrating SQL database to newer version

[dasfliege]

We have migrated one of our SQL-Servers from a Windows Server 2012 with SQL 2012 to a Windows Server 2019 with SQL 2019.
On the old server, we did the backup with Veeam Agent. On the new one, we do it with a standard VMware backup job. The source backup size is exactly the same and the Database is also setup exactly the same as on the old server. But since the migration, we have between 0.6 to 1TB incremental backups every day. Prior to the migration it was only around 0.2 - 0.4TB. I wonder if there is anybody else who observed the same behavior after migrating to a newer SQL version?

[veremin]

But have you tried to back it up with the Veeam Agent after migration (so it be a fair comparison)?

[dasfliege]

No i didn't. I don't think that the switch from agent to vmware backup caused the increase. Rather i think that SQL 2019 just produces a lot more junk somehow. I thought maybe someone observed the same after migrating to never SQL versions and already found the "magic" switch in SQL 2019 to prevent it from generating loads of data

[veremin]

I would still explain this as a difference in backup mode used: inside and outside the guest operating system. So if you have a time, it might be worth giving a try Thanks!

[dasfliege]

We're still working on this issue with Veeam and VMWare support.
After analyzing the logs, VMWare came up with the following explanation: https://kb.vmware.com/s/article/59905?lang=en_US

After deactivating inguest-unmap, we do have smaller incremental backups. So it seems like veeam is not utilizing the correct API calls to receive proper CBT information?
If this is true, i wonder why this hasn't been recognized way earlier?

[veremin]

What is your Veeam support ticket number, so we can take a look at the investigation and see how it ended? Thanks!

[dasfliege]

Case 05217700

[veremin]

I can see that the support ticket was created a week ago and has been actively handled since that time. In their latest reply the support team didn't confirm the issue with using the incorrect APIs.

So kindly continue your investigation with them.

Thanks!