How well can your organization deal with an emergency? Automatically sign up for our free Disaster Recovery newsletter, delivered each Tuesday, and make sure you’re prepared for the next catastrophe.

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 resources at TechRepublic

Before I begin, let me clarify that this will not be a primer
on how to manage your Exchange servers, nor will I be discussing day-to-day
administration of your Exchange systems. For this, check out the many resources
at TechRepublic:

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.