Clearing the confusion around Exchange Server circular logging

Circular logging recommendations have changed over the years based on Exchange version changes, so there's a lot of contradictory information out there.

An issue that commonly confuses new Exchange Server administrators is circular logging. Because Microsoft's circular...

logging recommendations have changed over the years based on Exchange Server version changes, there is a lot of contradictory information out there on the topic. In this article, I explain what circular logging is and the pros and cons of using it.

A crash course in Exchange transaction logs

Before you can understand circular logging, you need to know what transaction logs are and how Exchange Server uses them. Information that needs to be added to a mailbox database is first written to an Exchange transaction log. The contents of that transaction log are later written to the Exchange Server database.

Exchange Server writes data to transaction logs first for a couple of reasons. First, it's more efficient to write data to a transaction log than wait for database activity to stop so a change can be written directly to the database.

Primarily, though, transaction logs are used as part of the Exchange Server backup process. Volume Shadow Copy Services aside, you can't back up an open file. If data were written directly to the Exchange database, you would have to close the database before you could back it up, which means it would be unavailable to users during that period of time.

Microsoft chose to use the transaction log model, so users can still access Exchange Server during a backup. The data is simply written to the transaction logs rather than to the Exchange database. When the database is backed up, the transaction logs are backed up as well and their contents committed to the database.

Normally, after a backup completes, Exchange transaction logs accumulate until the next backup. If you have to restore the database, those accumulated transaction logs can be used to bring Exchange Server database back to a current state.

The mechanics of circular logging

Circular logging was introduced in a much earlier version of Exchange Server as a method for conserving disk space. It prevents Exchange transaction logs from filling up your hard disk by limiting the maximum number of transaction logs in use at any given time.

In most cases, only four transaction logs will be used at a time. Since transaction logs are 5 MB in size, they will consume 20 MB of disk space if circular logging is enabled. Once the fourth transaction log fills up, Exchange Server makes sure that the first transaction log created has been flushed, and then replaces it with an empty log file that will store the next set of transactions.

For example, Exchange will initially create the following log files: E0000001.LOG, E0000002.LOG, E0000003.LOG, and E0000004.LOG. Exchange Server will fill up E0000001.LOG first before moving on to E0000002.LOG. When E0000004.LOG is full, the E0000001.LOG file is erased and replaced with E0000005.LOG.

Advantages and disadvantages of circular logging

Circular logging's main drawback is that it affects the ability to back up and restore data.

When enabled, you can only perform full backups of the Exchange database. You cannot perform incremental or differential backups.

Furthermore, if you ever have to restore a backup, you will almost always lose any data that has been added to the server since the backup was made, because of the limited amount of data that is stored in the transaction logs when circular logging is enabled.

You might be wondering why Microsoft would create a feature that limits the ability to recover from a disaster. As I explained earlier, circular logging is left over from an ancient version of Exchange Server. Today, hard disks tend to be massive, so it makes no sense to use circular logging unless your server is running extremely low on hard disk space.

How to enable or disable circular logging

Clearly, circular logging on an Exchange 2003 server is almost always a bad idea. As such, it is disabled by default. But if you want to verify that it is disabled, open Exchange System Manager and navigate through the console tree to Administrative Groups -> your administrative group -> Servers -> your server -> the storage group you want to check. Right click on the storage group, select Properties, and verify that the "Enable Circular Logging" checkbox is not selected.

About the author: About the author: Brien M. Posey, MCSE, is a Microsoft Most Valuable Professional for his work with Exchange Server, and has previously received Microsoft's MVP award for Windows Server and Internet Information Server (IIS). Brien has served as CIO for a nationwide chain of hospitals and was once responsible for the Department of Information Management at Fort Knox. As a freelance technical writer, Brien has written for Microsoft, TechTarget, CNET, ZDNet, MSD2D, Relevant Technologies and other technology companies. You can visit Brien's personal Web site at


It didn't seem like you pointed out the advantages of circular logging at all. Enabling it completely removes the threat of filling up a disk with transaction logs. For servers that perform bridgehead type functions and do not store any mail so-to-speak, it's often the case that a database would not have to be restored in a disaster situation (create a new one and you're up). If there's no need to restore a database, circular logging becomes more desirable.
—Pat P.


Granted, circular logging does have its place. If there were never a need for circular logging, Microsoft would not have created it in the first place. When I wrote the article, I did so under the assumption that the server in question would be hosting mailboxes and/or public folders, would have plenty of disk space, and would be backed up regularly.
—Brien Posey, tip author


Great article!

Is it also a good practice to enable circular logging if you have deployed a front-end server that doesn't contain any mailboxes?
—Ted O.


Front-end servers do not contain databases, and therefore there is no need to enable or disable circular logging.
—Brien Posey, tip author


What about using circular logging on front-end Outlook Web Access (OWA) servers in a DMZ?

Since there is no user data on the front-end server in this scenario, you could question the need to run an Exchange aware backup on these servers. They are not the first servers in the site and they don't have any databases, so recovery of these servers is much simpler. OWA servers don't need the same beefy disk requirements as the back-end Exchange servers, therefore, circular logging makes sense in this scenario. It's an economy of scale: mirrored drives, Exchange Standard Edition, low backup expense.
—Dave C.


This is a perfectly valid point. Again though, I wrote the article under the assumption that the server in question contained databases filled with mailboxes or public folders.
—Brien Posey, tip author


On Exchange 2003 SBS, cicular logging IS enabled by default.
—Brett F.


Yes, circular logging is enabled by default in SBS.
—Brien Posey, tip author


What if you are using an email archiving solution? Turning on circular logging in this case seems to be recommended.

Also, I am considering using a system snapshot solution on Exchange servers that will "snapshot" the disk at a given time -- including open files -- but won't purge transaction logs.

Is there a way to configure circular logging to use a certain amount of disk space (e.g., 1 GB or similar) and once reaching that limit to circle?
—Andy O.


Microsoft has gone back and forth several times over the years recommending that admins use or not use circular logging. I believe that the current recommendation is still not to use circular logging, even with email archiving (but I'm not positive). If there is information to the contrary, then you should certainly use Microsoft's recommendations.

As for automatically purging log files at a certain point... no, it just doesn't work that way.
—Brien Posey, tip author

Do you have comments on this tip? Let us know.

Please let others know how useful this tip was via the rating scale below. Do you know a helpful Exchange Server, Microsoft Outlook or SharePoint tip, timesaver or workaround? Email the editors to talk about writing for

This was last published in March 2006

Dig Deeper on Microsoft Exchange Server Transaction Log Files



Find more PRO+ content and other member only offers, here.

Join the conversation

1 comment

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

Please consider the following scenario and share your thoughts.

What would your recommendation be regarding backing up Exchange 2007 or 2010 via a block level snapshot program that doesn't notify Exchange a full backup has been taken? The program does quiese the filesystem and Exchange however doesn't have a mechnism to notify Exchagne a full backup has been taken. In this case hourly snapshots are taken, testing has shown no problem recovering items from snapshots nor building a VM using an older snapshot and exchange coming up and working just fine for that snapshot. The question that has come up is the scenario where exchange crashes at say 3:50pm the last snapshot available is 3pm, if we restore the .edb files from 3pm will exchange be able to replay the logs from the last snapshot to 3:50pm so no emails are lost? My understanding is that we would restore the .edb file, delete the checkpoint file and exchange would replay the log files up to 3:50 (the assumption here is all the log files will be available up to 3:50pm)

Great post BTW.