Applies to: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007
Topic Last Modified: 2006-12-21

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).

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.


To recover from data corruption in a server that is configured for CCR

  1. Identify the passive node of the clustered mailbox server by running the following command:

    Copy Code
    Get-ClusteredMailboxServerStatus -Identity:<Name>
  2. Verify that the corruption is not the result of an offline log drive, offline database drive, or a volume configuration error.

    If the log volume on the active node is not available at the time of the failover, more data may be lost than necessary.
  3. Move the clustered mailbox server from the active node to the passive node using the Move-ClusteredMailboxServer cmdlet as follows:

    Copy Code
    Move-ClusteredMailboxServer -Identity:<Name> -targetmachine:<TargetName> -movecomment:<Comment>
    For more information about the Move-ClusteredMailboxServer cmdlet, see Move-ClusteredMailboxServer.
    If you determine that the logs are not available, you should insert the -ignoredismounted argument as shown in the following sample code:
    Copy Code
    Move-ClusteredMailboxServer -Identity:<Name> -targetmachine:<TargetName> -ignoredismounted -movecomment:<Comment>
    If a failure occurs late in the move processing, the transition of ownership of the clustered mailbox server occurs, but any affected databases are left offline.
  4. After the move operation is complete, make sure that all volumes have mounted. If one or more databases did not mount, you must determine the status of the local copy using the Get-StorageGroupCopyStatus cmdlet. You must determine if the source is exposing all available log files prior to running Restore-StorageGroupCopy or whether you are satisfied with the state of the copy.

  5. If logs were not available to make the process lossless for all storage groups, the Restore-StorageGroupCopy cmdlet must be run as shown:

    Copy Code
    Restore-StorageGroupCopy -Identity:"mbx01\SG1"
    When the Restore-StorageGroupCopy cmdlet is run, it displays the state of the storage group copy and presents a prompt to complete the restore option. If you want to complete the restore operation, enter Yes.
    If you choose not to complete the restore operation when prompted, you can run the command again at a later time.
    For more information about the Restore-StorageGroupCopy cmdlet, see Restore-StorageGroupCopy.
  6. The database can now be mounted. To mount the database, you can use either the Exchange Management Shell or the Exchange Management Console as detailed in How to Mount a Database in a CCR Environment.

  7. If you selected Yes to complete the restore operation, after the restore is complete, you must manually mount the database in the storage group as described in the topic How to Mount a Database in a CCR Environment. In the absence of further failures, these steps will activate the copy on the passive node.

    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.

For More Information

For more information about bringing databases online, see How to Mount a Database in a CCR Environment.

For more information about the Get-ClusteredMailboxServerStatus cmdlet, see Get-ClusteredMailboxServerStatus.