HP XP Racks - Manual (Page 400)

• You cannot simultaneously create the replica of the active and passive mailbox database copies.
Wait until execution of the replica creation is finished for the first mailbox database copy before
you begin create the replica of the other mailbox database copies.
• When you restore a replica, the target mailbox database copy must be an active mailbox database
copy.
• A replica can be restored only to the Exchange Server 2010 server where the replica was created.
Replicas acquired from another Exchange Server 2010 server cannot be used for restoration.
• After restoration, you must execute the seed function to change the status of the Exchange Server
2010 replication function to normal.
• If you perform a restoration without using the seed function, the Exchange Server 2010 replication
function to be restored will be stopped, but the seeding will not be performed. After the restoration,
you must perform seed processing and restart the Exchange Server 2010 replication manually.
• If you create a replica of either the active mailbox database copy or a passive mailbox database
copy using the option for deleting transaction logs, you cannot perform a roll-forward restore using
the replica that was made before the transaction logs are deleted, regardless of the active mailbox
database copy or the passive mailbox database copy. Therefore, HP recommends that you use
the option to delete transaction logs for only one mailbox database copy (either the active or
passive).
• When performing a restoration, Microsoft Exchange Replication Service must be running on the
Exchange Server 2010 server that holds the Primary Active Manager role.
• Even if performing the seed after point time restore, the length of copy queue might not be 0. If
you switch over the mailbox database copy in this status, use the Exchange Management Shell.
The following is an example using the
Move-ActiveMailboxDatabase cmdlet:
Move-ActiveMailboxDatabase databasename -ActivateOnServer destination-servername
-SkipLagChecks:$True MountDialOverride:Besteffort
Related topics
• Restoring the latest application replica (simple restore) , page 395
About Database Availability Groups (DAGs)
Database Availability Groups are a high-availability feature implemented in Exchange 2010. DAGs
provide automatic database-level recovery from a database, server, or network failure. DAGs use
continuous replication and a subset of Windows failover clustering technologies to provide continuous
mailbox availability. Mailbox servers in a DAG monitor each other for failures. When a Mailbox
server is added to a DAG, it works with the other servers in the group to provide automatic,
database-level recovery from database failures.
NOTE:
There is a limit of 16 mailbox servers per DAG.
When a DAG is created, it is initially empty and a directory object is created in Active Directory that
represents the DAG. The directory object is used to store relevant DAG information, such as server
membership. When the first server is added to a DAG, a failover cluster is automatically created for
the group and the infrastructure that monitors the servers for network or server failures is initiated. The
failover cluster heartbeat mechanism and cluster database are then used to track and manage
information about the DAG, such as database mount status, replication status, and last mounted
location.
Replication Manager supports data backups and restores on a DAG configuration.
Managing application replicas 400