CloudBerry Lab Resources
Get started with cloud backup and management solutions
MS Exchange Log Truncation

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 your logs in order to save space.

To get more information on MS Exchange backup and recovery techniques, refer to our comprehensive guide.

Further reading Exchange Backup and Recovery

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.

Remember that you cannot perform an incremental backup 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 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.

1Open the CMD console using elevated privileges (in other words, run as Administrator), and then enter the following command:
Diskshadow

2Next, 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.

3Create a backup session:
begin backup

4And then run VSS writer with the command:
create

5After VSS prepares the volume, you will see something similar to the screenshot below:

6To tell the Exchange that the simulated backup was completed, run this command:
end backup

7If this simulated backup was completed successfully and recognized by 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:

1Open Exchange Management Console and proceed to Organization Configuration - Mailbox.

2Select the database that contains the log files you want to delete and choose Dismount Database in the context menu:

3This 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>

4Replace “Path_to_.EDB_file” with a full path to your database. It is simple to accomplish by dragging “.EDB” file from Files Explorer to CMD window.

5If the database was dismounted successfully, you will see “Clean Shutdown” state in the command output:

6Now 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:

1Open File Explorer and navigate to the folder that contains your database:

2Now you need to sort folder contents by date. Click the "Date modified" column:

3Select 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.

4You 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 explained the simplest ways to avoid running out of storage space by truncating Exchange logs manually. 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.

CloudBerry offers an easy-to-use and reliable solution for MS Exchange Server backup to the cloud or local storage.

Compression and encryptionCompression and Encryption

Compression allows you to reduce storage space (and thus save money) while improving backup time. With AES-256 encryption, you can be sure that all your backup files are protected.

Cloud and localCloud and Local

CloudBerry Backup allows you to store your backups on local storage and any of more than 20 cloud storage providers, including Amazon S3 and Amazon Glacier, BackBlaze B2, Wasabi Hot Storage, Microsoft Azure, Amazon Cloud Drive, Microsoft OneDrive, Google Drive.

Flexible retention and recoveryFlexible Retention and Recovery

Store as many versions as you need for as long as you need with flexible retention settings. Recover the latest version or restore to the point in time of your choosing.

Bare-metal recovery from USB or ISO fileEmergency Recovery for Windows Server

Protect and restore entire servers using CloudBerry’s image backup and bare-metal recovery features in case of a system or hardware crash.

Related Articles