![\"CTA\"](\"https:\/\/no-cache.hubspot.com\/cta\/default\/5442029\/565257f1-bf91-414b-823e-d9b7a213232b.png\")
<\/a><\/span><\/span>\n<\/p>\n
Why Do You Need to Truncate Exchange Logs Without a Backup?<\/h2>\n
![\"Exchange](\"https:\/\/www.msp360.com\/resources\/wp-content\/uploads\/2019\/02\/log-truncation.png\")
\nPerforming manual transaction log truncation allows you to keep your environment stable in the following situations:<\/p>\n
- \n
- 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.<\/li>\n
- If you run the Exchange test environment you can save storage space by deleting unnecessary log files. Microsoft suggests using circular logging<\/a> for this scenario, but you may have reasons not to do that.<\/li>\n<\/ul>\n
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.<\/p>\n
Further reading<\/span> Microsoft Exchange: Exporting Mailboxes to PST<\/a><\/p>\n
\u00a0<\/span>![\"CTA\"](\"https:\/\/no-cache.hubspot.com\/cta\/default\/5442029\/09b0265a-a5a1-41bd-9699-418982b48e90.png\")
<\/a><\/span><\/span><\/div>\nRemember that you cannot perform an incremental backup of Exchange Server<\/a> if transaction logs were deleted manually.<\/p>\n
\n\nFREE WHITEPAPER<\/div>\nThe Ultimate MSP's Guide to MS Exchange Server Backup and Recovery<\/div>\nTips, tricks, and best practices<\/div>\n![\"CTA\"](\"https:\/\/no-cache.hubspot.com\/cta\/default\/5442029\/36bd5884-cacf-4ed7-9356-d3488a0f543e.png\")
<\/a><\/span><\/span>\n<\/div>\n![\"WP](\"https:\/\/www.msp360.com\/resources\/wp-content\/uploads\/2019\/07\/Exchange_WP_icon-1.png\")
<\/div>\n<\/div>\n<\/a> How to Truncate Exchange Logs Manually<\/h2>\n
There are three basic ways to truncate Exchange log files manually:<\/p>\n
- \n
- [Does not require DB dismount]<\/strong> 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.<\/li>\n
- [Requires DB dismount]<\/strong> Dismount the database to trigger commits for all remaining logs, then remove the log files manually.<\/li>\n
- [Does not require DB dismount]<\/strong>, is potentially dangerous. Using File Explorer to remove log files that you are sure to have been committed.<\/li>\n<\/ul>\n
Now, let\u2019s explore each of these methods in detail.<\/p>\n
Backup Simulation to Trigger Exchange Logs Truncation<\/h3>\n
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.<\/p>\n
- \n
- Open the CMD console using elevated privileges (in other words, run as Administrator), and then enter the following command: Diskshadow<\/b><\/li>\n
- Next, you need to add disk volumes that store Exchange database and logs: add volume C:<\/b>
\nWe assume that \u201cC:\u201d is a single system drive containing all server data.<\/li>\n- Create a backup session: begin backup<\/b><\/li>\n
- And then run VSS writer with the command: create<\/b><\/li>\n
- After VSS prepares the volume, you will see something similar to the screenshot below:
\n![\"Database](\"https:\/\/www.msp360.com\/resources\/wp-content\/uploads\/2018\/11\/image4-1.png\")
<\/li>\n- To tell the Exchange that the simulated backup was completed, run this command: end backup<\/b><\/li>\n
- 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:
\n![\"Exchange](\"https:\/\/www.msp360.com\/resources\/wp-content\/uploads\/2018\/11\/image3-1.png\")
<\/li>\n<\/ul>\nNow your log files will be safely truncated after the next log file creation.<\/p>\n
Removing Logs Manually After Database Dismount<\/h3>\n
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:<\/p>\n
\n1<\/var> Open Exchange Management Console and proceed to Organization Configuration - Mailbox.<\/p>\n
2<\/var> Select the database that contains the log files you want to delete and choose the Dismount Database<\/b> in the context menu:
\n![\"Dismounting](\"https:\/\/www.msp360.com\/resources\/wp-content\/uploads\/2018\/11\/image1-1-1024x737.png\")
<\/p>\n3<\/var> This step is optional - it just ensures that the database was dismounted with no issues<\/i>. Open CMD console and type the following command:<\/p>\n
eseutil \/mh <\/b> <Path_to_.EDB_file> <\/i><\/p>\n
4<\/var> Replace \u201c Path_to_.EDB_file\u201d <\/i> with a full path to your database. It is simple to accomplish by dragging the \u201c.EDB\u201d file from Files Explorer to the CMD window.<\/p>\n
5<\/var> If the database was dismounted successfully, you will see a \u201cClean Shutdown\u201d state in the command output:
\n![\"\u201cClean](\"https:\/\/www.msp360.com\/resources\/wp-content\/uploads\/2018\/11\/image5-1.png\")
<\/p>\n6<\/var> 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.<\/p>\n<\/div>\n
Removing Logs Manually WITHOUT Database Dismount<\/h3>\n
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.<\/p>\n
Please use this approach only if:<\/p>\n
- \n
- You cannot perform VSS simulated backups using the first approach described above.<\/li>\n
- There is absolutely no way to dismount the database to commit all logs.<\/li>\n
- You don't need to be concerned about the loss of data created since the last full backup.<\/li>\n<\/ul>\n
Here is how to remove log files with no database dismount:<\/p>\n
\n1<\/var> Open File Explorer and navigate to the folder that contains your database:
\n![\"File](\"https:\/\/www.msp360.com\/resources\/wp-content\/uploads\/2018\/11\/image6.png\")
<\/p>\n2<\/var> Now you need to sort folder contents by date. Click the \"Date modified\" column:
\n![\"Date](\"https:\/\/www.msp360.com\/resources\/wp-content\/uploads\/2018\/11\/image2-1.png\")
<\/p>\n3<\/var> 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.<\/p>\n
4<\/var> You can check your database integrity state by running
<\/code> eseutil \/mh <\/b> <Path_to_.EDB_file> <\/i> command, which works only after the database dismount.<\/p>\nDiscover more resources from MSP360<\/h3>\n
Streamlining IT infrastructure demands expertise in system optimization, cloud services, and data protection. For Linux administrators, tasks like <\/span>resizing partitions<\/span><\/a> and adopting a robust <\/span>Linux patching management<\/span><\/a> approach are essential for security and efficiency. In AWS environments, securely accessing services by <\/span>finding your AWS Access Key ID and Secret Access Key<\/span><\/a> and understanding the differences between <\/span>Amazon EC2 and S3<\/span><\/a> are critical for resource allocation. For database management, executing <\/span>SQL Server transaction log backups<\/span><\/a> and mastering <\/span>SQL Server backup and restore<\/span><\/a> processes safeguard data integrity. Additionally, e<\/span>nsuring Windows reliability by <\/span>enabling the recovery environment<\/span><\/a> mitigate risks. MSP360\u2019s comprehensive guides empower IT professionals to maintain resilient systems.<\/span><\/p>\n<\/div>\n
Conclusion on how to truncate exchange logs without a backup<\/h2>\n
![\"Exchange](\"https:\/\/www.msp360.com\/resources\/wp-content\/uploads\/2019\/02\/exchange-first-pic.png\")
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.<\/p>\nOf 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.<\/p>\n","protected":false},"excerpt":{"rendered":"
In this guide, we explain how to truncate exchange logs on Microsoft Exchange. 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.<\/p>\n","protected":false},"author":59,"featured_media":44423,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[886,878],"tags":[928],"class_list":["post-33633","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-backup-and-dr-guides","category-msp-university","tag-exchange-backup"],"acf":[],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/www.msp360.com\/resources\/wp-json\/wp\/v2\/posts\/33633","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.msp360.com\/resources\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.msp360.com\/resources\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.msp360.com\/resources\/wp-json\/wp\/v2\/users\/59"}],"replies":[{"embeddable":true,"href":"https:\/\/www.msp360.com\/resources\/wp-json\/wp\/v2\/comments?post=33633"}],"version-history":[{"count":5,"href":"https:\/\/www.msp360.com\/resources\/wp-json\/wp\/v2\/posts\/33633\/revisions"}],"predecessor-version":[{"id":60085,"href":"https:\/\/www.msp360.com\/resources\/wp-json\/wp\/v2\/posts\/33633\/revisions\/60085"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.msp360.com\/resources\/wp-json\/wp\/v2\/media\/44423"}],"wp:attachment":[{"href":"https:\/\/www.msp360.com\/resources\/wp-json\/wp\/v2\/media?parent=33633"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.msp360.com\/resources\/wp-json\/wp\/v2\/categories?post=33633"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.msp360.com\/resources\/wp-json\/wp\/v2\/tags?post=33633"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
- Next, you need to add disk volumes that store Exchange database and logs: add volume C:<\/b>
- [Requires DB dismount]<\/strong> Dismount the database to trigger commits for all remaining logs, then remove the log files manually.<\/li>\n
- [Does not require DB dismount]<\/strong> 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.<\/li>\n