Ransomware attackers specifically target and attempt to destroy backup systems to increase the probability of payment. Hardening your system is critical. Please ensure you have reviewed your platform security using the Security Hardening Checklist
Cohesity

COHESITY Documentation

Explore our documentation to get started, discover products & new features, access troubleshooting guides, register sources, platforms support.

Products
Data Security Alliance
Visit Cohesity.com
Demos
Support
Blogs
Developers
Partner Portals
Cohesity Community
© 2026 Cohesity, Inc. All Rights Reserved.
Terms of Use|
Privacy Policy|
Legal|
  1. Home
  2. Veritas NetBackup™ for Microsoft Exchange Server Administrator's Guide
  3. Configuring Exchange backup policies (non-VMware)
  4. About configuring a backup policy for Exchange Server
  5. About Exchange backups and transaction logs
Veritas NetBackup™ for Microsoft Exchange Server Administrator's Guide

About Exchange backups and transaction logs

For performance and recoverability, the Exchange database uses transaction logs to accept, track, and maintain data. All transactions are first written to transaction logs and memory, and then committed to their respective databases. Transaction logs can be used to recover Information Store databases in the event that a failure corrupted the database. The Information Store can have multiple separate databases, each of which has its own set of transaction logs.

Transactions are first written to the log file and then later written to the database. The effective database is a combination of the uncommitted transactions in the transaction log file and the actual database file. When the log file is filled with transaction data, it is renamed and a new log file is created. When the log file is renamed, the other renamed log files are stored in the same subdirectory. The renamed log files are named in a sequential numbering order, in hexadecimal.

The database transaction log for the Information Store is named EXXYYYYYYYY.log. XX is the database number (in hex). YYYYYYYY is the log file number (in hex). The size of the transaction logs is 1 MB.

After every 1 MB of transaction log data is written, a new log is created. The log is created even though the transaction data may not be committed to the database. There may be several transaction logs that contain uncommitted data, therefore they cannot be purged.

Transaction logs get committed to their database over time or when the services are brought down. Any transactions that existed in log files and not in the database file are committed to the database.

Do not manually purge log files. Instead, purge logs through the backup process. For backups of a replicated copy (DAG), the log truncation is scheduled. It starts with the active copy when Exchange has the resources to start truncation. It does not happen instantly after a backup as with non-replicated copies.

For information on how transaction logs are truncated, see the following topics:

See NetBackup for Exchange backup types.

See Adding schedules for Exchange Instant Recovery.

Feedback

Was this page helpful?
Previous

Configuring exclude lists for Exchange clients

Next

About configuring snapshot backups of Exchange Server

Feedback

Was this page helpful?