This article discusses the recommended approach to restoring a singledatabase from full online backups for Microsoft Exchange Server 5.5. Thisarticle further assumes that you do not want to play forward beyond thedate of the backup.
Assume that full backups are being taken of the information storedatabases (Priv.edb and Pub.edb), and the following backups have been made:
- Monday - Full backup of information store (Backup #1, Log #1)
- Tuesday - Full backup of information store (Backup #2, Log #2)
- Wednesday - Full backup of information store(Backup #3, Log #3)
- Thursday - Full backup of information store(Backup #4, Log #4)
During a full online backup, log files that have been committed to thedatabases are removed from disk. Following Thursday's backup, assumethat only Log #4 exists on disk.
Assume that on Tuesday, a user deleted an important public folder and thatto restore it, you need to recover the Pub.edb database back to Monday'sbackup and do not want to play forward any other transactions (you do notwant the delete of the folder to be replayed). Also, you do not want tolose any data in the Priv.edb database.
Since the goal is to restore an old backup of a database, and not playforward, it will be necessary to remove log files that exist after thepoint 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 logfiles if the databases are consistent (which happens as a normal part ofshutting down the information store). To remove the log files:
- Stop the information store.
- Ensure the Priv.edb database is consistent. To do so, at the command prompt, run:
eseutil /mh priv.edb
- Do a full offline backup of the Priv.edb database and log files (this is a safety measure -- the backup isn't needed as part of the solution steps).
- After the offline backup completes, remove any log files that are present as well as the checkpoint file (*.log, Edb.chk).
- Restore the Pub.edb database from Backup #1. From within the Ntbackup program, select the Public check box, and clear the Private check box.
- Start the information store (if it didn't start automatically based on your restore selection).
Because the Pub.edb database is restored from tape in an inconsistent state(which is normal) with the log files at the time of backup, when theinformation store starts, recovery will begin, and will replay the newlyrestored transaction log files. The Priv.edb database will not be affectedby this operation.
Log files contain the database signature of databases they are associatedwith. If the database signature has changed for a database, the Exchangedatabase 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 thatwe restored, the transaction log files restored from tape will be expectinga Priv.edb with a different database to be present. After restarting theinformation store and all the transaction logs have replayed, the Exchangedatabase 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 engineinitialization process, an attempt is made to associate the log files on thedisk to the database. Because the database was defragmented, it carries anew database signature which prevents Jet from associating the log filesto the database. This is not a fatal error, nor does it imply that thePriv.edb database is somehow damaged. Since the restore was for Pub.edb,and Priv.edb was in a consistent state, no transactions would have playedinto the Priv.edb database even if the database signature was still the same.
After recovery, the information store will run in a normal statewith 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 4above (anything above Edb0001.log in our scenario), the Exchange databaseengine generation number will be started at the next log file number. Thisimplies that the next log file in our example would be Edb0002.log. Becausethere was already an Edb0002.log file backed up in Backup#2, care must be taken tonot confuse the log file numbers. A full online backup should immediatelybe taken, and all previous backups discarded (to avoid conflicts withtransaction log files in the future).