The following is tip #8 from "20 tips on protecting and recovering Exchange data in 20 minutes," excerpted from...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
the book, "Mission Critical Microsoft Exchange 2003" (Digital Press, a division of Elsevier, Copyright 2004). For more information about this book and other computing titles, please click here. Return to the main page for more tips on this topic.
During a full backup operation, the transaction logs must be stored to the backup set next. Remember from above that the checkpoint is halted at the beginning of backup (for a full backup). Even though the checkpoint is halted, transactions continue to be written to the log files, and dirty pages from the database cache in memory are flushed to disk during the backup operation.
Note that with Exchange 2000 SP2 and later, dirty pages that cause patching operations are not flushed; this is how Microsoft was able to get rid of the patch files in SP2. In order to back up the log files, the backup application requests a list of log files (and patch files if applicable) from ESE (via the HrESEBackupGetLogAndPatchFiles API call). When ESE receives this call, it closes the current log file as the next log generation and opens a new E0n.log. In the case of a full backup, ESE then returns a list of log files to the backup application that starts with the current log generation where the checkpoint is halted and ends with the generation of the log file that was just closed (E0n.LOG -- 1). In the case of an incremental or differential backup, ESE returns a list beginning with the oldest generation on disk up to the most recent log file closed (E0n.LOG -- 1). During incremental, differential, and copy backup operations, only log files are backed up and the checkpoint is not halted. Using this list of files, the backup application can open file handles to the logs and copy them to the backup set (using the HrESEBackupOpenFile, HrESEBackupReadFile, and HrESEBackupClose-File). During these operations, ESE also ensures that no log generation is missing from the sequence passed to the backup application. This operation will continue until all relevant log and patch files have been written to the backup set by the backup application.
Truncating the logs
Since the log files have been stored to a backup set, they are not needed on disk. ESE will then truncate the log files during full and incremental backup operations. When ESE receives the call from the backup application to truncate the logs (HrESEBackupTruncateLog API call), it will truncate the log files on disk. Which log files ESE truncates is determined by the lowest generation of (1) the checkpoint log file generation, or (2) the log generation listed in the database header (you can view this using the ESEUTIL program with the /MH parameter) for the current full backup.
Once the log files are truncated, the backup operation is complete and the backup set is closed. At this point, ESE can return to normal operations and allow the checkpoint to advance forward. To complete the backup operation, the backup application calls HrESEBackupInstanceEnd to end operations for that instance of backup. At this point ESE is able to allow the checkpoint for the storage group instance being backed up to advance and normal database operations to recommence. Finally, the backup application calls HrESEBackupEnd to disconnect from the information store process allowing it to return to normal operations.
Get more "20 tips on protecting and recovering Exchange data in 20 minutes". Return to the main page.
About the author: Jerry Cochran is a contributing editor for Windows IT Pro and Exchange & Outlook Administrator and a group program manager for Microsoft. He is the author of Mission-Critical Microsoft Exchange 2000 (Digital Press).