TABLE OF CONTENTS I have spent a significant amount of time delving into Exchange storage technology in previous chapters. This is because of the critical role the Exchange storage engine plays in Exchange server reliability and data integrity. In the last chapter, I looked at why Exchange servers fail and the dependencies that Exchange has on other services and infrastructure. In this chapter, we will dig a bit deeper into the Exchange database engine in hopes of revealing even more to you about how critical this storage mechanism is to your data. Once again, at the core of the store process (STORE.EXE) and Exchange s ESE lie the keys to backing up and recovering Exchange data.
With the changes and new options implemented for Exchange 2000 (and carried forward to Exchange Server 2003), the disaster-recovery API that Microsoft provides as part of Exchange underwent a bit of a facelift. The ESE database engine in Exchange Server has always made an on-line backup API available via two DLLs called ESECLIB2.DLL and ESEBACK2.DLL. (For Exchange 5.5, the DLLs are ESECLIB1.DLL and ESEBACK.DLL.) This API allows Exchange to stay operational and service users while backup operations are performed. In previous versions of Exchange, since there was only one ESE instance, restore operations were performed off-line (the server is down until the restore is complete).
However, since Exchange 2000/2003 provides multiple ESE instances (storage groups), recovery operations can be underway within one storage group while another storage group continues to service users. This means...
