The Restore-StorageGroupCopy cmdlet is required to enable a Microsoft Exchange Server 2007 administrator to mount a passive copy of a database or an SCR target database as part of the recovery from a failure or corruption of the active copy of the database. In an LCR configuration, it is expected that the administrator will relocate the data via a file system or volume operation, such as the use and changing of volume mount points. We recommend this method to maintain naming conventions between the paths used for the passive copy or SCR targets and the active copy of the databases.
The ReplaceLocations parameter is used in an LCR environment when the administrator wants to terminate replication and activate the passive copy of a database by changing the locations for these objects in the Active Directory directory service to point to the paths containing the passive copy of the storage group and database files. This is a quick operation, and after completion, you will be able to mount the database. If this option is not used, the data from the passive copy must be copied or moved to the paths for the active copy of the storage group. 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 database files.
In a CCR environment, the copy being activated is on a different node and already in the correct location. Thus, it is not necessary to change the location of the logs or database as part of the activation process.
You can use the Restore-StorageGroupCopy cmdlet to override the loss restrictions of mounting the storage group on the newly active node. For example, the AutoDatabaseMountDial may be set to Lossless, which means that the database will not mount if even one log file from the last mounted node could not be copied and replayed on the copy. When in this state, you can restore the storage group copy and mount the database.
.gif) Note: |
|---|
|
In certain circumstances, overriding the loss restrictions of mounting the storage group on the newly active node may require reseeding the previously active node storage group. Reseeding would be required if one or more of the logs in the loss region had been written to the database.
|
The Restore-StorageGroupCopy cmdlet terminates continuous replication for the storage group and makes the passive copy or SCR target database viable for the Mount-Database cmdlet. Specifically, use the Restore-StorageGroupCopy cmdlet in the following ways:
-
In a CCR environment, use the cmdlet when the automatic mount support does not mount the database and the administrator must explicitly intervene to mount the database.
-
In an LCR environment, use the cmdlet to disable LCR and make the passive copy viable for the Mount-Database cmdlet.
-
In an SCR environment use the cmdlet to disable SCR and make the SCR target copy viable for the Mount-Database cmdlet.
The Restore-StorageGroupCopy cmdlet can accomplish the following goals:
-
It marks the storage group's database as mountable.
-
It provides a report on the data loss, if any, that will result from mounting the database in the storage group.
-
It verifies that all of the log files generated by the active copy of the storage group are present in the passive copy's storage group files location. If any log files are missing, the operation will try to copy the missing log files.
| Note: |
|---|
|
If all of the required log files are not available, and the Restore-StorageGroupCopy cmdlet fails to successfully copy them from the active storage group files location, the database will experience a data loss. For information about how CCR manages data loss, see Cluster Continuous Replication.
|
-
For LCR and SCR, it also disables continuous replication.
-
For LCR, if the database experiences any data loss, the content index will need to be re-created.
-
For LCR, this command must be run on the server hosting the storage group.
| Note: |
|---|
|
For CCR, for the passive copy to become the active copy, it must first be mounted. After being mounted and active, it will become the new active copy for subsequent replication activity.
|
To run the following code, the account you use must be delegated the Exchange Server Administrator role and local Administrators group for the target server. For more information about permissions, delegating roles, and the rights that are required to administer Exchange 2007, see Permission Considerations.