Summary: Circular Logging in Exchange Server helps clean the old transaction logs and make space for new logs. This blog covers information about Circular logging & also the steps to enable Circular Logging in Exchange to avoid database dismounts or corruption due to low or no space.
Circular logging allows Microsoft Exchange to overwrite transaction log files after the data that the log files contain has been committed to the database. Circular logging is not recommended in production environments since by enabling it, you reduce drive storage space requirements.
But without a complete set of transaction log files, you cannot recover any data more recent than the last full backup, thus increasing the chances of database corruption.
However, you can use Exchange recovery tools such as Eseutil or Stellar Repair for Exchange to repair corrupt EDB files and restore mailbox items.
How Circular Logging Works?
When Circular Logging is disabled, every log file goes into the transactional log database, and no limit exists as to how large that database can get. When circular logging is enabled, the transactional log can only grow to one megabyte (1 MB) in size. When this limit has been reached, the first log file is overwritten automatically to keep the transactional log database from growing any larger.
The term “circular” arises from the fact that the set of log files starts to “rotate” once the disk space limit is reached, something like a LIFO (last-in, first-out) queue.
Circular logging is a feature of the Joint Engine Technology (JET) database, used by all versions of the Exchange Server that can be enabled or disabled by an administrator. In older versions such as Exchange Server 5.5 and earlier, circular logging was enabled by default However, with Exchange 2000 Server and continuing to Exchange 2010 and newer versions, it is disabled by default.
It is suggested that you should not enable circular logging on an Exchange database if you are doing backups as they will be inconsistent. This includes incremental backups as well. If you do however decide to enable it, then it is recommended to take a full back up immediately, after the databases have been mounted and you have disabled it again.
Circular Logging Considerations
When you enable circular logging, check following points-
- When the database is not replicated, it employs JET circular logging. To enable or disable circular logging in this scenario, a dismount and remount of the database is necessary. However, if the database is replicated, it utilizes continuous replication circular logging (CRCL). In this case, there is no need for the dismount and remount process when enabling or disabling circular logging.
- One should also consider that when enable circular logging, this might affect the backup as when enabled the service will not generate additional log files and instead it overwrites the files so that there is no build-up of transaction logs.
- When having a high availability setup, it is strongly not recommended to have circular logging enabled since the replication of the databases is based on log shipping and if a transaction log is missed and overwritten, it will cause huge inconsistency of data. As a result, when you enable the circular logging feature, the current log file isn’t overwritten and closed log files are generated for the log shipping and replay process in case of high availability. When having circular logging enabled, apart from the backup process, one would need to consider the restorability of the databases in case of a disaster. Since the recovery would mean to replay the transaction logs, since logs will be overwritten, this would not be possible.
Enabling Circular Logging Exchange Server
This can be done by using both PowerShell and the Exchange Admin Center (EAC).
Let us start with the EAC. Follow these steps:
- Open the Exchange Admin Center. After logging in, open the databases window.
- In the Mailbox database properties under Maintenance, tick the Enable circular logging checkbox.
- You will immediately be prompted that you would need to dismount and mount the database for the changes to take effect.
To enable circular logging by using PowerShell, you need to open the Exchange Management Shell and use the below command.
Set-MailboxDatabase -Identity “database1” -CircularloggingEnabled:$true
Alternatively, if you want to do it for all the databases, you can use the below command.
Get-MailboxDatabase | Set-MailboxDatabase CircularloggingEnabled:$true
After the databases have been dismounted and remounted, it is strongly suggested to perform a full backup of your Exchange database.
Use Circular Logging Without Backup
Let’s now look at a scenario where the Exchange backups have not been taking place and the volume where the database is stored is filling up. Once you hit that specific backpressure threshold, then you risk the fact that the Exchange Databases will not mount.
If you are in this situation, do not just jump and enable circular logging so you can get rid of the log files to reclaim the space they have used. Instead, follow these steps:
- Firstly, make a copy of the log and database directory, if you need to restore the database from a backup and replay the logs.
- If you do not have them, you can end up with data loss. You must try recovering your Exchange database from the backup.
- If you are running a large environment and want to make use of Circular Logging in the long run, it is advised to have three copies of the data if you want to go backup-less with Exchange Native Data Protection (NDP).
- The next thing is if you are running a Database Availability Group and you are on an Exchange version higher than SP1 for Exchange 2010, then you no longer need to dismount and mount the Exchange stores for this to take effect.
- You do not need to restart the Information Store Service. It takes a few seconds/minutes to perform this.
However, if you still have a problem after enabling circular logging in Exchange 2010, such as database dismount or Exchange database won’t mount, then you need to look at a third-party Exchange Recovery tool such as Stellar Repair for Exchange to repair the corrupt EDB file without the need for the log files.
The software can repair large .EDB files as well as multiple files, simultaneously. You can even open the offline .EDB file with the tool and just extract the data to another live database or Office 365 tenant, or even to a .PST file. The software supports all Exchange server versions such as 2019, 2016, 2013, 2010, 2007, 2003 , 2000 & 5.5.
FAQ
A. Circular Logging can be disabled from the Exchange Admin Center (EAC), from the Servers/Databases tab and from the maintenance mode, untick Enable circular logging. Alternatively, one can use the Exchange Management Shell (EMS) PowerShell command Set-MailboxDatabase example below.Set-MailboxDatabase "<database name>" -CircularLoggingEnabled $False
A. Circular logging should only be used when there is an issue as for recoverability of data and integrity of data, it is strongly suggested not to have the feature enabled. It should only be used when there is a reason why, example out of storage or to resolve a quick issue.
A. Yes, it is supported, and it will not affect the Database Availability Group (DAG), but it is strongly not recommended to enable circular logging in a production environment as this would cause restorability and integrity issues.
A. No, by default (as it is recommended), circular logging is disabled when creating a new Exchange Mailbox Database.
A. Yes, as mentioned in this article and by Microsoft enabling circular logging should only be enabled when troubleshooting storage issues as a last resort, or when having a test server which is not in production. Recovering data without all the transaction logs to replay them, will cause data integrity and data loss.
A. After an incremental application aware backup (with circular logging disabled), the Exchange Server will receive a message from the backup software that the database has been successfully backed up with the list of transaction logs which are committed. After this the Exchange Server can safely (automatically) purge the transaction logs. You should never manually delete the transaction logs. If the backup is supported and is application aware, the transaction logs should be purged automatically. If there is a huge load on the server and a big volume of transaction logs are generated, one should consider increasing the frequency of the backup.
