Migrating Data from the DR Center back to HyperMetro Data Centers

After HyperMetro data centers recover from a fault, services will be migrated back to them.

Prerequisites

Application-based protection policies and recovery plans have been configured for database applications or VMware vSphere and FusionCompute deployed on physical machines.
LUN-based protection policies and recovery plans have been configured for other applications.
For protected groups that use asynchronous remote replication, the DR center has at least one copy of intact service data.
In a DR Star network, before performing planned migration, log in to DeviceManager and ensure that the running status of the DR Star network is Enabled.
The datastore name cannot contain Chinese characters.

In HyperMetro (NAS) and asynchronous replication (NAS) scenarios, the reprotection operation is not supported on eReplication after services are switched to the remote DR center.

Context

Services are migrated from HyperMetro data centers to the DR center due to a recoverable fault such as an unexpected power failure. After the HyperMetro data centers recover from the fault, you must synchronize data generated during the DR from the DR center to the HyperMetro data centers and migrate services back to the HyperMetro data centers.

Figure 1 shows the state of data replication between storage arrays before failback.

Figure 1 Data replication before failback

Procedure

In HyperMetro (SAN) and asynchronous replication (SAN) scenarios, you can use eReplication to migrate back services as follows:
1. Check the environment before starting the reprotection.
  1. Log in to a service host in an HyperMetro data center and stop services.
    - For databases: Manually stop applications in the production center and unmount host disks. Then log in to the storage array management software of the HyperMetro data centers, and remove mappings of LUNs used by applications from hosts.
    - For VMware VMs: Use vSphere Client to connect to VMware vCenter in the production center. Power off protected VMs, remove them from the list, and uninstall datastores used by the VMs.
    - For FusionCompute VMs: Log in to the FusionCompute, power off protected VMs, and uninstall datastores used by the VMs.
  2. Suspend HyperMetro pairs that are at active end of storage arrays in the HyperMetro data centers.
    Figure 2 shows the state of data replication between storage arrays before the planned migration.
    Figure 2 Data replication before the planned migration
1. Perform reprotection to protect services migrated to the remote DR center.
  After the planned migration is complete, the application system is working at the remote DR site and protected groups become Invalid. You must perform reprotection to recover the replication status and synchronize data from the remote DR center to the HyperMetro data centers.
  
  To ensure the normal running of protected groups and recovery plans after reprotection, the system automatically clears protected and recovered configurations, including startup configurations of protection policies and recovery plans, self-defined execution scripts, and self-defined execution steps. In addition, reconfiguration of protection and recovery policies is recommended to ensure the continuity of DR services.
  1. On the menu bar, select Utilization > Data Restore.
  2. Select the recovery plan and click More > Reprotection on the Operation list.
    If the protected objects are VMware VMs and services are recovered from site A to site B, perform the following steps to clear redundant and incorrect data in the virutalization environment before and after the reprotection:
    1. Log in to the vCenter server at site A using vSphere Client.
    2. Close and migrate all VMs that are recovered to site B by recovery plan registration.
    3. On ESXi hosts in the cluster from which VMs are migrated, uninstall datastores used by the VMs one by one.
    4. For LUNs used by the uninstalled datastores, detach the LUNs from the datastores.
    5. Click Storage. All storage devices are displayed. In the row where each storage device resides, click Rescan All to ensure that no datastore exists on ESXi hosts.
    6. Return to eReplication, and refresh vCenter servers and storage resources on both sites to obtain the latest VM environment information.
    7. Perform reprotection.
  3. Carefully read the content in the Confirm dialog box that is displayed and click OK to confirm the information.
    
    If Save user configuration data is selected, self-defined protection policies and recovery settings, such as self-defined recovery steps, will be retained. Ensure that the configuration data has no adverse impact on service running after reprotection.
    
    Figure 3 shows the state of data replication between storage arrays after the reprotection.
    Figure 3 Data replication after the reprotection
1. Test recovery plans and clear data generated during tests.
  Before services are migrated back, perform a DR test to verify data availability to ensure service failback success rate. After the test, clear test data to avoid failback failures caused by the test data. For details, see DR Testing.
2. Perform planned migration.
  Migrate services back to the HyperMetro data centers. After the migration, check data and clear test data. For details, see 1 to 4 in Performing Planned Service Migration from an HyperMetro Data Center to the Remote DR Center
  
  When the protected object type is Oracle, IBM DB2, or Microsoft SQL Server, select hosts or host groups in the original production center as recovery targets.
  
  If the protected object type is VMware VM, select vCenter and clusters in the original production center as recovery targets.
  
  You can select Synchronize HyperMetro to enable HyperMetro synchronization.
  
  Figure 4 shows the state of data replication between storage arrays after the planned migration.
  
  Figure 4 Data replication after the planned migration
1. Perform reprotection again.
  After the planned migration is complete, application systems are working in HyperMetro data centers and protected groups become Invalid. To ensure that services migrated back to the original HyperMetro data centers can be recovered at the remote DR center after an event (planned or unplanned) happens, reprotection must be performed and the replication status from HyperMetro data centers to the remote DR center must be recovered to synchronize data generated at the HyperMetro data centers to the remote DR site and to ensure that services are protected. For details, see see 5 to 6 in Performing Planned Service Migration from an HyperMetro Data Center to the Remote DR Center.
  
  Figure 5 shows the state of data replication between storage arrays after the reprotection.
  
  Figure 5 Data replication after the reprotection

----End