The following is tip #15 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.
Once all the backup sets that are necessary for the current recovery operation are copied, the backup application is ready to complete and terminate its activities and turn control back to the store process. The backup application calls HrESERestoreComplete and HrESERestoreClose to signal ESE that it is time to take over. At this point, you would think that the storage group that owns the database being recovered would take over and complete the recovery operation. However, this is not the case. The store process instantiates a separate ESE storage group specifically for the purpose and duration of completing the recovery operation. This recovery storage group then Takes over and performs the hard recovery operation. Hard recovery is the process of applying patch files to the database, replaying log files from the backup set (located in the temporary directory), and replaying log files from the production log file directory. Once hard recovery completes successfully, the database is ready to be mounted and made available for users. It is important to note here that hard recovery can be performed manually using the ESEUTIL program (/CC switch) if you are performing simultaneous restores or hard recovery did not complete automatically for some reason (like if you forgot to check the "last backup set" checkbox after restoring the last set of log files). Once automatic hard recovery is completed, the recovery instance deletes the files in the temporary directory, terminates, and turns control over to the storage group that owns the database for normal operations. The owning storage group can then mount the database and begin to apply user transactions.
Too often, Exchange disaster-recovery operations (backup and restore) are trivialized. However, it is of paramount importance that we as Exchange administrators understand exactly how these operations work and the impact they have on our ability to meet service level agreements for our Exchange deployments. This in-depth drill down into the internals of Exchange's ESE and how it exposes these capabilities and performs these operations will serve you in your quest to provide the highest levels of availability for Exchange.
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).