Verify that the corruption is not the result of an offline log drive, offline database drive, or a disk volume configuration error. If the log volume of the production storage group is not available (and could be available) at the time of the failover, more data may be lost than necessary.

Assess if the data in the passive copy of the database is acceptable. For guidance about how to make this determination, see How to View the Status of a Local Continuous Replication Copy. Typically, the system should be able to recover with all data from the active copy of the database. Thus, the assessment should show that all necessary log files are available. If this is not the case, you should investigate why some or all log files are unavailable.

Dismount the corrupt database. You can use the Dismount-Database cmdlet in the Exchange Management Shell or the Dismount shortcut menu option for the database in the Exchange Management Console.

Use the Restore-StorageGroupCopy cmdlet as follows to activate the copy of the database. This can be done in one of two ways:

Note:
The LCR copy is automatically disabled as part of running the Restore-StorageGroupCopy cmdlet.

1. To activate the copy and leave the production storage group and database paths unchanged, run the following cmdlet:
   
   

   	Copy Code
   Restore-StorageGroupCopy -Identity:<Server>\<StorageGroupName>

   Note:
   The preferred way is to activate the copy in its current location, move the files, change drive letters, or mount point assignments to get the copy files positioned under the production paths. Through this strategy, the production database is maintained in its expected location.

2. To activate the copy and update the production storage group and database paths with those of the LCR copy, run the Restore-StorageGroupCopy cmdlet with the -ReplaceLocations option as follows:
   
   

   	Copy Code
   Restore-StorageGroupCopy -Identity:<Server>\<StorageGroupName> -ReplaceLocations:$true

   Note:
   An administrator could be subsequently surprised by this if left in place for an extended period. The deciding factor should be whether the copy's files can be relocated in minutes, and thus permitting the desired rapid recovery.

At the confirmation prompt, type Y and then press ENTER.

Perform this step if you performed Step 4a where the production paths were unchanged (-ReplaceLocations was not specified in the Restore-StorageGroupCopy cmdlet). The passive copy's files must be relocated into the production storage group and database paths. Use the appropriate file system or volume management tool to move the logs, system files, and database of the LCR copy to these locations.

The database can now be mounted.

The Restore-StorageGroupCopy cmdlet automatically disables LCR for the storage group. LCR must be enabled after the recovery is complete. For detailed steps about how to enable LCR for the storage group, see How to Enable Local Continuous Replication for an Existing Storage Group.