High change rate

[dasfliege]

We need to explain to a customer why their M365 backup has an extremely high change rate. Their backup size grew from 4TB to 8TB within just one month.

Is there a Veeam KB article that details when an object is considered changed for each module (Exchange, OneDrive, SharePoint, Teams)? In particular, we’d like to understand how Veeam handles versioning in SharePoint.

Additionally, when an item changes, does Veeam download and store the entire object again, or does it only save the changed blocks/versions?

Finally, does anyone have recommendations on how we can use Azure tools and reports to identify what is driving this high change rate?

[mjr.epicfail]

it could be natural growth, could also be that the scope of the backupjobs changed, could also be that Microsoft made an oopsie and changed the datetime stamp on the objects, veeam uses that property to see if its newer than whats in the backuprepo.

[Polina]

Hi Florin,

There's no such a KB.
Each item version is saved separately, and the entire changed item (file, email, etc.) is downloaded again.

[DaStivi]

check the backup run in history tab... there you'll get a guess what has been downloaded... look for the "transferred" stats, you need to manually count them togehter, now you can see if that adds up to the growth in (bucket?) size..

another thing you should check is the report usage page in m365 admin portal... also quite cumberome , but you should see the data growth there too, somewhere...
https://admin.microsoft.com/Adminportal ... portsUsage

[dasfliege]

Each item version is saved separately, and the entire changed item (file, email, etc.) is downloaded again.

So if an item with 100 versions changes, the whole item including all of it's 100 versions is downloaded and stored again? If such an item changes daily, how is the actual storage consumption behaving on the repository? Will it dedupe somehow?

[dasfliege]

Unfortunately Azure reports do not really reflect what is considered by veeam as changed.
For example, this customer has an average veeam transfer per day between 10 and 30GB. On the 13. and 15. of march we had almost 1TB each day.
Azure reports do not show any anomalies on that days. Neighter in storage grow nor activity.

Quite difficult to explain to the customer his high storage costs for the backup if it is not reflected on azure in any way...

[dasfliege]

Case 07651290

[dasfliege]

We’re still chasing ghosts with this case. In the meantime, we’ve opened a new support case with Veeam: 07776717.

We’ve also performed some troubleshooting with Microsoft. According to them, it’s Veeam’s responsibility to correctly identify which fields should be used to determine whether an item has actually changed.

The issue remains unchanged: for some tenants, Veeam is backing up thousands of items daily, even though no new version exists, and even the metadata hasn’t changed. The only field that changes appears to be something undocumented, like “SMLastModifiedDate”, and we have no idea why.

Since we've been told that Veeam is now working closely with Microsoft, I’d really appreciate if you could implement a more reliable algorithm to detect true item changes. I hope others are affected by this as well and can +1 such an enhancement.

[Polina]

We are indeed discussing it with Microsoft, and have already proposed alternative approaches that could help to avoid such issues. Things move slowly though. Spikes in backup data in most cases are indeed caused by changes in internal and undocumented fields. Those changes impact the overall 'change' status of an item while being currently impossible for us to filter out. Eventually, this will be resolved.

@johan.h Maybe you can share more on this?