How to manually purge Exchange server logs – clean and easy

Update 9/Jun/2015 – Thanks to Josh Davis for the feedback, I’ve added a note about making sure to include both drives (if EDB and LOG files are separated).

Update 21/Oct/2013 – This 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 – http://technet.microsoft.com/en-us/library/bb331958%28v=exchg.141%29.aspx#UTL

I often get calls and questions regarding backups and Exchange Server, since ever this issue is 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, transaction logs will get piled and fill up the volume or disk 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.. and here’s where this post comes in…

So how can you delete or purge Exchange server logs without any risk ? well, in simple – you cannot, because the whole idea of restoring an Exchange or for this matter any transactional database requires you to have a first – “full” backup of the database itself and all transaction logs that were generated since the 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 2008 or 2008 R2) . This procedure also “proves” that a VSS backup for your Exchange Server will work fine.

note: This method was tested on an Exchange server with Locally Attached Disks, not storage attached LUNs.

Use this method on on your risk. You should preform a “Full Backup” right after this process is done.

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…

Open Command prompt

Launch Diskshadow

Add volume d:

(optional, add one line for each additional drive to include) Add volume X:

Begin Backup

Create

End Backup

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 from 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.

side note: although this example was tested against Exchange 2010, it should work just as fine with Exchange 2013 & 2007.

Brilliant Idea – Was trying to move all mailboxes to another storage space, but about 50% the way though the Logs filled the remaining space. This freed up enough to get the store back online and finish the job – saved me having to move 1TB to another space just to finish the copy.. Thx (3 years later)

thousand times THANK YOU. My EXCH2010 was nearly using 1TB of disk space for logs. The consistency check for the backup has taken more than 20 hours before the backup has started.
My backup wasnt working the last two weeks and so the logs become more and more………..

I found out another method although maybe not recommended but works, stop the information store, just delete the older transaction logs (longer than a month or so) get some free space.restart the exchange information store. run a backup. that will clear all logs and reclaim the space.

thank you very much for the great solution.
i have a question:
last week my exchange server 2010 was unexpectedly restart,
since then i am getting A bad page link (error -338) and my exchange database logs folder is grow up
every day like 30 gb per day/
whay can i do?
esutil?
or the solution you gave?

Terry, valid point, thus Circular Logging will require you to dismount the databases and that will cause service disruption.
I’ve just realized I didn’t wrote about that in the post. I’ve added a comment about Circular Logging.
Thanks for your feedback!
ilantz

sorry, can provide much clear step ?
currently the path to store DB has out of space and automatically dismount, due to less of resource the HDD cannot replace or extend
thus, can I use this method, like
i. disable the exchange service
ii. manually remove all *.log file
iii. run diskshadow as you provide

after that exchange 2010 can mount up the db since it has been treat as a “full backup” conduct ?

This method required that the database will be mounted, if it’s already dismounted, then what I’ll suggest is to sort the log folder by date descending, then delete or move the files just enough to get by.

You just saved me from a potentially very nasty situation. Started getting 452 4.3.1 Insufficient system resources. Checked mailbox log store – Whoa, 139000 transaction logs and down to 12gb of free space. (Wouldn’t have had a hope in hell trying to repair DB from ‘Dirty Shutdown’ if the store had crashed). Further investigation showed MS VSS backup schedule had been deleted.(Don’t ask – too many admins!)

Ran above – What a pleasure. (Less than 5 min of work). All good. Now to go and kick some techies a**s.

I am running exchange server 2013 with DAG. I have two mailbox servers on which DAG is running. The problem is that my log files are not purging with Windows Server backup. I tried to enable Circular Logging and then dismount database and then mount it again. It did not have any impact on log files.

One thing which I noticed that during windows server backup the service for Microsoft Exchange Server Extentsion for Windows Server backup do not starts. If I manually start this service then it stops after few minutes.

To make sure circular logging will
take effect, make sure that you dismount and suspend all other copies. Mount back the db following with resuming the copies. The logs should truncate soon once all copies
are in sync.

This article still holds true today. Our full backup of Exchange 2010 via Backup Exec completed successfully but Exchange still showed that no backup had occurred for one specific database. The VSS backup didn’t work the first time I attempted it however. The VSS exchange replica writer service showed a retryable error. I activated the database on another DAG member, rebooted the server with the VSS error and then performed the steps above. This bought me plenty of time to resolve the issue with the full backup. Can’t thank you enough!

