KB ID: | 1878 |
Product: | Veeam Backup & Replication | 10 | 11 |
Published: | 2014-04-21 |
Last Modified: | 2022-01-14 |
Now you’re less likely to miss what’s been brewing in our knowledge base with this weekly digest
Exchange truncation may not occur for the following reasons:
VMs processed by Veeam Backup & Replication must have Application-Aware Processing enabled to perform truncation.
Confirm this by editing the job, going to the Guest Processing tab, and ensuring the Enable application-aware processing is checked.
In addition to making sure Application-Aware Processing is enabled, check that truncation is enabled at the granular per VM level. Click the [ Applications... ], then in the window that opens, highlight the Exchange server and select [ Edit ]. Within the processing setting window, make sure that the job is set to either "Require successful processing (recommended)" or "Try application processing, but ignore failures," then make certain "Process transaction logs with this job (recommended)" is selected.
On the Exchange server that was backed up, navigate to C:\ProgramData\Veeam\Backup and open the most recent VeeamGuestHelper log file.
Within the VeeamGuestHelper log file, search for: "Notifying writers about the 'BACKUP FINISH' event."
After that line will be a list of each VSS writer notified of the 'BACKUP FINISH' event. When the Exchange VSS writer is notified that it has been backed up, it handles the truncation process. There may be multiple lines regarding the Microsoft Exchange VSS Writer, the most important of which is the one that will end in "Ok." which signifies that notification was successful.
Example:
Notifying writers about the 'BACKUP FINISH' event. Truncate logs: [true]. Notifying a VSS writer about the successfully backed up components. Writer name: [Microsoft Exchange Writer]. Class ID: [{guid}]. Instance ID: [{guid}]. Writer was notified about the successfully backed up component. Component's logical path: [Microsoft Exchange Server\Microsoft Information Store\EXCH-MBX]. Component name: [guid]. Writer was notified about the successfully backed up component. Component's logical path: [Microsoft Exchange Server\Microsoft Information Store\EXCH-MBX]. Component name: [guid]. Notifying a VSS writer about the successfully backed up components. Writer name: [Microsoft Exchange Writer]. Class ID: [{guid}]. Instance ID: [{guid}].. Ok.
Entries about other writers were removed from this example for conciseness.
vssadmin list writersIf the writer is not listed or is in a failed state, the Exchange server should be rebooted, then it should be verified that the writer returns and shows as Stable/No Error. Once this has been done, retry the Veeam job and verify log truncation.
Within Event Viewer on the Exchange server, look for any Exchange related errors. If the Exchange configuration utilizes Distributed Availability Groups (DAG), the replication process between the different nodes can prevent log truncation if there are any errors. These will show with the event source MSExchangeRepl. Generally, if there are errors, these are not caused by Veeam Backup & Replication processes and should be addressed in the Exchange and/or Windows configuration. To isolate whether the issue is caused by a Veeam Backup & Replication process or within VSS itself, enable the Windows Backup role on the Exchange server and run a native Windows Backup (system state). Alternatively, test manual shadow copy creation and truncation as documented here: KB1980: Using the Diskshadow Utility to manually test VSS operations
MSExchangeRepl errors: http://technet.microsoft.com/en-us/library/hh994877(v=exchg.141).aspx
Your feedback has been received and will be reviewed.
Please try again later.
This form is only for KB Feedback/Suggestions, if you need help with the software open a support case
Your feedback has been received and will be reviewed.