How to Restore Production Database Access After a Server Failure
Applies to: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007
Topic Last Modified: 2008-05-13
This topic explains how to recover from corruption in the active database or storage group of a server that is configured for cluster continuous replication (CCR).
To perform this procedure, the account you use must be delegated the following:
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 Microsoft Exchange Server 2007, see Permission Considerations.
If one or more databases do not automatically mount during a failover, either the clustered mailbox server is configured for lossless recovery or the copy was outside the configured criteria. In either case, you must determine if the copy is in a state that warrants making it available to users. You must perform the following procedure for each affected database.
Get the status of the passive copy for the storage group by running the following command:
If you decide to use the available copy, you must run the Restore-StorageGroupCopy cmdlet to terminate replication and make the copy available to be mounted. Run the following command to restore a storage group copy:
Note: When the Restore-StorageGroupCopy cmdlet is run, it will present a prompt to complete the restore operation. If you want to complete the restore operation, click Yes. Important: If you choose to not complete the restore operation when prompted, you can run the command again at a later time.
After the Restore-StorageGroupCopy command has successfully completed, the database can be mounted. You can mount the database using either the Exchange Management Shell or the Exchange Management Console by following the procedures detailed in How to Mount a Database in a CCR Environment.
Important: After the copy is activated, the corrupted copy must be restored to a condition where it can be a replication target. This task may involve repairing the hardware problem that caused the corruption or failure.