Understanding the Exchange Database Structure
| An increasing number of wizards both in Microsoft and other vendor products is available for use in backing up and restoring Microsoft Exchange. These wizards are mini applications with easy-to-use graphical user interfaces (GUIs) that collect data and options and then automatically configure all required settings. Although these tools take the tedium and risk out of complex, multifaceted operations, it is important to understand what should be backed up, why it should be done, and the process by which it occurs. Without understanding these fundamentals it is almost impossible to plan and implement an efficient disaster recovery program and resolve or work around the issues. Moreover, such knowledge lends a framework and context to the various processes, techniques, and tools used for data recovery. This chapter concerns itself with the backup and restoration of Microsoft Exchange data, not the SBS server, Exchange Server, or its messaging components. Restoration of the server can be achieved through restoring a full system backup, a disk image, or a recovery reinstall of the Exchange Server using the /DisasterRecovery switch. The choice of backup media undoubtedly will be determined by the business's cost/benefit analysis together with the needs and the risk analysis. The media to be used, whether it be tape, hard disk, tape via hard disk, network addressed storage (NAS), or other, may affect the speed of backup and recovery, but it does not affect the basic method. The following are the main elements of Microsoft Exchange relating to data backup:
Exchange Storage GroupsBecause SBS 2003 contains Exchange Server 2003 Standard Edition, it can have only one storage group accessible by MAPI (Messaging Application Programming Interface) clients such as Microsoft Outlook. Table 13.1 lists the two stores created by default in an SBS 2003 installation.
On installation, these two stores are created as First Storage Group, as shown in Figure 13.1. Figure 13.1. SBS storage groups. In addition, you can create a Recovery Storage Group not accessible by MAPI clients but responsive to the Exchange API for the recovery of a Mailbox Store or its contents. In Microsoft Exchange 2003 Standard each storage group store consists of two databases that work together. These are Microsoft Extensible Storage Engine databases denoted by extensions .edb and .stm. It is important to keep these two files together at all times whether copying, moving, or backing up because they form parts of a whole. The internal schema for the .stm database is stored in the .edb database. A database signature, which is a 32-bit random number combined with the time that the database was created, is stored as a header in both files. If these files get out of synch, (as would be the case if one file were backed up one day and the other the next), the database will be unrecoverable. Extensible Storage Engine (ESE) DatabasesExchange Server 2003 uses ESE98, an Extensible Storage Engine (ESE), as its database engine. This was previously known as Joint Engine Technology (JET) Blue. The ESE is optimized for fast retrieval of data because this is the database's main function. Properties of ESE databases include
The ESE allows applications to store records, create indexes, and access those records in a variety of ways. You can find the location of the files that underlie the databases in the Mailbox Store Properties window, shown in Figure 13.2, and the Public Folder Store Properties window, shown in Figure 13.3. Figure 13.2. Property sheet showing the location of Mailbox Store database files. Figure 13.3. Property sheet showing the location of Public Folder database files. The .edb FileThe .edb database file contains folders, tables, messaging data, attachments, indexes, and metadata for MAPI messages and other items in the Exchange store such as the internal schema for the .stm file. By default, SBS creates the files as Priv1.edb and Pub1.edb for the respective Mailbox and Public Folder Stores. The .stm FileThe .stm database file (also known as the streaming file) contains Internet messages in their native format, such as MIME, which are written directly (streamed) to the file as a temporary storage point until the email is accessed by a client such as Outlook. By default SBS creates the files as Priv1.stm and Pub1.stm for the respective Mailbox and Public Folder Stores. Figure 13.4 illustrates how the .edb and .stm files together with the uncommitted transaction log files constitute the total Exchange data. Figure 13.4. Exchange current data. Log FilesAs Microsoft Exchange receives data, it simultaneously writes the information to a transaction log and to memory, until the load on the server allows for the data to be written to the database. If a database shuts down unexpectedly, uncommitted transactions can be restored by replaying the sequentially numbered transaction log files into the database. There are a series of transaction logs for each store. The sequential filenames prefixed with an E, have a .log extension, and contain a seven-character hexadecimal number: the letter and first two characters identifying the database. By default, each log file (except the temporary log currently being written tofor example, E00tmp.log) is exactly 5 megabytes (5,242,880 bytes) in size. When the temp file reaches 5 megabytes, it is saved as the next sequentially numbered transaction log. Each storage group also maintains two reserve log files, Res1.log and Res2.log. These are created to reserve disk space. If the drive containing the log files runs out of disk space, these will be used so that the database can be closed down in a consistent state without data loss. Figure 13.5 shows the transaction log location in the property sheet. Figure 13.5. Transaction log location.
Figure 13.6 shows the default log file directory MDBData and examples of the log files themselves. Figure 13.6. Default log file directory. Circular LoggingCircular logging is turned on by default in SBS 2003 installations to protect systems that have not configured an Exchange-aware backup, which deletes committed log files, from filling the hard drive partition. The SBS Backup Wizard disables circular logging on completion.
Because you cannot recover Exchange 2003 data that is more recent than the last Normal backup without a complete set of transaction logs, you should not have circular logging enabled in production environments. Circular logging is usually used for Public Folder Stores that contain Network News Transfer Protocol (NNTP) feeds (newsgroup posts) where roll-forward capabilities are not required. Checkpoint FileEach storage group has a checkpoint file. This file has a .chk extension with a prefix containing the letter and the two numbers that identify the storage group it and the logs refer to. This prefix is also the prefix of the related log files with the database identifier. The purpose of the checkpoint file is to track the progress of transaction logging and which logs have been committed to the database. Transaction log files accumulate over time, and this tracking can dramatically reduce the amount of time taken during a recovery because the logs need only to be rolled forward from the point indicated in the checkpoint file. Although the checkpoint file is not essential to a backup, ideally it should be backed up together with the ESE databases and the Exchange logs. TransactionsMicrosoft Exchange is transaction based. A transaction is defined as an inseparable set of database operations such as inserts, deletes, and updates that must be executed either in their entirety or not at all. A transaction should adhere to the following ACID properties:
The database engine commits data only when it can verify that it has successfully committed that data from memory to the transaction log file on disk. Figure 13.7 illustrates the transaction process. Figure 13.7. The transaction process. Typical Transaction Logging ProcessThe following list outlines the steps that take place in the Exchange message transaction process:
|
EAN: 2147483647
Pages: 253