Backing Up an Exchange Server

Losing valuable PC data is a terrifying prospect. Almost everyone has a story about inadvertently deleting a crucial file or having a fatal disk corruption. An even worse scenario is an Exchange server crash, which could permanently destroy all users' email messages. The prospect is scary enough to inspire you to plan an effective disaster-recovery strategy.

Many organizations have a written backup routine, but the sticking point is implementation. An effective program means testing your disaster recovery plan to ensure that it works. This month, I'll take you through the Exchange Server backup process; in a subsequent issue, I'll explain how to restore the server.

Client-based Storage and Backup
Exchange can store messages on both the client and the server, and the backup strategy differs for each storage location. Because client-based Exchange components, such as personal folders (.pst files), Personal Address Books (PABs), and offline storage (.ost) files, reside on users' PCs, the responsibility for backup falls on the user. AutoArchive, a feature in Outlook that automates client backup, backs up users' mail folders into a dedicated .pst file, and stores that data on the user's local hard disk.

The .ost files are usually not at much risk, because Exchange synchronizes, or copies, .ost files from the server. If the client's hard disk fails, users can go to another PC and create a new Exchange profile with a new .ost file and synchronize their messages again. In this case, you lose only changes to the .ost file on the client that Exchange hasn't synchronized to the server when the client computer crashes.

If all messaging is server-based, an organization can plan for centralized backups. Let's see what's involved in a centralized backup.

Exchange Backup Files
With a proper backup strategy, Exchange Server can survive a catastrophic event. You use the following important files to back up and recover Exchange. (Screen 1, page 2, displays some of these files.)

Three database files. At a minimum, you need to back up three databases: the Directory (DIR.EDB), the Private Information Store (PRIV.EDB), and the Public Information Store (PUB.EDB). In addition, if you're using Microsoft's Key Manager Server (i.e., encryption and digital signatures), you need to back up the Key Manager Server directory, because it contains the database that contains all the organization's public and private keys.

Transaction logs. The transaction files contain transactions for the Directory Service and Information Store service. When a user sends a message, Exchange first writes the data to the transaction log and later flushes it to the Information Store database. This two-step process helps you recover from a disaster that loses the database but retains the log files. (For more information about this process, see Tony Redmond, "Inside the Information Store," Windows NT Magazine, May 1998. The sidebar "Tips for Using Transaction Log Files" gives suggestions for using the files efficiently.)

For example, the DIR.EDB, which stores directory information such as the Global Address List (GAL), has a corresponding log file (EDB.LOG). The Private and Public Information Stores share a separate EDB.LOG. By default, Exchange writes messages into the current EDB.LOG until that log file reaches 5MB. At that point, Exchange renames the file, using a hexadecimal naming scheme (i.e., EDBxxxxx..LOG), and creates a new EDB.LOG. The default location for both the current log and previous logs is exchsrvrdsadata for the Directory and exchsrvrmdbdata for the Information Store service. (For more information about transaction log files, see Jerry Cochran, "The Exchange Server Troubleshooter," June 1998.)

Checkpoint files. The checkpoint file (EDB.CHK) records the history of the committed entries from the respective .log file. Both the Directory and the Information Store have checkpoint files. When Exchange commits a buffer to a database, Exchange updates the checkpoint file and moves a marker to the next uncommitted entry. Exchange uses the checkpoint file during recovery operations, but if the checkpoint file is corrupt or missing, Exchange can read the logs directly.

Reserve logs. The Directory and the Information Store each have two 5MB reserve logs (RES1.LOG and RES2.LOG) for emergency situations. For example, when Exchange fills the current .log file, it renames it and then attempts to create a new EDB.LOG. If you don't have enough disk space (5MB of free space), Exchange automatically begins using the reserve log files. Exchange flushes any uncommitted entries from memory into a reserve log file, shuts down the service, and writes a corresponding event in Event Viewer. Users, of course, won't be able to use the server until the administrator frees up disk space.

Patch files. Because you can actively back up the Exchange server while it is online, you need a mechanism to capture entries written to the database during the backup process. Patch (.pat) files play that role. The three patch files (DIR.PAT, PRIV.PAT, PUB.PAT), typically visible only during the backup process, record any transactions committed to the database that reside on split pages. In other words, if Exchange applies a newly committed transaction to the database after Exchange has already backed up that portion of the database, Exchange records the new transaction in the patch file. During the final stage of the backup process, Exchange copies the patch files over to the tape and later purges the files from the hard disk. This process ensures that Exchange fully captures all transactions.

Backup Options
The Exchange backup application offers four backup options:

Circular Logging
An important consideration for backups is circular logging, a setting that lets Exchange overwrite previous transaction log files. You can clear or select circular logging from the Advanced tab of the Exchange Server Properties sheet, as you see in Screen 2.

A typical Exchange server has four .log files at one time. When you enable circular logging, as Exchange writes new messages to the log file, it overwrites the older messages in the log file. Enabling circular logging conserves disk space, because Exchange effectively purges log contents that it has committed to the database file.

The key point is that with circular logging enabled, you can recover data only up to your last backup tape. You can't roll forward any log files to the databases. If you can't live with this constraint, I strongly suggest that you disable circular logging.

