Article ID: 191357 - View products that this article applies to.
This article was previously published under Q191357
This article has been archived. It is offered "as is" and will no longer be updated.
This article discusses the recommended approach to restoring a single database from full online backups for Microsoft Exchange Server 5.5. This article further assumes that you do not want to play forward beyond the date of the backup.
Assume that full backups are being taken of the information store databases (Priv.edb and Pub.edb), and the following backups have been made:
Assume that on Tuesday, a user deleted an important public folder and that to restore it, you need to recover the Pub.edb database back to Monday's backup and do not want to play forward any other transactions (you do not want the delete of the folder to be replayed). Also, you do not want to lose any data in the Priv.edb database.
Since the goal is to restore an old backup of a database, and not play forward, it will be necessary to remove log files that exist after the point in time you want the database to be restored to. In our scenario, anything after Log #1 should be removed. It is only safe to remove log files if the databases are consistent (which happens as a normal part of shutting down the information store). To remove the log files:
Log files contain the database signature of databases they are associated with. If the database signature has changed for a database, the Exchange database engine may produce an event log error about the inconsistency. In our example, if the Priv.edb database has been defragmented offline (which changes the database signature) after the date of the backup that we restored, the transaction log files restored from tape will be expecting a Priv.edb with a different database to be present. After restarting the information store and all the transaction logs have replayed, the Exchange database engine may log the following error:
EventID: 134 Source: ESE97 Type: Error Category: Logging/Recovery Description: ((263) ) The database C:\ExchSrvr\mdbdata\priv.edb created at 3/19/1998 14:43:38 was not recovered.
This error is logged because during the the Exchange database engine initialization process, an attempt is made to associate the log files on the disk to the database. Because the database was defragmented, it carries a new database signature which prevents Jet from associating the log files to the database. This is not a fatal error, nor does it imply that the Priv.edb database is somehow damaged. Since the restore was for Pub.edb, and Priv.edb was in a consistent state, no transactions would have played into the Priv.edb database even if the database signature was still the same.
After recovery, the information store will run in a normal state with the current Priv.edb and the old Pub.edb.
You will see the following Warning by the information store:
EventID: 1091 Source: MSExchangeIS Type: Warning Category: Recovery Description: You have restored a public information store only. This server contains a private information store and a public information store. Only the data in the public information store has been modified.
NOTE: Because the original transaction log files were removed in step 4 above (anything above Edb0001.log in our scenario), the Exchange database engine generation number will be started at the next log file number. This implies that the next log file in our example would be Edb0002.log. Because there was already an Edb0002.log file backed up in Backup#2, care must be taken to not confuse the log file numbers. A full online backup should immediately be taken, and all previous backups discarded (to avoid conflicts with transaction log files in the future).
Article ID: 191357 - Last Review: October 10, 2013 - Revision: 3.3