Completing the restore and running hard recovery |
 |
By Jerry Cochran
01 Nov 2004 | SearchExchange.com |
|
|
The following is tip #15 from "20 tips on protecting and recovering Exchange data in
20 minutes," excerpted from 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).
|
|
|
|
