Logs are not truncated on incremental job runs

[CCSAD]

Our primary Exchange 2010 servers are still physical and being backed up by Backup Exec. However we virtualized a new mailbox server and have started backing it up with Veeam and application awareness. This server that Veeam is backing up holds passive DAG copies only. After the intial full backup the logs were cleared a expected. However the logs don't seem to be clearing after subsequent incremental Veeam backups. Is this supposed to be like this? We are using normal incremental (not reversed) and are NOT doing synthetic fulls. Fulls run once a week. I have reviewed the Windows App log and do not see any errors or warnings jumping out at me.

[foggy]

Chris, I've split your post into a separate topic since it does not relate to the topic you've originally posted into.

Do you see the 'Truncating transaction logs' message in the job statistics window when selecting the particular VM to the left? Have you already contacted technical support with that?

[Cokovic]

Whats the state of your Microsoft Exchange Replica Writer? Open a command prompt and type "vssadmin list writers". Can you see the Microsoft Exchange Replica Writer?

If so whats the state of this writer?

Keep in mind that in your scenario log truncation will still happen on the active node with the active databases. If you are looking for log truncation errors you should take a look into the event logs of your active node

If you cant see anything in the event logs on your active node you should focus on the Microsoft Exchange Replica Writer on the passive node as this one is responsible for log truncation notification issued to your active node after backup was finished. I had this situation too. In my case the above writer wasn't even present anymore. So Veeam finished its backup task and issued the log truncation command but no writer was present to pass this command through to the active node thus no log truncation happened and i couldn't find the event in the event logs. I had to bring the writer back by rebooting the server or just restarting the MS Exchange Replication service.

Described it earlier in this post here.