How to Restore Production Database Access After a Single Database Failure
Microsoft Exchange Server 2007 will reach end of support on April 11, 2017. To stay supported, you will need to upgrade. For more information, see Resources to help you upgrade your Office 2007 servers and clients.
Applies to: Exchange Server 2007, Exchange Server 2007 SP1, Exchange Server 2007 SP2, Exchange Server 2007 SP3
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
Identify the passive node of the clustered mailbox server by running the following command:
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.
Move the clustered mailbox server from the active node to the passive node using the Move-ClusteredMailboxServer cmdlet as follows:
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:
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.
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.
If logs were not available to make the process lossless for all storage groups, the Restore-StorageGroupCopy cmdlet must be run as shown:
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.
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.
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.