(0) exportieren Drucken
Alle erweitern

Rebuild an Entire Database Availability Group

 

Letztes Änderungsdatum des Themas: 2011-02-10

A database availability group (DAG), together with mailbox database copies, can provide automatic recovery from a variety of server, storage, network, and other hardware failures. A DAG can also provide a site resilience solution so that you can perform a datacenter switchover in the event of a site-level disaster. But even a comprehensive, intelligent, and robust solution such as a DAG can't protect you from all possible disasters, including disasters that affect an entire DAG.

For example, consider a two-member DAG deployed in a single datacenter. If the datacenter experiences a flood, fire, or other cataclysmic event that destroys the DAG, the entire DAG will need to be rebuilt from scratch. Rebuilding a DAG is a straightforward process that consists of nine primary steps:

  1. Prepare Active Directory for the Introduction of Servers with the Same Name

  2. Prepare the DAG's Cluster Name Object

  3. Remove the Database Copies from the DAG

  4. Remove the Mailbox Servers from the DAG

  5. Build Replacement Mailbox Servers

  6. Run Setup /m:RecoverServer on Each DAG Member

  7. Restore and/or Mount Mailbox Databases

  8. Add Mailbox Servers to the DAG

  9. Add Mailbox Database Copies to the DAG

We'll take a closer look at each of these steps, but first let me illustrate the example environment that you'll work with throughout this article.

In this article, you'll work with a two-member DAG named DAG1 that contains Mailbox servers named MBX1 and MBX2. MBX1 hosts the active copy of a database named DAG1-DB1, which is replicated to MBX2. In addition to hosting the passive copy of DAG1-DB1, MBX2 also hosts the active copy of DAG1-DB2, which is replicated to MBX1.

DAG used in example recovery

In Beispielwiederherstellung verwendete DAG

Microsoft Exchange Server 2010 derives security permissions based on the computer account for each server. To preserve these security permissions, the computer account for each DAG member needs to be reset and disabled using Active Directory Users and Computers.

  1. Using Active Directory Users and Computers, locate the computer account for each DAG member.

  2. Right-click the computer account for MBX1, point to All Tasks, and then select Reset Account.

  3. Right-click the computer account for MBX1, point to All Tasks, and then select Disable Account. When the prompt appears, click Yes, and then click OK.

  4. Repeat steps 2 and 3 for MBX2.

After Active Directory replication is complete, you can build new Windows servers using the names MBX1 and MBX2. If you've already built two replacement servers, you can rename them to MBX1 and MBX2 respectively.

Each DAG has an underlying Windows failover cluster. The name you give to a DAG becomes the name of the cluster, and a corresponding cluster name object (CNO) is created in Active Directory with this name. A CNO is the equivalent of a computer account for a cluster.

The names of the DAG and the CNO aren't used by end users or administrators. They're used by the system for internal communication and to secure the DAG. To preserve and reuse this name for the rebuilt DAG, the CNO for the DAG also needs to be reset and disabled using Active Directory Users and Computers.

  1. Using Active Directory Users and Computers, locate the CNO for the DAG. In our example, the name of the CNO is DAG1.

  2. Right-click the computer account for DAG1, point to All Tasks, and then select Reset Account.

  3. Right-click the computer account for DAG1, point to All Tasks, and then select Disable Account. When the prompt appears, click Yes, and then click OK.

Allow time for Active Directory replication to complete before proceeding with the next step.

Before you can recover Mailbox servers that are members of a DAG, you must first remove all mailbox database copies from the server. When that is complete, you must then remove the server from the DAG. In our example environment, this process involves removing all passive database copies from the DAG. Specifically, you would use the Remove-MailboxDatabaseCopy cmdlet to remove the passive copy of DAG1-DB1 from MBX2 and the passive copy of DAG1-DB2 from MBX1.

  1. Run the following Exchange Management Shell commands.

    Remove-MailboxDatabaseCopy -Identity DAG1-DB1\MBX2 -Confirm:$False
    Remove-MailboxDatabaseCopy -Identity DAG1-DB2\MBX1 -Confirm:$False
    
  2. Because the DAG members aren't operational, the commands will complete successfully but with several warning messages. You can verify that each mailbox database has a single copy by using the Get-MailboxDatabase cmdlet, as shown in the following examples.

    Get-MailboxDatabase -Server MBX1 | Format-List Name,DatabaseCopies
    Get-MailboxDatabase -Server MBX2 | Format-List Name,DatabaseCopies
    

