TSM incrementals fail on Exchange after Veeam Backup

[Moebius]

A customer uses IBM Tivoli Storage Manager (TSM) for file-level backups and Veeam B&R on the system disks only, for disaster recovery purposes.
The Exchange database is backed up daily with the TSM Data Protection for Exchange, which also leverages VSS.
The backups made by TSM are incremental except on Saturdays, when a full backup is performed.

All has been working flawlessly for months until the introduction of Veeam backup. With Veeam only the system disk of the Exchange server is backed up (using the VSS-only method) weekly on Sundays. Apparently the Veeam backup disrupts in some way the TSM incremental/full sequence; this is what happens:

Saturday, 1:00 AM: Exchange full backup with TSM, success.
Sunday, 1:00 AM: Exchange incremental backup with TSM, success.
Sunday, 1:00 PM: VEEAM backup of C: disk with VSS, success.
Monday, 1:00 AM: Exchange incremental backup with TSM: fails with the following message:

Backup of storage group First Storage Group (EXCHGROUP) failed.
ACN5798E MS Exchange API HRESEBACKUPSETUP() failed with HRESULT: 0xc8000230
The database missed a previous full backup before the incremental backup.

which repeats for all storage groups.

This goes on the following days until a TSM full backup is performed, at which point the incrementals run correctly again (until the next Veeam backup...).
I have the impression this is not a TSM issue but rather a VSS issue. A product B backing up the Exchange database disrupts the sequence of full and incrementals of a product A doing the same thing.

Aside from the obvious workaround solution of scheduling the TSM full just after the Veeam backup, any other hints?

[Gostev]

So what does TSM support say? I doubt it is VSS issue... from your description, it sounds like TSM bug: it does not expect any other application to perform shadow copies on the computer it is backing up?

[tsightler]

The problem you are having is that, when running the Veeam backup, even though you are backing up only the systems disk, the VSS freeze applies to the entire system, not just the system disk. When the system "thaws" after the snapshot, the Exchange logs are purged. An "incremental" backup of Exchange with TSM is basically just a log backup so I'm sure that error message is TSM's way of saying "hey, there's logs missing since the last full".

As a workaround you might consider disabling Veeam VSS for this case, perhaps using VMware VSS in it's place since I think VMware VSS doesn't support Exchange so it probably wouldn't eat the logs. Actually, since you're only concerned about the system disk, simply skipping VSS might also be fine.

[tsightler]

So what does TSM support say? I doubt it is VSS issue... from your description, it sounds like TSM bug: it does not expect any other application to perform shadow copies on the computer it is backing up?

TSM support will say, "Yes, if another application comes in and deletes the Exchange logs prior to TSM running an incremental, then the incremental will fail". It's not that TSM "does not expect any other application to perform shadow copies" it's that Exchange incrementals can't work without the logs. If another application performs Exchange VSS backup, the logs are gone since the Exchange VSS thaw process removes them.

The problem in this users case is that he's doesn't want to use VSS for Exchange backups, so, as far as I can tell, he'll need to disable Veeam VSS since it will always perform full application VSS which includes the "purge Exchange logs" after the thaw.

[Gostev]

Makes perfect sense, thanks for the explanation Tom.
Sounds like not using Veeam VSS is the way to go.

[Moebius]

Thanks Tom, I guess you're right. From the TSM standpoint it appears as if another application, unknown to it, recently performed a full backup (which is, indeed, exactly the case) clearing some info that TSM needs to calculate the increment.
I'll try and disable VSS on the Veeam backup and report the outcome. As you say, as I'm only concerned about the system disk and all the databases are on other volumes, I should not need VSS for Veeam in this case.