Utilizing Microsoft Exchange 2003 components for disaster recovery

Microsoft Exchange Server 2003 is used in the smallest mom-and-pop shops to the largest enterprise-class clients. While it is available via a multitude of sales channels, and while it exists in a large number of companies, it is often considered a confusing and hard to manage system from an administrative viewpoint. Because of that, disaster recovery (DR) for this system is often either totally overlooked, or worse, done improperly.

Over the next few weeks, I'll take a look at various components to DR strategies centered around Exchange Server 2003, and tell you how you can safeguard what has quickly become a vital communications component of many organizations. I'll begin by explaining the basics of the major files that must be protected in order to perform any sort of Exchange DR later on.

Exchange is, in effect, a large database engine that contains primarily log files and data files (plus some auxiliary files that perform various functions). The database technology in use here is called JET, or Joint Engine Technology, and it has been in use within Exchange for many versions. Learning about the database components is key to properly protecting the overall system. In short, if the database components don't mount when Exchange tries to start up, the Exchange system will not respond properly.

Understanding the Exchange database components
In Exchange, databases are arranged into groups called Storage Groups (SG). Each SG contains a complete database set as a single logical unit, and the version of Exchange you are using determines how many SGs you can have. Exchange Server 2003 can have one SG, while Exchange Server 2003 Enterprise Edition can host up to four per server. Keep in mind that you can have one SG in addition to these. It is called a Recovery Storage Group, and it is not useable for normal operations. (I'll dive into more detail on the Recovery Storage Group in a later article.) Each SG can contain between one and five Stores, which can contain mailbox data, referred to as Private Stores—or Public Folder data, often called Public Stores.

The combination of a SG and all its data stores is a logical database unit, and can be treated as such for the purposes of backup and restoration. Each SG has a series of log files, which record all transactions that take place, and a set of database files that hold the actual data. In addition, Exchange uses other auxiliary files—such as CHK files—to cross-check itself and aid in recovery without time-consuming utilities having to be run.

It is important to recognize that the database files are split into two types: EDB file extensions contain all Outlook formatted MAPI data. STM files contain all other e-mail data, especially attachments and other "non-message" components that many modern e-mails contain.

In short, you will need to back up all of these database components. Without them, you cannot restore an Exchange server back into an operational state after a disaster.

Methods for backing up Exchange files
First, you can back up all the flat files that the database components are stored in. Doing so is very effective, but it has a few drawbacks. Primarily, you'll have to take Exchange offline to back up the files, as they are locked by the Exchange system while the services are up and running. In addition, this method doesn't remove log files which are already committed to the database systems. This means that you'll be backing up unnecessary logs, and that you'll never remove them from the disk, where they will use up more and more space over time.

The second method is to obtain an Exchange backup agent from a backup tool vendor. One such agent comes free with the Exchange server install, and enhances the functionality of the native NTBackup tools on the Windows server. Any of these tools will allow you to back up an Exchange system while it is online, though with a definite performance hit during the backup process itself. This is why Exchange backups are typically done while few people are using the system—otherwise known as the "backup window." The backup window is always going to be preferable to taking the system offline altogether, as is necessary for the flat-file backup. The differences between the free version and those that you buy from a vendor usually involve extra features that you may or may not want, but all will do the basic duties of backing up databases and cleaning up logs.

A third option is to use some form of replication software to get the data to another disk or another machine. These systems typically work very well, though you must be sure the tool in question can ensure that the data is committed to both sides identically, or you may lose database integrity, rendering the data useless. Many such tools can also allow you to back up the flat files off the second server, making backups easier, but not handling log management as mentioned above. Which of these options works best will be a matter of budget and need in your organization; a combination of tools is often the best option to utilize.

Finally, depending on what method you plan to use for your restore, you may also wish to back up configuration files and other segments of Exchange along with the databases. The database, log, and CHK files are mandatory for recovery, however, so you will always need to back up these vital pieces of information. The good news is that most automated tape backup tools will select the appropriate files for you. If you are using other tools, you will need to find the location of these files before proceeding, but generally they will be in the \EXCHSRVR directory in a folder labeled \MDBData, unless you have moved them or installed them to a different path.

In the next columns, I'll discuss:

• How to use your backup tools effectively.
• How to protect Exchange servers that act as front-end systems and contain no data, per se.
• How to put it all together to build a DR plan for your messaging infrastructure.