Chapter 18: Backing Up and Restoring Microsoft Exchange Server 2007

Microsoft Exchange Server 2007 is critically important to your organization. If a mail-box server crashes, you are faced with the possibility of every user on that server losing days, weeks, or even months of work. If your primary Client Access server crashes and you don't have any alternates, users won't be able to remotely access messages, calendars, address lists, and more. If your primary Transport server crashes and you don't have any alternates, messages will not be properly routed and delivered. To ensure access to Exchange Server and to protect your users’ data, you need to extend your Exchange organization to meet the availability expectations and implement a backup and recovery plan. Backing up Exchange Server can protect against database corruption, hardware failures, accidental loss of user messages, and even natural disasters. As an administrator, it's your job to make sure that backups are performed and that backup media are stored in a secure location.

Understanding the Essentials of Exchange Server Availability, Backup, and Recovery

Backing up and recovering Exchange data is a bit different from backing up other types of data, primarily because Exchange Server 2007 has different units of backup and recovery than Microsoft Windows. You not only work with files and drives, you also work with the information store and the data structures it contains. As you know from previous chapters, the information store can contain one or more storage groups and, in turn, each storage group can contain one or more databases.

Ensuring Data Availability

With Exchange Server 2007, it is easier than ever to design a fault-tolerant architecture that ensures the availability of most messaging services. Simply by deploying multiple Hub Transports, Edge Transports, and Client Access servers and placing the additional servers within the appropriate Active Directory sites, you can ensure availability of key messaging services if a primary Hub Transport, Edge Transport, or Client Access server is to fail.

When it comes to mailbox servers, you can use several techniques to improve availability and avoid having to restore from backups. These techniques include:

• Continuous replication Exchange 2007 includes asynchronous log shipping technology that you can use to create and maintain a copy of a storage group. If you are using clustered mailbox servers, you can use Cluster Continuous Replication to create a copy of a storage group on another server. If you are using non-clustered mailbox servers, you can use Local Continuous Replication to create a copy of a storage group on another set of disks.

• Deleted item retention Deleted item retention allows users themselves to restore a single item or entire folders in Microsoft Outlook.

• Deleted mailbox retention Deleted mailbox retention allows administrators to restore deleted mailboxes without having to restore the mailboxes from backups.

• Multiple mailbox databases By using multiple mailbox databases and distributing users across these databases, you can reduce significantly the impact of the loss of a single database and allow for faster restores when needed.

Backing Up Exchange Server: The Basics

To create a complete backup of an Exchange server, you must back up the following:

• Exchange configuration data, which includes the configuration settings for the Exchange organization. You take configuration settings from Active Directory and the Windows registry. Configuration data doesn't include any user data.

• Exchange user data, which includes Exchange mailbox database databases, public folder database databases, and transaction logs. If you want to be able to recover mailbox and public folder databases, you must back up this data. User data doesn't contain Exchange configuration settings.

• System State data for the operating system, which includes essential system files needed to recover the local system. All computers have System State data, which you must back up in addition to other files to restore a complete working system.

• Folders and drives that contain Windows and Exchange files. Normally, this means backing up the root drive C, which is the special partition for Exchange Server.

Storage groups and databases are the units of backup and recovery for the information store. Storage groups are the smallest units of backup, and mailboxes are the smallest units of recovery. This means that you have the following backup and recovery options for the information store:

• Backup options

  • q You can back up the entire information store.

  • q You can back up sets of storage groups.

  • q You can back up individual storage groups.

• Recovery options

  • q You can recover the entire information store.

  • q You can recover sets of storage groups.

  • q You can recover individual storage groups.

  • q You can recover groups of databases.

  • q You can recover individual databases.

  • q You can recover individual mailboxes.

The ability to recover an individual database from backup is a great improvement over early releases of Exchange Server, but there are some fundamental issues you should know about before you try to do so. These issues pertain to transactions, transaction logs, and transaction logging modes.

Exchange Server uses transactions to control database changes. You can think of a transaction as a logical unit of work that contains one or more operations that affect the information store. If Exchange Server executes all of the operations in a transaction successfully, it marks the transaction as successful and permanently commits the changes. If one or more of the operations in a transaction fails to complete, Exchange Server marks the transaction as failed and removes any changes that the transaction created. The process of removing changes is referred to as rolling back the transaction.

Transaction logs are units of storage for transactions. Exchange Server writes each transaction to a log file and maintains the log files according to the logging mode. With standard logging, Exchange Server reserves 1 megabyte (MB) of disk space for the active transaction log. Exchange Server commits or rolls back transactions based on their success or failure. When the contents of the log reaches 1 MB, Exchange Server creates a new log file. Because Exchange Server maintains the transaction logs until the next full backup, you can recover Exchange Server to the last transaction.

Note 

The active transaction log is named E##.log, where ## is the unique identifier for the storage group. Additional transaction logs are named E##00000001.log, E##00000002.log, and so on.

The ability to recover mailboxes selectively from backup is an improvement over Exchange 2000 Server, and, as with recovering databases, there are some fundamental issues you should know about before you try to recover individual mailboxes. These issues pertain to recovery storage groups.

Recovery storage groups are special types of storage groups that Exchange Server reserves for recovery operations. Using a recovery storage group, you can restore mailboxes from any of the regular storage groups in an Exchange organization. You can recover individual or multiple mailboxes at the same time, provided the databases for those mailboxes are in the same storage group. You cannot, however, use recovery storage groups to restore public folder databases. Because you link each recovery storage group to an existing storage group, you can mount only databases from the linked storage group in the recovery storage group.

Note 

Don't confuse this recovery procedure with those used for disconnected mailbox recovery. You use disconnected mailbox recovery to recover deleted, disconnected, or otherwise unavailable mailboxes, as long as those mailboxes are available for recovery from an existing mailbox database. You use the recovery storage group to recover mailboxes from a previous backup of a mailbox database.

Creating a Disaster Recovery Plan Based on Exchange Roles

With Exchange Server 2007, you need to tailor your recovery plan to the roles installed on your Exchange servers. Because configuration data for Exchange Server 2007 is stored in Active Directory, you can fully restore some server roles by running the Exchange Setup program with the /mode:recoverserver command on a server. With other roles, running this command restores the Exchange configuration, but you will need to recover the critical Exchange data from backup.

Here are guidelines for your recovery planning:

• Mailbox servers You cannot fully restore the Mailbox Server role by running the Exchange Setup program with the /mode:recoverserver command. You must restore mailbox servers from a backup that includes the necessary Exchange data and the System State data. Mailbox servers store Exchange database files, including both mailbox and public folder databases, and Exchange transaction log files specific to each storage group. You must back up these files with an Exchange-aware backup application. You can also rebuild replicated public folder data through the normal replication process if there are available replicas. Mailbox servers also store full-text indexing information specific to each mailbox database in a storage group. You do not need to back up full-text indexes, because you need to rebuild them, as discussed in the "Content Indexing" section of Chapter 11, "Managing Microsoft Exchange Server 2007 Data and Storage Groups." Other types of Exchange databases on mailbox servers include: free/busy information and the Offline Address Book (OAB). This information can be rebuilt by automated maintenance and then replicated.

• Hub Transport servers You can restore the Hub Transport Server role and make it fully functional by running the Exchange Setup program with the /mode:recoverserver command. Hub Transport servers store all essential configuration data in Active Directory. These servers also store some limited configuration data in the registry. You back up the registry when you perform a System State data backup. In addition to configuration data, Hub Transport servers store queues in database files and any logs you've enabled, including message tracking, protocol, and connectivity logs. Queues store messages actively being processed, and logs are primarily used for historical reference and troubleshooting. Queues and logs are not essential to restoring Hub Transport server functionality. That said, you could mount message queues on a new server if you recover them from a failed server.

• Edge Transport servers The Edge Transport Server role is designed to function on a stand-alone server. Edge Transport servers store configuration data, queues, replicated data from Active Directory, and any logs you've enabled, including message tracking, protocol, and connectivity logs. These servers also store some limited configuration data in the registry. You back up the registry when you perform a System State data backup. Replicated data from Active Directory is stored in Active Directory Application Mode (ADAM). Queues store messages actively being processed, and logs are primarily used for historical reference and troubleshooting. Replicated data, queues, and logs are not essential to restoring Edge Transport server functionality. Replicated data can be resynchronized as necessary, and both queues and logs are created automatically as necessary. If you've applied custom settings to an Edge Transport server, such as those for content filtering, you can create a backup of the configuration, as discussed in the "Cloning Edge Transport Server Configurations" section of this chapter.

• Client Access servers You can restore the Client Access Server role to its initial default state by running the Exchange Setup program with the /mode:recover-server command. However, any custom changes you've made to Hypertext Transfer Protocol (HTTP) virtual servers running on a Client Access server are not restored. Changes to HTTP virtual servers are stored in the Internet Information Server (IIS) metabase. Although you could restore the IIS metabase from backup to recover the custom settings, this is not recommended, as you may experience errors on the Client Access server if the IIS metabase and the recovered Active Directory settings aren't exactly in sync. These servers store some limited configuration data in the registry. You back up the registry by performing a System State data backup. To restore a Client Access server, you can build a new server with a new name by running Exchange Setup, or you can restore the old server with the same name by running Exchange Setup with the /mode:recoverserver command. When Setup finishes, you then need to apply the same customizations that you had on the server before, re-creating additional Web sites and virtual directories as necessary. To apply the setting changes, you should restart IIS.

• Unified Messaging servers The Unified Messaging Server role stores all of its essential configuration data in Active Directory, and you can restore a server restored to its initial default state by running the Exchange Setup program with the /mode:recoverserver command. Unified Messaging servers store some limited configuration data in the registry. You can back up the registry by performing a System State data backup. In addition to configuration data, Unified Messaging (UM) servers store queues in database files and any logs you've enabled. Queues store messages actively being processed, and logs are primarily used for historical reference and troubleshooting. Queues and logs are not essential to restoring UM server functionality. You can mount message queues on a new server if you can recover them from a failed server. In addition, you can restore any custom audio files used for prompts automatically through replication if you have other UM servers in the organization.

Finalizing Your Exchange Server Disaster Recovery Plan

As you've seen, creating a backup and recovery plan for Exchange Server 2007 requires forethought on your part. As part of your planning, you also need to take a close look at the overall architecture of your Exchange organization and make any changes required to ensure that the architecture meets the availability and recoverability expectations of your bosses. You need to review:

• The number of Exchange servers to use in your organization. Do you need multiple servers to ensure high availability? Do you need multiple servers to improve performance? Do you need multiple servers because the organization spans several geographic areas?

• The number of storage groups for each Exchange server, as well as how the groups are organized. Do you need to create storage groups for each department or division in the organization? Do you need to create storage groups for different business functions? Do you need to create separate storage groups for public folders and other types of data?

• The number and type of databases for each storage group. Do you need to create separate databases for different departments, divisions, and business functions? Do you need to create separate databases for different types of public folder data?

After you've reviewed the architecture of the Exchange organization and implemented any necessary changes, you can create a backup and recovery plan to support that organization. You'll need to figure out what data you need to back up, how often you should back up the data, and more. To help you create a plan, consider the following:

• How important is the mailbox or public folder database you're backing up?

  The importance of the data can go a long way in helping you determine when and how you should back up the database. For critical data, such as a department's mailbox database, you'll want to have redundant backup sets that extend back for several backup periods. For less important data, such as public folders for nonessential documents, you won't need such an elaborate backup plan, but you'll need to back up the data regularly and ensure that you can recover the data easily.

• How quickly do you need to recover the data? Time is an important factor in creating a backup plan. You might need to get critical data, such as the primary mailbox database, back online swiftly. To do this, you might need to alter your backup plan. For example, you might need to create multiple mailbox databases and place them in different storage groups on different servers. You can then recover individual databases, individual storage groups, or individual servers as the situation warrants.

• Do you have the equipment to perform backups? If you don't have backup hardware, you can't perform backups. To perform timely backups, you might need several backup devices and several sets of backup media. Backup hardware includes tape drives, tape library systems, storage arrays, and removable disk drives.

• Who will be responsible for the backup and recovery plan? Ideally, someone should be the primary contact for the Exchange backup and recovery plan. This person might also be responsible for performing the actual backup and recovery of Exchange Server.

• What is the best time to schedule backups? Scheduling backups when system use is as low as possible speeds up the backup process. However, because you can't always schedule backups for off-peak hours, you'll need to carefully plan when you back up data.

• Do you need to store backups off-site? Storing copies of backup tapes off-site is essential to recovering Exchange Server in the case of a natural disaster. In your off-site storage location, you should also include copies of all the software you might need to recover Exchange Server.

Choosing Backup Options

As you'll find when you work with data backup and recovery, there are many techniques for backing up data. The techniques you use depend on the type of data you're backing up, how convenient you want the recovery process to be, and other factors.

You can perform backups online (with Exchange services running) or offline (with Exchange services stopped). With online backups, you can archive the following:

• Exchange configuration data

• Exchange user data

• System State data

• Files and folders that contain Windows and Exchange files

With offline backups, you can't archive Exchange configuration or user data. This means that you can only archive the following:

• System State data

• Files and folders that contain Windows and Exchange files

Real World With Exchange Server 2007 running on Microsoft Windows Server 2003 or later, you have the option of using the Volume Shadow Copy Service (VSS) to perform online backups. VSS creates point-in-time snapshots of data at the beginning of the backup process. The snapshot data is then used to create the backup rather than working with the server's hard disk. This allows normal operations to continue while the backup occurs and ensures that the backup is consistent, even if the data changes while the backup is in progress. Shadow copies of Exchange data can be made only if the backup software you are using supports the Exchange VSS extensions.

The basic types of backups you'll want to perform with Exchange Server are as follows:

• Normal/full backups Back up all Exchange data that has been selected, including the related databases and the current transaction logs. A normal backup tells Exchange Server you've performed a complete backup, which allows Exchange Server to clear out the transaction logs.

• Copy backups Back up all Exchange data that has been selected, including the related databases and the current transaction logs. Unlike a normal backup, a copy backup doesn't tell Exchange Server you've performed a complete backup and, as a result, the backup does not clear the log files. This allows you to perform other types of Exchange backups later.

• Differential backups Designed to create backup copies of all data that has changed since the last normal backup. Backs up only transaction log files and not the actual databases. Does not clear the log files. To recover Exchange Server, you must apply the most recent normal backup and the most recent differential backup.

• Incremental backups Designed to create backups of data that has changed since the most recent normal or incremental backup. Backs up only transaction log files and not the actual databases. Clears the log files after the incremental backup completes. To recover Exchange Server, you must apply the most recent full backup and then apply each incremental backup after the full backup. You must apply transaction logs in order.

In your backup plan, you'll probably want to perform full backups on a weekly basis and supplement them with nightly differential or incremental backups. You might also want to create an extended backup set for monthly and quarterly backups that you rotate to off-site storage.