Disabling circular logging will cause Exchange to continually write 5MB transaction log files until either you perform a backup (normal or incremental) or the server runs out of disk space and automatically shuts itself down. Disabling circular logging lets you perform incremental and differential backups, which you can't do if you enable circular logging.

The advantage of disabling circular logging is that in disaster recovery, you have at least a fighting chance of recovering your Exchange server up to the point of failure. If you have a regular backup tape, incremental or differential log tapes, and transaction log files that still reside on a good partition of the server, you can recover up to the point of failure without losing any messages. To have the best chance of recovery, always disable circular logging on production servers.

Performing an Exchange Backup
You can back up Exchange Server online or offline. In addition, you can use third-party products for the backup.

Online backup. Microsoft has extended the Windows NT Backup utility to let you back up your Exchange organization, as you see in Screen 3. This application lets you back up Exchange while the Exchange services are running, so you can have 24 * 7 coverage.

Because this NT Backup extension applies only to Exchange, you can't perform other backup operations at the same time through this program. For instance, you can't back up the local Registry or perform hardware compression. Exchange Backup lets you back up remote servers throughout the organization; however, backing up a remote server with large databases can monopolize the network wire. Therefore, the best practice is probably to back up each server locally.

You access the Exchange backup window from Start, Programs, Administrative Tools, Backup. You can choose two backup sets, one for the Directory and one for the Information Store, as you see in Screen 3. A backup set is a collection of files from a drive. After you select a set, click Backup on the toolbar to bring up the Backup Information window, which you see in Screen 4, page 4.

You can configure several options. Enter a tape name for the specific backup. Choose the backup type (normal, copy, incremental, differential). The backup program automatically creates a log file. The default is Summary Only, but I recommend that you select Full Detail instead so that the file contains as much information as possible (e.g., the data files that you're backing up in the order that they occurred). Exchange will append future backup logs to the Backup.log file so you have a running summary of each backup in one file. Another best practice is to select Verify After Backup (this option is not the default) to initiate a checksum calculation after the backup to ensure the tape data is the same as what's on the hard disk.

To start the backup, click OK. The backup program

Offline backup. As an alternative, you can use the default NT backup program to back up the Exchange server offline. Because this program can't back up open files, you have to stop the Exchange services before you start the backup. Although you lose 24 X 7 support if you use the NT backup program, you gain the advantage of backing up the entire hard disk, including the local Registry and all the data on the disk. This backup type would be advantageous if you were using Exchange's Key Manager, because you would be backing up all the keys used for advanced security.

Third-party backup products. Several third-party products support Exchange backups. These applications typically give you more functionality (e.g., custom and automated scheduled backup routines, media pooling, and advanced logging and management reports) than either of the Microsoft backup products. One product, Computer Associates' ARCserve 6.5 with DBAgent 2.0, lets you back up individual mailboxes or public folders. During the restore process, you select just the mailbox you want to restore, instead of the entire Private Information Store. Large organizations might want to invest in these utilities to gain the additional capabilities they provide.

Regardless of the backup program you use, you aren't finished until you perform possibly the most ignored step in disaster recovery: storing the backup tape offsite in a safe place away from the server.

Backup Strategy
Backup strategy depends on your organization's preferences. Daily normal (full) backups offer the quickest restore capability, but they create a heavy load on the server, because you're backing up both database and log files. In addition, if the backup hardware is slow, daily full backups might not be feasible if they cut into heavy client usage time and affect performance.

A weekly full backup with daily incremental backups reduces the server load (at least during the incremental backup) but increases restore time because you might need multiple incremental logs. This strategy conserves disk space because incremental backups purge log files. A weekly full backup coupled with daily differential backups lets you restore faster because you need only two tapes (the last full and last differential backup).

Exchange Utilities and Backups
Microsoft has included a few utilities that can help keep your databases free from errors. Every quarter, I run the ISINTEG utility before and after my backup procedure to perform an integrity check on my Exchange databases. This utility can correct inconsistencies in the databases. The last thing I want to do is back up a corrupt database. I run ISINTEG until it reports 0 warnings and 0 errors to ensure that I've squeezed out as many errors as possible. For more information about ISINTEG, see Microsoft Knowledge Base articles Q182081 (http://support.microsoft.com/support/kb/articles/q182/0/81.asp) and Q183400 (http://support.microsoft.com/support/kb/articles/q183/4/00.asp).

Many administrators also use another utility, ESEUTIL, to defragment databases. However, you must perform a backup immediately before and after an ESEUTIL defragmentation because ESEUTIL changes the internal structure of the log files. The log files on the tape before the defragmentation are incompatible with the log files on the hard disk after the procedure.

Be Prepared
Even the most rigorous backup regimen isn't flawless. As the sidebar "Don't Forget the Hardware" notes, you must be alert for hardware failures, too. However, as an Exchange administrator, one of your tasks will surely be the disaster recovery plan for your site. And as more companies consider email a mission-critical application, your managers will entrust you with making your Exchange server as bulletproof as possible. A solid disaster recovery strategy will go a long way toward not only protecting the server from a cataclysmic disaster, but giving you peace of mind in knowing you have done all you can.

However, backing up is only half the story. In a future article, I'll talk about the restore process. I'll take you through a real-life restoration—one where I remove all the Exchange files from a server and then restore the database and log files from tape.