Applies to: Exchange Server 2007 SP3, Exchange Server
2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007
Topic Last Modified: 2006-12-19
This topic explains how to recover a cluster continuous replication (CCR) copy after a database has been detected as corrupted.
There are two cases that must be considered:
- The corruption is localized to the passive
copy. In this case, the node may have become
passive as part of a scheduled outage to recover from corruption on
the active server, or the corruption could have occurred during the
passive processing.
- The corruption exists on the active
server. This condition is detected as part of
recovering from the passive copy's corruption.
You are encouraged to address corruption or volume failures in the copy as rapidly as practical. During the period of time that the condition is not resolved, the passive node is not a good recovery target for the affected database. Therefore, should a failure occur, the affected database would be unable to be mounted, thus preventing mailboxes hosted on it from being accessible.
Before You Begin
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.
Procedure
To restore a cluster continuous
replication copy after a database is determined to be
corrupted
-
When corruption is detected in the passive copy, an assessment of the storage volume for the passive database must be made. Is the storage experiencing specific issues that make it an inappropriate host for the database file? You must consult your hardware diagnostics and hardware event reporting to make this assessment.
-
The only recovery method for a corrupted database is seeding the passive copy. The steps to complete this procedure are detailed in How to Seed a Cluster Continuous Replication Copy.
Note:If the Update-StorageGroupCopy cmdlet detailed in How to Seed a Cluster Continuous Replication Copy fails due to corruption in the production database, the production corruption issue must be addressed. You will need to restore from a valid backup and run recovery with all logs since the last full backup successfully occurred. Consult your backup application documentation to determine the steps required to complete the restore operation.