How Exchange Online Backups Work in Exchange Server 2003
Topic Last Modified: 2005-05-23
Microsoft® Exchange Server databases can be backed up while users are online, even as new data is written to them. This capability exists because of Exchange's transaction logging mechanism (as discussed in Appendix B, "Exchange Transaction Logging").
As you begin an online backup, the backup program streams the database file to the backup medium. Changes to the database continue, even to parts of the database that have already been backed up. These missed changes will later be reconstructed from transaction log files.
After the database file has been backed up, Exchange copies at least one transaction log (and usually several of them) to the backup set. These are the transaction logs generated from the time the backup starts until just after it finishes.
|Prior to Exchange2000 Service Pack2, a patch file (database_name.pat) was created during backup and was saved with the backup set. The patch file was needed to reconstruct a small subset of possible database changes that could not be preserved in the transaction logs. In newer versions, Exchange no longer saves the patch data to a separate file, but inserts it at the end of the database file. For more information about how patch data is used when restoring an online backup, see Transaction Log File Replay: Soft Recovery and Hard Recovery in Exchange Server 2003.|
When you restore an online backup, you always replay at least one transaction log into it. If you examine the header of a restored database before transaction logs are played into it, you see that it reads "Dirty Shutdown." Restoring a database from online backup and then starting it is similar to starting a database after a system crash.
Replaying logs after an unexpected database stop is called soft recovery. Replaying logs after restoring an online backup is called hard recovery. The most important difference between the two kinds of recovery is the application of the extra patch data during hard recovery.
Because Exchange replays transaction logs during recovery of every online backup, it is possible to add more transaction logs to be replayed than were originally on the backup tape. If E0000007.log is on the backup tape, and you have log E0000008.log and others going forward, you can continue log file replay after restoring the online backup as long as there are available logs in an unbroken series. Even if your backup is several days old, you can bring it completely up-to-date as long as you have all the transaction logs generated since the backup was made.
Suppose that you made an online backup of the database on Monday. On Wednesday, the database files were destroyed by a hard disk failure, requiring you to restore Monday's backup. If the transaction log files for the last two days still exist, it is possible to restore Monday's backup and recover all data from Tuesday and Wednesday by retrieving the data from the transaction log files.
|It is an Exchange best practice to keep transaction log files on a dedicated disk separate from the database files. Not only does this improve database performance, but it also provides fault tolerance in case the database disk is destroyed.|
There are four kinds of online backups of an Exchange database: normal, copy, incremental, and differential. You may be familiar with these terms; however, the meaning that Exchange assigns to each of them differs from conventional usage:
Normal The backup program backs up the database files (.edb and .stm), patch data, and at least one log file. After backup is complete, the backup program deletes all log files prior to the checkpoint at the time that backup began; this prevents log files from accumulating until they use up all available drive space. Note that in current versions, Exchange no longer keeps patch information in a separate file, but appends a patch header page to the end of the database file when the backup process is complete.
Copy The same as a normal backup, except that the backup program does not delete old log files, and does not update the database header to indicate that a backup has taken place.
Incremental The backup program only backs up log files, not database files. Log files since the last normal backup are copied to the backup medium and are then purged from disk. To restore an incremental backup, you must also restore an earlier normal or copy backup because the incremental backup does not contain the database files. Transaction logs from the incremental backup can be replayed after the logs from the full backup are replayed, assuming that there is an unbroken sequence of logs between the two backups.
Differential The same as an incremental backup, except that the backup program does not delete old log files from disk.
In terms of the files actually placed on the backup medium, there is no difference between a normal and copy backup, and no difference between an incremental and differential backup.
Exchange 5.5 has only one storage group. It holds only two databases, a mailbox database and a public folder database. Starting the Information Store mounts both databases and stopping the Information Store disconnects both of them. Beginning with Exchange 2000, however, a server can hold up to 20 Exchange store databases spread over four storage groups. Each database is capable of being independently mounted and dismounted. This flexibility has important ramifications for restoring online backups.
Recall that all the databases in a storage group share the same set of log files, and that restoring an online backup requires replaying some log files. With Exchange 2003, you can now restore one database in a storage group while others are running. This capability means that there are several scenarios in which restoration of log files could cause hard recovery failure or interfere with the operation of other databases in the storage group. Further, it is possible that multiple simultaneous restore operations could occur at once.
To prevent various interaction problems, log files from online backups are now restored to a temporary folder, along with a Restore.env file that controls the hard recovery process. Restore.env is not in plain text format, but its contents can be viewed with the command Eseutil /cm.
|Exchange5.5 administrators may be familiar with the Restore in Progress registry key, which serves much the same purpose for Exchange 5.5 that Restore.env serves for newer versions of Exchange. There is no Restore in Progress registry setting for Exchange 2000 and later versions.|
If you are restoring multiple online backups (for example, a single full backup and several incremental backups), you do not want hard recovery to begin before all backups have been restored. You have only one opportunity to replay log files into a restored database; therefore, hard recovery must be postponed until all necessary log files are in place.
If you are using Backup to restore an online backup, you indicate that you are ready to begin hard recovery by selecting the Last Backup Set check box before restoring your final backup set. (Other backup applications may implement this differently.) If you do not select the Last Backup Set check box when restoring the last backup, you can still complete hard recovery manually with the Eseutil /cc command. You should run this command from the folder where Restore.env exists.
After hard recovery finishes processing log files in the temp folder, other transaction logs in the storage group's normal transaction log folder can be replayed as long as they continue in an unbroken sequence with the logs in the temp folder.
Restoring a single Exchange online backup set is a straightforward operation. You need only pick a target server, pick a temporary location on the server for the restored log files, and set hard recovery to run automatically after restore is complete. However, if you are restoring multiple backup sets, you should understand how log file replay works, and how to verify that you have actually restored all needed files. Transaction Log File Replay: Soft Recovery and Hard Recovery in Exchange Server 2003 describes the log file replay and recovery process in more detail, and Cross-Matching Exchange Databases and Log Files in Exchange Server 2003 explains how to check a set of log files to make sure they belong together and are complete.