A word to the wise about off-line backup and restore

By Jerry Cochran 01 Nov 2004 | SearchExchange.com

Digg This!     StumbleUpon     Del.icio.us

The following is tip #4 from "20 tips on protecting and recovering Exchange data in 20 minutes," excerpted from the book, "Mission Critical Microsoft Exchange 2003" (Digital Press, a division of Elsevier, Copyright 2004). For more information about this book and other computing titles, please click here. Return to the main page for more tips on this topic.

Microsoft has strongly educated Exchange implementers about the benefits and necessities of performing on-line backup operations. When calling Microsoft PSS, you will be hard-pressed to find a sympathetic ear if your only means of Exchange Server recovery is an off-line backup. Microsoft has specific reasons for enforcing its recommendations for on-line backups. The main reason is that on-line backups, which utilize the ESE APIs, have awareness of the transactional nature of the Exchange data¬base engine. If you simply treat the Exchange database as a file, no transactional integrity of the database is maintained.

An on-line backup not only will back up the database, but will also back up log files and provide log file truncation. In addition, on-line backups for Exchange provide management on the restore side as well. When restoring backup sets created using on-line methods, the database engine is able to provide recovery up to the very last transaction recorded by utilizing the log files. All around, on-line backups are a preferable method. I recommend against the practice of offline methods unless they are used as a mechanism for periodic archival or your databases.

Unfortunately, many have still chosen to use off-line methods to backup their Exchange servers. In an off-line scenario, all Exchange services are shut down in order to perform the backup or restore operation.

Backup operations simply treat the Exchange information store databases as individual files in the file system. EDB and STM files would be backed up just like any other file on the server. This can be very problematic for several reasons. First, since an off-line backup method does not utilize the ESE API, no integrity checking of the database is performed (unless you do it manually with ESEUTIL, ESEFILE, or ISINTEG).

Remember, using an on-line method and performing a normal (or full) backup will verify each and every page of the database during the backup procedure. Another problem with the off-line backup method for Exchange is that the operator must take responsibility for managing database transaction log files.

The transaction log files are required for successful recovery of the database up to the point of the last transaction that occurred. Suppose, for example, you needed to recover your Exchange 2000/2003 server (either an individual database or an entire storage group) from an off-line backup. If your backup was performed at midnight (12 a.m.), you would have a consistent copy of the data for that point in time, assuming the services were stopped or an individual database (store) was dismounted.

In our example scenario, suppose a failure condition were to occur at 2 p.m. (14 hours later) and you were forced to recover the database. If the failure were mild enough (such as database corruption), you would be able to restore the database files (EDB+STM), but would not be able to play through the existing log files that have accumulated (representing real user data) since the database files were backed up.

The greatest potential for error with off-line backup methods occurs during the restore of an off-line database -- the database engine does not automatically play through the log files as it would normally do in the case of an on-line backup.

There are certainly ways to accomplish the task, but this must be accomplished through manual log file management and the use of scripts and "hacks" that attempt to mimic the on-line recovery operations. Realistically, there is no point to this exercise since that is the purpose for which Microsoft designed the on-line backup APIs.

While you may have been able to devise methods of safe recovery using off-line methods in previous versions of Exchange, Exchange 2000/2003 will make it virtually impossible to enjoy success using off-line methods. In previous versions of Exchange (prior to Exchange 2000), the fact that there was a single private and public information store (PUB.EDB and PRIV.EDB) made it possible (although still prone to error) to implement successful disaster-recovery procedures based on off-line methods. There were only two database files and one ESE database engine instance (storage group) in previous versions of Exchange.

Consider Exchange 2000/2003, however, in which you can configure up to four storage groups (even more in later releases) on a server -- each with five databases. Further consider the fact that the database is now two files (*.EDB and *.STM) instead of one. Putting all of this together, you can see the difficulty in implementing a backup strategy based on off-line methods for Exchange 2000 on a server with multiple storage groups and databases.

Here is my bottom line for this discussion: I hope I have convinced you to stay away from an off-line approach and only to use this method for periodic archival or as an added measure of protection that is complementary to on-line, API-based back¬ups.

Off-line backups are, arguably, still useful as a last-ditch recovery tool before, for example, a major hardware upgrade -- do a full backup to truncate the logs, shut down or dismount and then do the full off-line backup.

Whatever your preference, ensure that you understand the pitfalls of offline backups with Exchange Server.

Get more "20 tips on protecting and recovering Exchange data in 20 minutes." Return to the main page.

About the author: Jerry Cochran is a contributing editor for Windows IT Pro and Exchange & Outlook Administrator and a group program manager for Microsoft. He is the author of Mission-Critical Microsoft Exchange 2000 (Digital Press).

Digg This!     StumbleUpon     Del.icio.us