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.
Even if no backup is available, you can usually restore a Hub Transport server to a functional state after a crash by running this command:
Setup /m:RecoverServer
This command will use information contained in AD to rebuild the server and restore it to a functional state. You can read more about this command in the Microsoft article "Understanding Setup /M:RecoverServer" (http://technet.microsoft.com/en-us/library/ aa998656.aspx).
The Edge Transport Server Role
Edge Transport servers are different from any other server in your Exchange
organization because they are designed to be isolated from AD, whereas other
Exchange servers depend on AD. More precisely, the Edge Transport role can't
be a domain member, and it uses Active Directory Application Mode (ADAM) to
give it a local directory replica.
Aside from that difference, an Edge Transport server functions similarly to a Hub Transport server. In fact, Edge Transport servers and Hub Transport servers have many of the same components. Both types of servers have message queues, tracking and protocol logs, and basic server configuration data. Because of the similarities, many of the rules that apply to backing up and recovering Hub Transport servers also apply to Edge Transport servers.
As with a Hub Transport server, the message queues on an Edge Transport server are based on an ESE database. And as is the case with Hub Transport servers, it isn't practical to back up the message queue database because of the transient nature of the data and the fact that the server uses circular logging.
You can back up message-tracking and protocol logs on an Edge Transport server by performing a file-level backup. The message tracking and protocol logs are located by default in the \Program Files\Microsoft\Exchange Server\TransportRoles\Logs folder.
Where Edge Transport servers really differ from Hub Transport servers is in the way that they store configuration data. As I mentioned earlier, Edge Transport servers don't store data in AD. Instead, it's stored in an Active Directory Application Mode (ADAM) database. This data is derived by replication from the AD database.
An Edge Transport server's primary job is to filter messages entering the organization from the Internet. Content-filtering data is stored in an ESE database similar to the one used by the message queue.
What makes the configuration data on an Edge Transport server interesting is that you typically don't need to back it up. That's because most settings on an Edge Transport server are set by default. The data contained in the ADAM database is replicated from the AD database, which you should already be backing up. The content-filtering database is updated automatically over the Internet as new antispam data becomes available. Consequently, Microsoft says that it isn't necessary to back up configuration data on an Edge Transport server unless you've implemented custom settings.
If your Edge Transport server does contain custom settings, you'll need to use a cloning technique to back up those settings. The easiest way to accomplish this task is to use the Exchange Management Shell to run two predefined scripts: ExportEdgeConfig.ps1 and ImportEdgeConfig.ps1. You use the ExportEdgeConfig.ps1 scripts to export configuration data to an XML file, then if you ever need to restore the server's configuration, you use the ImportEdgeConfig.ps1 script to import the XML file. Both scripts are located in the \Program Files\Microsoft\Exchange Server\Scripts folder.
Client Access Servers
In Exchange 2007, servers that host the Client Access server role provide OutlookWeb
Access (OWA) to users. What makes recovering Client Access servers tricky is
that they contain data that resides outside of Exchange Server. For example,
configuration data is stored in the local file system, AD, and in the Microsoft
IIS metabase. This external data complicates recovery efforts in the event of
a crash.
As with some of the other server roles that I've discussed, there's a command that you can enter to return the server to a functional state. For a Client Access server, the command is:
Setup /mode:RecoverServer
The most important thing to know about this command is that it returns your server to the default installation state, and therefore any customizations that you've made will be lost. These customizations include nondefault virtual directories, any customizations that you've made to the default virtual directory, and any certificates you've added.
Furthermore, if you attempt to recover the IIS metabase after having run the Setup /mode: RecoverServer command, then the IIS Metabase will be out of sync with AD, and the Client Access server will experience errors. Therefore, Microsoft recommends that you don't attempt to recover the IIS metabase after you've run the Setup /mode:RecoverServer command. Instead, you should create a log of any customizations that you've made to the Client Access server so that you can manually reapply those changes after a recovery.
The easiest way to back up a Client Access server is to perform a file-level backup that also includes a backup of the system state. Table 1 lists the components that you can back up through a file-level backup and where they are located. A system state backup will back up the remaining Client Access server components, including the Autodiscover service, the Windows registry, and the Web Services configuration.
The Unified Messaging Role
The Unified Messaging role is new to Exchange 2007. This is the role that allows
voice messages and faxes to be stored in user's inboxes. You can back up Unified
Messaging servers by performing a filelevel and system state backup.
The vast majority of the configuration data that's associated with a Unified Messaging server is stored in AD. In fact, in the event of a crash, you can rebuild a Unified Messaging server by running the Setup /m:RecoverServer command. So much of the server's configuration information is stored in AD that the only thing that a system state backup really gives you is a backup of the configuration data located in the Windows registry.
Configuration data located in the registry isn't essential for server recovery, and therefore a system state backup isn't an absolute requirement. Keep in mind that if you've created custom auto-attendant or custom voice prompts, you'll need to back them up or you'll lose them. The same goes for any auto-generated grammar file containing the table names for the auto attendant.
The most important location to back up during a file-level backup is the \Program Files\Microsoft\Exchange Server\Unified Messaging\Prompts folder. This is the folder that contains any custom audio files that you've created.
AD
As you know, Exchange Server is completely dependent on AD. As such, the only
way to protect your Exchange Server organization from a catastrophic failure
is to also have backups of your AD and your DNS server. DNS server backups are
necessary because DNS is an AD dependency. The easiest way to perform an AD
backup is to perform a file system and system state backup of your domain controllers
(DCs).
New Architecture, New Strategies
You can see a summary of Exchange 2007's new server roles and points to remember
about their associated backup strategies in the sidebar "Exchange 2007 Server
Roles and Backup Techniques." . As you can see, Exchange 2007's roles-based
architecture makes it quite different from its predecessors. Therefore, the
techniques that you use to back up Exchange 2007 will likely also be different
from what you are used to. But once you understand Exchange 2007's new server
roles, you should have no trouble backing up and restoring your vital Exchange
data.
