Note: If your Hyper-V host is running Windows Server 2016 (or newer) and your Exchange VM is running on a Windows Server 2012R2 (or older) operating system, please note that there is a confirmed Microsoft bug.
A fix has been released by Microsoft in March 2021 for this issue. The KB article can be found here.
PROBLEM
When running Exchange inside a guest VM, the Microsoft Exchange Transaction Logs are not being truncated after a backup succeeds.
CAUSE
'Application Consistent' Backups or the 'Truncate Logs' option is not enabled; the VM does not meet the requirements for a live backup or there's a specific Exchange issue within the VM that's causing the Exchange VSS Writer to fail to truncate the logs.
SOLUTION
Note: Windows Server 2016 (or newer) hosts introduced an API that now bypasses VSS from the host and creates what's called a production checkpoint, so jump to point 4 in this case.
- Ensure that the "Application Consistent" option is enabled in the "VSS Settings" screen in VM Backup. If you're using VMware ensure that the "Truncate Logs" option is also enabled and it shows as 'Installed'.
-
Only applies to Hyper-V 2012R2 and earlier
Check if your VM meets Microsoft's requirements for a live backup, this can be easily done by following the steps in this article. If your VM is listed as 'Backup Using Saved State' or 'Offline', then this be the reason why the Exchange Logs are not being truncated, as Microsoft VSS wouldn't be running inside the VM.
If that's the case, check the live backup requirements in order for your transactional logs to get truncated.
-
Next, if you're running Hyper-V 2012R2 and earlier ensure that you have the latest Integration Services installed. To upgrade, connect to the virtual machine and select 'Insert Integration Services Setup Disk' from the 'Action' menu.
For VMware, ensure that the latest version of 'VMware Tools' is installed.
Also, please check for any Windows Updates inside the VM itself as they're an integral part of ensuring that VSS runs successful inside the VM.
-
If all of the above checks out, the next step is to take a look at the Windows Application event log of the VM itself. Essentially, the VSS process inside the VM (using the actual Exchange VSS writers) should indeed commit/truncate the logs if behaving properly. By looking at the same time of the backup, you should be able to find relevant events that point to the reason why the logs are not being truncated.
If you're running a VMware host and notice that the VM tools are going back to 'Required' instead of 'Installed'. Please take a look at this article.