Backup and DR
Microsoft Exchange Log Truncation Guide
In this guide, we explain how to purge Microsoft Exchange logs. Doing so is useful in the event that you are running out of disk space for storing logs, and there is no way to create a full regular backup.
Microsoft Exchange Server uses a write-ahead approach to commit new data to the database. This means that when you create new Exchange items (emails, calendar events, etc.), data is written to the log file. After some time, these logs are committed to the database, and Exchange then truncates logs by marking them as recyclable.
These log files consume storage space. Normally, the logs are truncated (which makes them shorter and saves space) whenever you run a full backup of Exchange. However, sometimes you cannot run a full backup. Fortunately, it is still possible to truncate Exchange logs in order to save space.
Why Do You Need to Truncate Exchange Logs Without a Backup?
Performing manual transaction log truncation allows you to keep your environment stable in the following situations:
- The backup software failed to perform a backup job, and logs remain untouched. You may be forced to shrink storage space consumed by Exchange logs if you need additional time to find the issue.
- If you run the Exchange test environment you can save storage space by deleting unnecessary log files. Microsoft suggests using circular logging for this scenario, but you may have reasons not to do that.
We strongly recommend against using circular logging because, in the case of failure of the host disk, you will only be able to restore data to the point of the last backup. All subsequent changes will be lost. You should delete log files manually only in a dire situation, or when running a non-production environment.
Further reading Microsoft Exchange: Exporting Mailboxes to PST
Remember that you cannot perform an incremental backup of Exchange Server if transaction logs were deleted manually.
How to Truncate Exchange Logs Manually
There are three basic ways to truncate Exchange log files manually:
- [Does not require DB dismount] Simulate the backup process by using a VSS writer. This is similar to a standard backup scenario, but you actually do not capture the data and do not wait for the backup to be completed.
- [Requires DB dismount] Dismount the database to trigger commits for all remaining logs, then remove the log files manually.
- [Does not require DB dismount], is potentially dangerous. Using File Explorer to remove log files that you are sure to have been committed.
Now, let’s explore each of these methods in detail.
Backup Simulation to Trigger Exchange Logs Truncation
This is the simplest approach, and it works as long as your Exchange server does not have VSS-related errors. Basically, you can run a backup simulation if you have previously not faced any backup-related errors on the server, including third-party backup tools.
- Open the CMD console using elevated privileges (in other words, run as Administrator), and then enter the following command: Diskshadow
- Next, you need to add disk volumes that store Exchange database and logs: add volume C:
We assume that “C:” is a single system drive containing all server data. - Create a backup session: begin backup
- And then run VSS writer with the command: create
- After VSS prepares the volume, you will see something similar to the screenshot below:
- To tell the Exchange that the simulated backup was completed, run this command: end backup
- If this simulated backup was completed successfully and recognized by the Exchange server, you will see an event with ID 9780 in the Windows Event Viewer:
Now your log files will be safely truncated after the next log file creation.
Removing Logs Manually After Database Dismount
Exchange normally commits all remaining log files when running the database dismount procedure. It, therefore, allows you to make sure that log files that you want to delete are already in the database. You can perform this procedure using the following steps:
1 Open Exchange Management Console and proceed to Organization Configuration - Mailbox.
2 Select the database that contains the log files you want to delete and choose the Dismount Database in the context menu:
3 This step is optional - it just ensures that the database was dismounted with no issues. Open CMD console and type the following command:
eseutil /mh <Path_to_.EDB_file>
4 Replace “ Path_to_.EDB_file” with a full path to your database. It is simple to accomplish by dragging the “.EDB” file from Files Explorer to the CMD window.
5 If the database was dismounted successfully, you will see a “Clean Shutdown” state in the command output:
6 Now it is safe to delete all LOG files associated with this database using File Explorer . Then you can simply mount the database using Exchange Management Console - Organization Configuration - Mailbox.
Removing Logs Manually WITHOUT Database Dismount
This is the most dangerous approach since it does not provide a way to check if the deleted logs were actually committed to the database before deleting them. Instead, we just assume that Exchange has committed all log files older than a few days after the creation date.
Please use this approach only if:
- You cannot perform VSS simulated backups using the first approach described above.
- There is absolutely no way to dismount the database to commit all logs.
- You don't need to be concerned about the loss of data created since the last full backup.
Here is how to remove log files with no database dismount:
1 Open File Explorer and navigate to the folder that contains your database:
2 Now you need to sort folder contents by date. Click the "Date modified" column:
3 Select all LOG files older than N days and delete them. The higher the value of N, the lower the chance of data corruption. We suggest selecting at least one week.
4 You can check your database integrity state by running eseutil /mh <Path_to_.EDB_file> command, which works only after the database dismount.
Conclusion
We've provided tips on how to truncate Exchange logs manually to avoid running out of storage space. The approaches described above are not recommended for use in your daily routine; they are disaster-recovery solutions that are useful in the event that something goes completely wrong.
Of course, it is always better to avoid a problem than to deal with the consequences after the problem occurs. That is why we suggest implementing Exchange backup using Windows Server Backup or Exchange-aware third-party solutions.
Simple. Reliable.