Quick question Ilan Lanz…. one of my customers actually DELETED exchange LOG FILES (10 GB out of 30GB in the system)…. now store is still up but VSS backup fails due to consitency check beeing bad…. would you method be a good try? or you dont recomend it?

Thanks for writing this article but unfortunately it did not work for me. There were no errors received, it appears to have run the shadow copy backup without a problem. Once complete however I don’t see any of the events listed in this article in the event log and the logs never clear. I am on Exchange 2010 SP2 with storage attached LUN’s.

I did tested that method on an exchange server with local disks, however I see no real reason why it won’t work with storage LUN’s attached…
If I’ll have the chance I’ll try to reproduce and report back.
Would appreciate if any one subscribed to the post will share their result with the storage config they’ve used.
Ilantz

For those of you who claim that this does not work. I am here to save you. I too thought that this method did not work, however I was incorrect. The problem is that a lot of folks have their logs and database drives on different drives. Sound familiar? See below.

Just a note on enabling circular logging for a database with 2 or more copies in a DAG, you DO NOT have to dismount/remount the database for circular logging to take effect. Again, you must have multiple copies of a database for Continuous Replication Circular Logging (CRCL) to begin removing log files on the fly, and it may take up to 15 minutes for you to see the log files begin to disappear.

Yomi Ogunbajo…….this works like magic and it has been tested on Exchange 2010 and Exchange 2013 as well.
Note: Do make sure you add the other volumes that houses your Databases as long as its resides on a different drive from the drive that houses the log files.
DISKSHADOW: add volume G:
DISKSHADOW: add volume H:
DISKSHADOW: add volume I:
DISKSHADOW: add volume J
DISKSHADOW: add volume K:
DISKSHADOW: add volume L:
DISKSHADOW: begin backup
DISKSHADOW: create

NB: Drive G is for the log file while Drives H-L are for the DB. The create command takes a while to execute depending on the size of the log files and the DB in your Exchange Organization.

Hi Chris,
The fakebackup script works fine on Microsoft Exchange 2013 and it does not take time, when you initiate the create command that may take a while depending on the size of the logs and you DB!!!

Thanks for the info. I am right about at this stage since my backup server is loosing communication for some reason with the Exchange server. Now I have 40gigs left out of 1.5 tb. Exchange store is only 200gigs. My question to you is, will this method work if all stores are on the C drive? Can I do this spoof shadowcopy on the one and only drive (scary) that obviously also runs the OS.

Hi Ilan. Thanks for the really great and helpful article. Can you confirm one thing for me… When you run the DiskShadow cmd to create the spoof shadow copy does it actually create a backup of all the files on the volume that you specify and where is that backup actually stored? We have a 1TB drive where the Exc 2007 server logs are stored and its almost out of space and none of the other drives on the system have sufficient space to hold a backup of the logs. We don’t currently have Exchange specific backups configured (we’re working on that) and so the transaction logs are building-up. Your solution would be a good workaround until the backups are configured but I am bit concerned about what will happen when running diskshadow. I’ve googled the DiskShadow cmd but can’t seem to clarify if it actually backs-up the files to another location and, if so, where it puts those files? Does it just pretend to perform a backup or does it actually create a copy of the files somewhere? Hope you can clarify for me…

Hi Ilan Great article, I have a situation one of the database logs folder is running out of space on Excahnge 2013 DAG member attached EMC LUN, and at the moment there is some issues with backup solutions, so can i use this method only for that particular database ? please advice. and as you mentioned Is it is must to do a backup ofter this procedure?

Hi yeah, this should work. Keep in mind that this work in the volume level.
Because you are removing log files with this method. You must do a full backup because you lose the point in time capability when you purge log files.

Keep in mind that within a DAG the actual removal time of the log files is delayed. So wait a while after you perform the method.

Great post, but I do have a question or two:
1) I see in some of the comments that this should work in a DAG environment, do you run this on each member of the DAG or just the active member?
2) in my environment I have several databases and logs stored on the same volume, will this process identify each database that is mounted by the Information Store and truncate log accordingly?