In this article, we will cover the topic of how to purge Exchange 2010 logs in “emergency” cases. Topics covered are useful in case you need to free up drive space by deleting Exchange log files, and there is no way to create a full regular backup instead.
Microsoft Exchange Server uses a write-ahead approach to commit new data to the database. It means that when you, for example, create the new email, data will be written to the log file; after some time, these logs are committed to the DB and then Exchange truncates logs by marking them as recyclable.
These log files consume the storage space and the truncation should be triggered by running Exchange full backup. But sometimes you can not use the recommended approach.
Table of contents
Why Purge Exchange 2010 Logs Without a Backup
Manual transaction logs truncation allows you to maintain the environment in cases, as follows:
- The backup software failed to perform backup job thus leaving logs untouched. You may be forced to shrink storage space consumed by Exchange logs if you need additional time to find the issue.
- When 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 so.
- You need to shrink log files once. Exchange downtime is necessary if enabling or disabling the Circular Logging feature.
Note: the main point here is that you should not use our suggestion as a regular solution to maintain Exchange volume consumption. 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.
Purging Exchange 2010 Logs
Here are three simple ways to truncate Exchange log files manually:
- [Does not require DB dismount] Simulate backup process by using VSS writer. It is like 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 committing all remaining logs, then remove the log files manually.
- [Does not require DB dismount, is potentially dangerous] Removing those log files that are surely committed, using File explorer.
Let’s cover these solutions in detail.
Backup Simulation to Trigger Exchange Logs Truncation
This is the simplest approach that works if your Exchange server does not experience 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.
- Run CMD console using elevated privileges (run as Administrator), and then enter the following command:
- Next, you need to add disk volumes that store Exchange database and logs:
add volume C:
“C:” is a single system drive containing all server data.
- Create a backup session:
- And then run VSS writer by the command:
After VSS prepare the volume, you will see something similar to the screenshot below:
- To tell the Exchange that the “backup” was completed, run this command:
If 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 DB Dismount
Exchange normally commits all remaining log files when running database dismount procedure. So, it allows you to make sure that log files that you want to delete are already in the DB.
- Open Exchange Management Console and proceed to Organization Configuration - Mailbox.
- Select the database containing the log files you want to delete, and choose Dismount Database in the context menu:
- This step is optional - it just ensures that DB was dismounted with no issues. Open CMD console and type the following command:
eseutil /mh <Path_to_.EDB_file>
Replace “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.
If the DB was dismounted successfully, you will see “Clean Shutdown” state in the command output:
- 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 DB Dismount
This is the most dangerous solution since it does not provide a way to check if the deleted logs are committed to the DB. We just assume that Exchange has committed all log files older than a few days after creation date.
Please use this approach only if:
- You cannot perform VSS “fake” backup from the first solution.
- There is absolutely no way to dismount the database to commit all logs. Though, it is hard to imagine for non-production environments.
- You don't need to be concerned about the loss of the data created from the last full backup.
Here is how to remove log files with no DB dismount:
- Open File Explorer and navigate to the DB containing folder:
- Now you need to sort folder contents by date - click Date modified column:
- Select all LOG files older than N days and delete them. The more N you choose, the less chance of data corruption. We suggest selecting at least one week.
You can check your database integrity state by running
eseutil /mh <Path_to_.EDB_file> command only after the database dismount.
Now we have covered the simplest ways to maintain your drive consumption by helping Exchange to truncate logs. Approaches described are not recommended to use in your daily routine - these are disaster solutions useful if something goes completely wrong.
It is always better to avoid a problem than to solve the consequences. That is why we suggest implementing of Exchange backup using Windows Server Backup or any other third-party tool. If you do not have one yet - try our CloudBerry Backup for MS Exchange and check whether it meets your business needs.
You should also check our item-level recovery feature allowing the recovery of individual emails with no entire DB recovery.