Before you can recover a Mailbox server that is a member of a DAG, you must first use the Remove-DatabaseAvailabilityGroupServer cmdlet to remove the Mailbox server from the DAG. Because our example is a disaster recovery operation, we assume that MBX1 and MBX2 are either not operational or don't exist. As a result, the ConfigurationOnly parameter is used with the Remove-DatabaseAvailabilityGroupServer cmdlet. When this parameter is used, Remove-DatabaseAvailabilityGroupServer removes the Mailbox server from the DAG object in Active Directory.

  1. Run the following Exchange Management Shell commands.

    Remove-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer MBX1 -ConfigurationOnly:$True -Confirm:$False
    Remove-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer MBX2 -ConfigurationOnly:$True -Confirm:$False
    
  2. You can verify that each DAG member was removed by using the Get-DatabaseAvailabilityGroup cmdlet, as shown in this example.

    Get-DatabaseAvailabilityGroup -Identity DAG1 | Format-List Servers
    

    After all DAG members are removed, the Get-DatabaseAvailabilityGroup cmdlet should return a Servers attribute that's empty.

The next step is to rebuild the servers you're recovering, using the same computer names as the original production servers (in this example, MBX1 and MBX2), and the same operating system version as the servers being recovered.

HinweisAnmerkung:
The server recovery process is based on the name of the computer on which Setup is run. You can use different IP addresses, but the name of the server must match the original Mailbox server name for server recovery to complete.

The rebuild process is effectively the same process used to build the original production Mailbox servers.

  1. Install and configure Windows Server.

  2. Rename the computer with the appropriate name.

  3. Join the computer to the appropriate Active Directory domain.

  4. Install the prerequisites for running installed Exchange server roles. For details, see Exchange 2010 – Systemanforderungen.

After the replacement servers are built and ready for Exchange server recovery, the next step is to run the Exchange 2010 unattended setup process in recovery mode. You don't need to complete this step on each DAG member before moving to the next step (restoring and/or mounting databases). However, you do need to perform this step for each DAG member on which you want to mount databases.

  1. Open a Command Prompt window and navigate to the Exchange 2010 installation files.

  2. Run the following command.

    Setup /m:RecoverServer
    
  3. After Setup completes successfully, restart the recovered server to complete the recovery process.

Depending on the nature of the failure, the previously active copy of the databases hosted on these servers may not be available. If the files on disk are preserved and in their original location or copied to the original location, you should be able to use the Mount-Database cmdlet to mount the databases. Alternatively, you can restore your databases from backup to their original location, and then mount the databases.

After your mailbox databases are restored and/or mounted, service and data access should be restored for clients. The final steps are to reconfigure the Mailbox servers and databases for high availability by adding the recovered servers back to the DAG, and then creating mailbox database copies.

Adding Mailbox servers to a DAG can be accomplished by using the Add-DatabaseAvailabilityGroupServer cmdlet.

  1. Run the following Exchange Management Shell commands.

    Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer MBX1
    Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer MBX2
    
  2. You can verify that each DAG member was added by using the Get-DatabaseAvailabilityGroup cmdlet, as shown in this example.

    Get-DatabaseAvailabilityGroup -Identity DAG1 | Format-List Servers
    

The final step is to add mailbox database copies back to the appropriate DAG member. Depending on the nature of the failure, the previously passive copies of the databases hosted on these servers may not be available. If the files on disk are preserved and in their original location or copied to the original location, the Microsoft Exchange Replication service may be able to perform an incremental resynchronization of the passive copies, thereby eliminating the need for a full reseed. However, if the original passive copies aren't available, you'll need to perform a full reseed.

  1. To add the mailbox database copies back to the DAG, run the following commands.

    Add-MailboxDatabaseCopy -Identity DAG1-DB1 -MailboxServer MBX2
    Add-MailboxDatabaseCopy -Identity DAG1-DB2 -MailboxServer MBX1
    
  2. You can verify that each mailbox database copy was added successfully by using the Get-MailboxDatabase cmdlet, as shown in the following example.

    Get-MailboxDatabase | Format-List Name,DatabaseCopies
    
  3. You can also verify the health and status of all mailbox database copies in the DAG by using the Get-MailboxDatabaseCopyStatus cmdlet, as shown in these examples.

    Get-MailboxDatabaseCopyStatus -Server MBX1
    Get-MailboxDatabaseCopyStatus -Server MBX2
    

I hope you now have a better understanding of how to recover an entire Exchange 2010 DAG. To learn more about DAGs and the commands discussed in this article, see the following topics:

Tim McMichael Tim McMichael - Senior Support Escalation Engineer, Microsoft Customer Support Services

 
Fanden Sie dies hilfreich?
(1500 verbleibende Zeichen)
Vielen Dank für Ihr Feedback.
Anzeigen:
© 2014 Microsoft