Exchange Server 2010 customers sometimes ask why their server disk drive is filling up with log files. Usually they are referring to the transaction log files created by the mailbox databases.
Update February 2013 – there is a specific issue with iOS 6.1 that causes excessive log generation on Exchange servers. Click here for more details.
Each Exchange 2010 mailbox database comprises two main parts:
- the transaction log files
- the database file itself
The folder containing the log files will look something like this.
A best practice for Exchange 2010 mailbox servers is to store the database and transaction log files on completely separate disks. This is to protect the server from data loss if one disk or the other has a failure.
The way this works is that each database change is written to a memory buffer and also recorded in a transaction log file. Periodically the memory buffer information is also written to the database file. When this occurs a checkpoint is updated that tells the server which transaction log entries have and have not been written to the database yet.
If the server was to unexpectedly restart, the database comes online in a “dirty shutdown” state and the checkpoint is used to tell the server which transaction log entries need to be replayed into the database to recover the information that was lost in the memory buffer when the server failed.
Over time these transaction logs will grow, because of course the mailbox database is continually changing as new mail arrives in mailboxes (as just one example). Eventually the log files will fill up the disk if they are not removed.
To remove the transaction log files the database needs to be backed up. When an Exchange Server database is backed up by a proper application-aware backup product, after the backup is finished the backup program will issue a command to VSS (Volume Shadow-copy Service) on the server that the backup was successful and to go ahead and truncate the transaction logs.
The server then proceeds to remove the transaction log files up to the nearest checkpoint prior to the backup commencing. Because the database can continue to change and write new transaction log files while a backup is in progress it is not unusual for multiple transaction log files to still be present after a backup has completed. However most of them will be removed, and regular backups are the method by which transaction logs can be kept from consuming all free disk space on the server (as well as the obvious benefit of having your Exchange databases safely backed up).
So if your Exchange Server disk is being filled up by transaction log files, the issue is likely to be one of the following:
Cause: You aren’t backing up the mailbox server
Solution: Back up the mailbox server with a proper Exchange Server application-aware backup product. There are commercial products available for this such as Symantec Backup Exec or you can use the built-in Windows Server Backup for the task.
Cause: You’re using the wrong type of backup
Solution: Make sure you’re running a backup job type that will truncate the logs. Full and Incremental backups will truncate the transaction log files, whereas Differential and Copy will not.
Cause: The backup is not completing successfully
Solution: Check your backup product for log file entries that indicate what the issue is.
Cause: The backup is completing successfully but transaction logs are not truncating
Solution: Check the Application Event Log on the mailbox server for errors with the log truncation process.