Executing Reprotection

If planned migration or fault recovery has been performed for a recovery plan, you can execute reprotection for the recovery plan. Reprotection protects data at the original disaster recovery (DR) site once devices at the original production site recover from disasters, simplifying failback.

Prerequisites

If reprotection needs to be performed after fault recovery, clear the environment of the original primary end and the recover replications of the original DR site switch to production site before performing other operations.

You have logged in to the eReplication as a user with DR management permission.
Planned migration or fault recovery has been performed for at least one recovery plan on eReplication.
Before performing reprotection, check whether protected groups at the original production site are in the Invalid state.
Before reprotection, underlying storage links, remote replications, and consistency groups have been recovered.

Demands in protection objects are described as following table.

Protection Object	Description
FusionCompute VM	If execute reprotection after executing planned migration, in array-based replication for DR, the storage device configuration of the original production site and original DR site must be correct. All underlying storage units corresponding to protected groups have remote replications. All remote replications have secondary LUNs that belong to storage devices at the original production site. If there are multiple remote replications, they must belong to a same consistency group. If add or delete the disk in the protected VM, refresh the VM and execute this protected group of protected VMs reside manually.

Protection Object

Description

FusionCompute VM

If execute reprotection after executing planned migration, in array-based replication for DR, the storage device configuration of the original production site and original DR site must be correct.
- All underlying storage units corresponding to protected groups have remote replications.
- All remote replications have secondary LUNs that belong to storage devices at the original production site.
- If there are multiple remote replications, they must belong to a same consistency group.
If add or delete the disk in the protected VM, refresh the VM and execute this protected group of protected VMs reside manually.

Context

In order to ensure the previous configuration does not effect the execution of protected group and recovery plan, the system will automatically clear protection and recovery configuration (includes the protected policy, startup setting for recovery plan, self-defined execution script and execution steps) . Please re-configure protected policy and recovery policy after you execute reprotection to ensure the normal operation of DR services.

If the recovery plan is based on the snapshot or clone protection policy template, reprotection cannot be performed.
Reprotection is not supported in the following scenarios:
- In solutions based cascading replication (synchronous and asynchronous) or parallel replication (synchronous and asynchronous), services switched to the remote DR site do not support reprotection.
- In solutions based on cascading replication (asynchronous and asynchronous), services switched to the remote DR site do not support reprotection.

Procedure

If the protected object is a VMware VM, to prevent unnecessary or incorrect data in the virtualization environment before and after the reprotection, perform the following operations. If the protected object is not a VMware VM, go to Step 2.
- If you have performed planned migration from site A to site B:
  1. Before reportection, if the reportection has been performed, log in to the vCenter server at site B from vSphere Client and perform Rescan All in Storage for all ESXi hosts in the clusters where VMs have been migrated to ensure that no datastore information is left on the ESXi hosts. Otherwise, you can ignore this step.
  2. Perform Step 2 to Step 4.
  3. Log in to the vCenter server at site A from vSphere Client. Perform Rescan All in Storage for all ESXi hosts in the clusters where VMs have been migrated to ensure that no datastore information is left on the ESXi hosts.
  4. Return to the eReplication system and refresh vCenter server and storage resources at site A to obtain the latest information about the virtualization environment.
- If you have performed fault recovery from site A to site B:
  1. Log in to the vCenter server at site A from vSphere Client.
  2. Shut down and unregister all VMs that are restored to site B.
  3. Remove datastores used by the migrated VMs from the EXSi hosts in the cluster where the migrated VMs reside.
  4. Detach LUNs from the removed datastores.
  5. Perform Rescan All in Storage to ensure that no datastore information is left on the ESXi hosts.
  6. Return to the eReplication system and refresh vCenter server and storage resources at site A and site B to obtain the latest information about the virtualization environment.
  7. Perform Step 2 to Step 4.
On the menu bar, select Utilization > Data Restore.
Select the remote recovery plan for which you want to execute reprotection and click More > Reprotection on the Operation list.
In the Warning dialog box that is displayed, read the content of the dialog box carefully and click OK.

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.

Result

After the reprotection starts, you can view the execution process and result. If the task is failed, you can solve the problem and execute the task again.
After the reprotection, it protects data at the original DR site once devices at the original production site recover from disasters, the original DR site is production site.