Recovering from Exchange Database Dismount due to Transaction Log Accumulation

As we all know, Microsoft Exchange uses transaction logs to commit data to the mailbox databases. One of the first critical issues we usually run into during our messaging career is a database dismount due to running out of capacity for the transaction logs. This is usually caused by at least one failed backup, and the emergency fix is to clear some of the oldest transaction logs from the drive so you can remount the database. Once the DB is back up (in a DAG you’ll have to manually delete the same transaction logs from each copy to restore HA), you may want to quickly truncate all of the remaining possible logs to maximize the time you have before the problem happens again. To do that, Microsoft has created a tool for testing VSS capabilities on an Exchange server (versions 2010, 2013, and 2016), but it has the additional benefit of kicking off the log truncation process while it runs. You can find the tool here:

A few things to note before using the VSSTester.ps1 script:

  • You would run this tool on the server with the active copy of the database
  • If this is the server the backup failed on, you may need to reboot (you could restart the Information Store service instead but IMHO if you’re going to move all the DBs off that server to bounce the service might as well reboot to clear out any other gremlins). For the tool to complete successfully all of the VSS Writers and such need to be in the correct state
  • Once this has successfully cleared your logs on the active copy the passive copies should truncate their logs as expected.
  • If you’re having problems running the tool on one server you can always make another copy of the DB active on another server and run it there