Estimated reading time: 4 minutes

Thank you for reading this post, don't forget to subscribe! Happy New Year 2024!

“Often, you hear about something weird and un-supported, and feel like you have to share it”.

I often get calls and questions regarding backups and Exchange Server, and most backup technologies are not always working as required or as you would expect, but that’s off-topic.

One of the most common stories is that without a working Exchange Server backup, when you perform massive mailbox moves or no backup at all, the transaction logs will get piled and fill up the volume that they reside in. and then panic starts, “hey my databases were dismounted…” then of course the administrator realizes that the space on the log drive or volume has indeed ran out and now he needs to figure out what to delete. On Nutanix, we simply can solve this by extending the container that the logs live in, but what if you rely on snapshots for backups.

I had a customer reach out to me running Exchange 2007 with CCR ( Cluster Continuous Replication) on Nutanix. Yes, you heard me right, Exchange 2007 ;).  They are planning on migrating to Exchange 2013 in the next year or so, but need to get from A to B for budgetary reasons until then.  The only form of backup the customer has is to use Nutanix daily snapshots.  The customer understands the painful process of restoring an individual mailboxes from snapshots and not having up to date recovery that logs provide along with the point in time database backup, but its a risk they are willing to take as opposed to having nothing. They reached out to me and asked, how do cleanup logs that are piling up. And so here’s where this post comes in…

My blog article suggests that you cannot sustain downtime or interruption for your users while battling with deleting log files or restoring your working backup solution. If you can sustain a downtime (should be around minutes or so) the easiest method will be to enable Circular Logging on your database / storage group – see more here –

The customer needs to be able to purge the committed logs so they don’t fill up their disk space.  So how can you delete or purge Exchange server logs without any risk? well, in simple – you cannot, its built-in by design, because the whole idea of restoring an Exchange or for this matter any transnational database requires you to have a first – “full” backup of the database itself and all transaction logs that were generated since the date of the database creation date, or the last “successful” “full backup”.

Now here’s a nice method to “fake” a “full backup” or an on-demand transaction logs purge when you see you will be soon out of space, using the Exchange VSS writers and the diskshadow utility (available with Server 2008R22012R2) . This procedure also “proves” that a VSS backup for your Exchange Server will work normally.

Please note: This method was tested on an Exchange 2010 server with using a Nutanix block NX-3460-G4. Use this method on your risk.  This is not supported by Nutanix or Microsoft.. You should perform a “Snapshot” before and right after this process is done.

How to manually purge Exchange server logs – with ease

This example will show you how to purge the logs for a database that is located on Drive D, the log files of the databases are also located in Drive D. we will “fake backup” drive D and this will trigger the logs to be purged.Note: If you have separated your log files and database file in different drives, or you want to include additional databases in the “backup” you must include the additional drives in the process, so in the example below, you will “Add volume e:” after “Add volume drive d:” and so on…

1. Open Command prompt
2. Launch Diskshadow
   1. Add volume d:
   2. (optional, add one line for each additional drive to include) Add volume X:
   3. Begin Backup
   4. Create
   5. End Backup
3. At this step you should notice the following events in the application log indicating that the backup was indeed successful and logs will now be deleted.

Here’s some screenshots of the process:
The Diskshadow example screenshot.

ESE – Event ID 2005 – Starting a Full Shadow Copy Backup

MSexchangeIS – Exchange VSS Writer preparation.
ESE Event ID 224 – Logs are now purged

MSExchangeIS Event ID 9780 – Backup is now complete.

Final Note: although this example was tested against Exchange 2010, it should work just as fine with Exchange 2016/2013 & 2007

Until next time, Rob.