Applies to: Exchange Server 2007 SP3, Exchange Server
2007 SP2, Exchange Server 2007 SP1
Topic Last Modified: 2007-08-21
Use the Restore Storage Group Copy wizard to make a passive copy of a database viable for a Mount-Database operation. This wizard should be used when the automatic mount support does not mount the database in a cluster continuous replication (CCR) environment. In this event, an administrator must explicitly intervene to mount the database. In this scenario, the administrator uses this wizard prior to performing the Mount-Database operation.
In a local continuous replication (LCR) environment, this wizard is used to disable LCR and make the passive copy of the database viable for the Mount-Database cmdlet.
 Note: |
|---|
| Before proceeding with this wizard, the database in the selected storage group must be dismounted. For LCR, this wizard must be run on the server hosting the storage group. |
This wizard can accomplish the following goals:
- It marks the storage group's databases as mountable.
- It provides a report on the data loss that will result from
mounting the databases in the storage group.
- It checks whether all logs created on the source server for the
storage group are present in the copy, and if not, it tries to copy
them one more time.
- For LCR, it also disables the storage group copy.
- For LCR, if the resulting database experiences a loss, content
indexing will re-index.
Verify that the correct storage group is listed in the Storage group name field. The Replace production database path locations with this copy check box is selected in an LCR configuration when the administrator wants to terminate replication and push the copy's paths into the production storage group and database location attributes. The production database and storage group objects' paths are updated with the locations from the copy. This will be a quick operation and allow an immediate mount of the database. If the option is not used, the data from the copy must be made available at the production locations. If this cannot be done via file system rename commands or volume operations, the outage duration will be proportional to the time required to copy the logs and databases.