As I'm sure you know, Microsoft Exchange Server 2007 is very different from
its predecessors. Because of the changes to Exchange 2007's architecture, the
methods that you use to back up and restore Exchange data might vary from what
you're used to. In Exchange Server 2003, creating a backup basically meant using
an Exchange-aware backup application to back up the server's system state, file
system, and any existing information stores. But with Exchange 2007's roles-based
architecture, the backup techniques that you use will depend largely on the
roles that the server is hosting. Therefore, I'm going to focus this discussion
of backing up an Exchange Server on the aspects that are unique to each server
role. Keep in mind that an Exchange server can host multiple roles. In those
situations, you'll need to combine the backup techniques that correspond to
the roles that the server is hosting.
The Mailbox Server Role
Of all the roles that Exchange Server performs, the Mailbox server role is usually
the most important to the backup. That's because servers that host the Mailbox
server role contain end-user data such as mailboxes and public folders.
As was the case in earlier versions of Exchange Server, mailbox and public
folder data is stored in databases and in transaction log files. Exchange 2007
continues to use the Extensible Storage Engine (ESE) database format. As changes
are made to the Exchange Server databases, those changes are first written to
a RAM-based database cache, then written to a transaction log when the system's
work load permits. The contents of the transaction logs aren't committed to
the databases until the next backup. This means that unless you back up the
system on a regular basis, transaction logs can accumulate until they eventually
run the server out of disk space. If this happens, Exchange Server will dismount
the database and stop accepting data until additional storage space is made
available.
As was the case with Exchange 2003, Exchange 2007 uses
the concept of storage groups (SGs). By default, Exchange
2007 stores both the databases and the transaction logs in a
folder associated with the SG. For example, databases and
transaction logs associated with the first SG are stored in
the \Program Files\Microsoft\Exchange Server\MailboxFirst Storage Group folder. Of course this is only a default
location. In real-world deployments, transaction logs and
databases are almost always kept separate from each other
for performance and disaster recovery reasons.
The databases in the transaction logs are by far the most important components
of the Mailbox server role. You can back up these components by using any Exchange
2007aware backup application. However, there are other components that the Mailbox
server role uses that you might need to recover. One such component is the Exchange
Search information, an index of the contents of user mailboxes. It allows users
to perform searches against messages and attachments. According to Microsoft,
the Exchange Search information can't be backed up or restored. Instead, you
must rebuild it, in which case, you don't have to worry about it as part of
your backup process.
To rebuild the search index, first stop the
Microsoft Exchange Search Service and delete
the existing search catalog. The search catalog
is stored in a subdirectory under the storage
group directory. The name of the subdirectory
varies, but it always uses the word CatalogData,
followed by two GUIDs. To delete the search
catalog, simply delete the contents of this
folder within the SG that you're recovering.
Then restart the service to force the search
catalog to be rebuilt.
The Hub Transport Server Role
The Hub Transport server is responsible for routing messages within the Exchange
organization. As such, servers that host the Hub Transport role have two main
responsibilities: They host the message queues, and they maintain message-routing
information for the Exchange organization as well as message-tracking logs and
protocol logs. It also handles all the transport rules and other transport-related
activities.
In spite of the importance of the Hub
Transport server role, backing up a Hub Transport server isn't critical. To understand why
this is the case, let's look at the functions of
a Hub Transport server separately. Probably
the more crucial of the Hub Transport server
responsibilities is the message queue. The
message queue consists of an ESE database
similar to those used by Mailbox servers;
however, Hub Transport servers use circular
logging, which means Exchange overwrites
the older logs in the log file, whereas Mailbox
servers use sequential logging, in which the log
files aren't removed until they're backed up.
The reason Hub Transport servers are able to
use circular logging is because of the transient
nature of the data passing through the Store.
You might think you'd want to back up the message queue database just as you
back up any other database. Keep in mind, though, that messages generally pass
through the queue very quickly. Suppose that you made a backup of the message
queue database, and 30 minutes later your system crashes. If you were to restore
the message queue database, probably the only things that would be restored
are messages that have already passed through the queue. The highly dynamic
nature of this database and the fact that it uses circular logging makes traditional
backups impractical.
This doesn't mean that in the event of a server crash you wouldn't want to
salvage messages that are currently in the queue. If a Hub Transport server
crashes, then you can use the same techniques to recover the message queue database
that you would use to recover any other Exchange Server database, aside from
restoring the database from backup. In fact, Windows NTBackup doesn't even allow
you to back up the message queue database. In some situations, it may be possible
to recover messages from the transport dumpster.
Now let's talk about the message-tracking logs and protocol logs. These log
files store records of transactions that have occurred on the server. They aren't
crucial to the server's operation but rather are used for forensic purposes.
If the message-tracking logs and protocol logs are of value to you, you can
use a regular file-level backup to back them up. By default, these logs are
located in the \Program Files\Microsoft\Exchange Server\Transport Roles\Logs
folder.
Lastly, Hub Transport servers contain configuration information related to
the way that messages are routed throughout the Exchange organization. The majority
of the configuration information is stored in Active Directory (AD). A small
amount of configuration information is stored in the Windows registry, but this
information isn't crucial to restoring a Hub Transport server to a functional
status.
Previous
Register
