Veritas NetBackup™ for Microsoft Exchange Server Administrator's Guide
- Introducing NetBackup for Exchange
- Installing NetBackup for Exchange
- Snapshot Client configuration and licensing requirements for Exchange snapshot backups
- Configuring Exchange client host properties
- Configuring the account for NetBackup for Exchange operations
- Configuring the Exchange hosts
- Configuring Exchange Granular Recovery
- About Exchange backups and Granular Recovery Technology (GRT)
- About installing and configuring Network File System (NFS) for Exchange Granular Recovery
- About configuring Services for Network File System (NFS)
- Configuring Exchange backup policies (non-VMware)
- About configuring a backup policy for Exchange Server
- Adding schedules to a NetBackup for Exchange policy
- Adding backup selections to an Exchange policy
- About configuring snapshot backups of Exchange Server
- About configuring Instant Recovery backups of Exchange Server
- Configuring an Exchange snapshot policy with Instant Recovery
- Performing backups of Exchange Server, mailboxes, and public folders
- Performing restores of Exchange Server, mailboxes, and public folders
- About restoring Exchange snapshot backups
- About restoring individual Exchange mailbox and public folder items
- About redirecting a restore of Exchange mailbox or public folder objects to a different path
- Protecting Exchange Server data with VMware backups
- About protecting an application database with VMware backups
- About configuring a VMware backup that protects Exchange Server
- About configuring a VMware backup that protects Exchange Server, using Replication Director
- Troubleshooting backups and restores of Exchange Server
- About NetBackup for Exchange debug logging
- Viewing Event Viewer logs on an off-host Exchange server
- About NetBackup status reports
- Troubleshooting Exchange restore operations
- Troubleshooting DAG backups and restores
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: