Introduction

Understanding how to back up and restore the Exchange data on your servers is critically important. If you don't ensure that your public and private information stores, and Exchange's configuration data are backed up on a regular basis, you could end up losing business-critical datawhich can lead to some very uncomfortable conversations, at best. Unfortunately, too many administrators wait until disaster strikes to hone their backup and recovery skills. The time to understand the mechanics of backing up and restoring your servers is before you have a major failure that necessitates reloading your data from backup.

Often, the most important thing to do when faced with disaster recovery is to relax, and think the situation through clearly before beginning. Ensure that you have all of the media you will need for software installation (including third-party products, like Exchange-aware anti-virus software), and that you understand the task you are undertaking. There is no shame in calling Microsoft Product Support Services (PSS) for help; the cost of the call is easily offset by the confidence you will gain and improved speed with which you'll be able to get the restore process completed.

The basics of disaster recovery for Exchange really haven't changed through the various releases of the product; the main difference between Exchange 2000 and 2003 and older versions of the product is that Exchange no longer hosts its own directoryActive Directory (AD) holds almost all Exchange-related configuration data, and being AD savvy and understanding Exchange's dependency upon AD counts for a lot when you're faced with restoring an entire Exchange server from scratch.

We described some of the inner workings of Exchange's Extensible Storage Engine (ESE) database engine in the Introduction in Chapter 6. From a backup and recovery perspective, there are several important consequences of the way ESE works; you have to understand these to make appropriate choices about your backup and recovery procedures. The key items about ESE's architecture to remember are that:

• The EDB and STM files for any mounted database will be held open as long as that database is mounted. That means that copying the open file is not guaranteed to yield a complete and consistent copy. For example, let's say that someone sends you a 5 MB PowerPoint presentation. The first 4.9 MB of the attachment have been written to the store, and then the file is copied before the last 100 KB is written. Even if the copy appears to be complete, you will be left with missing data. You need to ensure that your backup solution works on open databases and understands the transactional nature of Exchange databases.

• A single transaction log file (known as a generation) is open for each storage group at any one time. When a log file reaches its maximum size of 5 MB, it's closed and a new generation is allocated. Older generations of log files remain present until they're purged. This is desirable, since the log generations allow older transactions to be played back during a recovery; however, the log files do need to be backed up. During a full, or normal, online backup (as described later in this introduction), Exchange-aware backup software freezes the checkpoint file for the storage group, which enables the information store to note which transactions have been committed to the database at the time the backup began, and leaves the checkpoint in place until the backup completes. Once the backup completes, any new generations are also backed up during the operation. The generations that were committed to the database prior to the start of the full backup, and the generations that were backed up individually, are then purged from the file system. These operations are further discussed in the "Backup Types: Full, Incremental, and Differential" section of this introduction.

Online, Offline, and Point-in-Time Backups

Since the EDB and STM files are kept open by the database engine, it's reasonable to ask how they can be backed up. One way is to dismount the databases you want to back up, or the storage groups to which they belong, then copy or back up the files. This approach is called an offline backup . You can perform these backups either by stopping the Exchange information store service (which dismounts all databases on the server) or by dismounting individual storage groups. Of course, during the time that these databases are dismounted, users won't be able to access their mailboxes. Restoring these backups can be tricky (as described in MS KB 296788, Offline Backup and Restoration Procedures for Exchange), so we normally don't recommend them as a part of your backup/restore processes. The exception is when you're making a major change to the server, like installing low-level software (say, a virus scanner or a Windows service pack). In that case, you should probably plan on making a complete offline backup right before you make the change, just in case the change breaks something and you need to back out.

As a better alternative to offline backups, Microsoft provides an API for performing Exchange online backups. Backup programs that use this API are said to be Exchange-aware; by using the API they can read pages from the Exchange database files while the files are open. This permits you to back up databases while users continue to send and receive messages; you can restore individual databases without affecting users whose mailboxes are in other storage groups on the same server. The API also permits a compliant backup program to simultaneously back up or restore one database from each active storage group; this allows you to parallelize backups or restores by using one tape drive or disk volume for each storage group and backing up or restoring to all of them at once. The online backup API is mature, thoroughly tested, and able to handle a variety of edge cases properly, such as when new transactions come in while the current generation is being backed up, and when two generations' worth of transactions occur during backup.

Some vendors (notably EMC, HP, and VERITAS) offer snapshot backups that freeze a point-in-time copy of the data in an Exchange database. Without delving into the differences between specific products, all of these products are supported by Microsoft only as offline backups. That doesn't mean that you can't use them, it just means that these solutions aren't directly supported by Microsoft. MS KB 311898 (XADM: Hot Split Snapshot Backups of Exchange) provides a brief overview of snapshot and hot split backups, and has this to say:

This does not mean that you cannot perform hot split and other snapshot backups safely and successfully. However, the backup solution vendor or Exchange administrator is responsible for making sure that all of the required files are backed up and restored correctly. The backup solution vendor or Exchange administrator is also responsible for making sure that the integrity of all of the files is preserved at each stage of the process.

If you implement a snapshot or hot split backup solution for Exchange, your vendor is your primary support provider for backup and recovery issues. Microsoft Product Support Services (PSS) can help you diagnose or analyze issues with the available database and transaction log file sets. However, Microsoft does not test, certify, or debug scripts and procedures for hot split backups or snapshot backups of Exchange data files. Microsoft PSS assistance is limited to advice about how to best continue to recover the available file set.

For Exchange Server 2003 running on Windows 2003, there's an alternative method of making point-in-time copies; the Windows Volume Shadow Copy Service, or VSS. VSS is a system service that ties together applications, backup, or utility programs, and hardware to provide a safe method for creating point-in-time copies. With VSS, here's what happens:

1. The administrator initiates a backup using a VSS-aware backup program. The "VSS-awareness" of this program comes about when the vendor creates a component known as a requestor; the requestor's job is to use the VSS interfaces to tell VSS-aware applications what data is to be backed up.

2. VSS accepts the request from the requestor and looks through its list of registered applications for one that matches. Each application that wants to be visible to VSS, like Exchange, SQL Server, or Oracle, has to include a VSS writer. The writer's job is to take whatever application-specific actions are required to prepare the application's data to be safely copied.

3. VSS notifies the Exchange writer that it needs to get things ready. The writer responds by calling VSS again, asking it to freeze pending write requests for the volumes "owned" by Exchange. Pending reads can still complete, as can any writes that are already in progress; new writes are held in a queue. The writer can initiate this freeze across multiple volumesa necessary refinement for Exchange, since logs and databases are usually stored on separate volumes.

4. Once VSS has frozen I/O for all the target volumes, it notifies the writer, which can then perform any necessary cleanup operations like closing log files, flushing caches, and so on to temporarily quiesce the database so it can be safely copied.

5. When the writer's finished its work, the application signals VSS, which gives the go-ahead to the requestor. The requestor can then copy the data itself (using the default copy-on-write provider included with Windows Server 2003), or it can tell VSS to use a specific provider, like those provided by various SAN hardware vendors.

6. When the provider is finished copying data, it notifies VSS, which then unfreezes I/O to the source volumes and notifies the writer to proceed with normal operations.

As we write this, there are still very few vendors outside of Microsoft that are shipping stable VSS-aware products. However, most major backup vendors (including VERITAS, Computer Associates, and CommVault) support VSS, as do many SAN hardware vendors. At the time of this writing, VSS implementations for Exchange have not been widely produced. Until this technology becomes more mature, and more vendors provide solutions based on VSS, we're sticking with full, online backups for our Exchange servers.

Backup Types: Full, Incremental, and Differential

Earlier in this section, we mentioned that transaction logs must periodically be purged. Assuming you don't have circular logging enabled, you shouldn't do this manually; the supported way of purging the logs is to back up the log files themselves. When you perform an online backup with a program that supports the Exchange backup API, the log files may or may not be purged, depending on the type of backup you've specified. Understanding the backup types is thus critical to knowing how to ensure that the log files are backed up. (Before reading the remainder of this section, you may find it useful to revisit the Introduction in Chapter 6 on how incoming transactions are logged.)

Full backups are the easiest type of backup to understand. When you perform a full online backup on an Exchange database, the database is backed up in its entirety, but the logs remain untouched. When you perform a full backup of a storage group, all of the databases are backed up, and the log files are truncatedtheir transactions are committed, and the transaction log files are removed from the disk. To restore a full backup, all you need is the full backup itselfif you restore your Monday full backup, you only need the Monday tape to roll back to that point in time.

Incremental backups capture only pages within the database that have changed since the most recent full backup; they do this by backing up (and then removing) all log files generated since that backup. This tends to make these backups small and fast, but the consequence is that you can't do a complete restoration using only incremental backupsyou must first restore the full backup, and then restore each incremental backup that you have, in the correct order. Let's say you adopt the common approach of taking a full backup weekly (say, on Sunday) and incrementals daily. If you want to restore to the system state on Wednesday, you need the Sunday full backup and the Monday, Tuesday, and Wednesday incrementals. If you don't have the Tuesday tapes, you will only be able to restore the Monday state; you can't play back transaction logs that were generated after a missing or corrupt earlier generation.

Differential backups are a hybrid of full and incremental backups. They accumulate all transactions since the last full backup, but they don't purge the log files when the backup is completed. If you combine a weekly full backup with daily differentials, each differential will be larger than the preceding day's backup, but you only need a particular day's differential plus the full. In the Sunday scenario described earlier, to restore to Wednesday's state, you'd need the Sunday full backup and the Wednesday differential.

What backup type should you use? It depends on how much time you can afford to take for backup and restore operations, and the capacity of your storage media and devices. For example, if your backup hardware requires 12 hours to make a full backup of your current databases, but only two hours for an incremental backup (on average, of course), you'd probably find that a weekly full, combined with daily incrementals, would give you adequate protection. However, you must factor in restore times.

Let's say your goal is to restore a failed database within four hours. That means that, within a four-hour window, you need to locate all the needed backup media, start the backup, wait while the backed-up data are retrieved from tape or disk, and then wait while the logs are played back and the database is mounted. The largest portion of time will be spent reading the data from tape. If you can restore 10 GB per hour, then you can restore a maximum of between 20 and 30 GB during your four-hour window. You might be able to cut that time by splitting larger databases into smaller ones, redistributing mailboxes between servers, or using different backup hardware.