Section 20.1. Exchange Architecture

20.1. Exchange Architecture

To understand Exchange backup and recovery, you need a basic understanding of its architecture. We'll cover the design of the backend engine that makes Exchange what it is and then continue on to examine the details of how it works.

20.1.1. Database Structure

Exchange is essentially a specialized database for processing messages and similar content. In understanding how Exchange structures the underlying files and databases, it is useful to have an overview of the architecture. The principal database technology used by Exchange is called the Extensible Storage Engine (ESE) and is a specialized database based on Microsoft's Joint Engine Technology (JET). The current version of this JET database in use for Exchange Server 2000 and 2003 is ESE98. (Active Directory, which is tied closely with Exchange, uses ESENT.)

While there are differences between different versions of Exchange, most of the information presented in this chapter is valid for 2003 and 2000 at a minimum. All screenshots reflect configuration parameters taken from Exchange Server 2003. Any major differences are noted.

At this writing, Microsoft is still maintaining that it plans at some point to use SQL Server technology as the underlying database for Exchange. When that will happen is left as an exercise for the reader.

The ESE database stores its information in files. Two files in particular, .edb and .stm files, are tied together to form a store. Stores can be grouped together to form a storage group. A storage group maintains a common set of transaction logs for all stores within the storage group. This is illustrated in Figure 20-1.

Figure 20-1. Common transaction logs for all stores within the storage group

Now that we have a basic understanding of how things are arranged inside an Exchange Server, we can look at the details of each component.

20.1.2. Extensible Storage Engine

Beneath Exchange is a transactional database similar to other commercial databases. The ESE provides all the usual Data Manipulation Language features you would expect in a high-powered database: inserts, updates, selects, and deletes. These DML statements are all wrapped into atomic units called transactions. Transactions are the basis for ensuring that database integrity remains intact by providing a means for rolling back a group of statements if a problem arises or committing the transaction otherwise.

To demonstrate the transactional nature of Exchange, let's walk through the steps for a simple message move between the inbox and another folder located on the server (not a local .pst file). Because the ESE works with transactions in snapshot isolation mode, every transaction is guaranteed a unique view of the database during the operation. To begin the transaction, the commands to erase the message from the inbox are written to an in-memory structure called the version store. If this step is successful, the commands to write the same message to the second folder are written in the version store. After these steps have completed without error, the transaction log is played back, actually causing the data move to physically take place. If no errors occur at this point, the transaction is committed. If there are errors, the transaction is rolled back, and no changes are made.

20.1.3. Stores

Now that we know how Exchange accesses data, we need to know where it stores this data. Exchange maintains its databases in objects called stores. There are two types of stores, mailbox stores and public folder stores. Each store consists of two files, rich-text database (.edb) files and native content database (.stm) files. .edb files are specialized to store Messaging Application Programming Interface (MAPI) messages, checksums for the .edb and .stm files, and tables used by the store.exe process. .stm files store native Internet-formatted content such as Multipurpose Internet Mail Extensions (MIME) content. While .edb files handle most of the data, the primary purpose of the .stm database file is to support non-MAPI clients. Figure 20-2 shows where the store filenames are located in a default Exchange install. You can see that this is the default mailbox store, and its associated .edb and .stm files are created under c:\Program Files\Exchsrvr\mdbdata\ in this example. These locations are the same for 2000 and 2003.

Figure 20-2. Location store filenames

All Exchange installations have a mailbox store and a public folder store. The mailbox store contains user private data whereas a public folder store contains public or shared information. The database files in the default mailbox store are named priv1.edb and priv1.stm; the database files for the public folder store are named pub1.edb and pub1.stm. With Exchange Server 2003 Standard Edition (pre-Service Pack 2) and Exchange 2000, these databases can hold 16 GB. Standard Edition with SP 2 is increased to 75 GB per store. In Exchange Server 2003 and 2000 Enterprise Edition, the databases are limited to 16 TB. Figure 20-3 shows the default storage groups and stores. For reference, the name of the server in these examples is EXCH2003.

Figure 20-3. Default storage groups and stores