Executing a Protected Group

Prerequisites

• Only protected groups in the Normal state can be executed.
• If storage devices, hosts or VMs on production site or DR site change, storage devices, hosts or VMs at the site where a protected group resides must be refreshed, for details, refer to Refreshing Resource Information.
• Information about storage devices and hosts must be refreshed the DR sites where the protected group resides to ensure that information about the protected group is refreshed successfully.
• If add or delete the disk in the protected VM, refresh the VM and execute this protected group of protected VMs reside manually.
• The state of the remote replications must be Normal in the array, the state cannot be Synchronizing

Context

If execute protected groups in a Windows host, only execute a protected group in the same time.

If daylight saving time (DST) is enabled on the eReplication management server, a DR protection task whose trigger time point falls within the DST shift period cannot be executed at the scheduled time. Details are as follows: UTC-08:00) Pacific Time (United States and Canada) is used as an example. The DST starts at 2016-03-12 02:00:00, and ends at 2016-11-06 02:00:00.

• If the start time of the protection policy falls within the first hour (2016-03-12 02:00:00 to 03:00:00) after the DST starts, for example, 2016-03-12 02:30:00, the protection group will be automatically executed with a delay of one hour, that is 2016-03-12 03:30:00.
• If the start time of the protection policy falls with the last hour (2016-11-06 01:00:00 to 02:00:00) before the DST ends, for example, 2016-11-06 01:30:00, the protection group will be executed after the DST ends for half an hour.

• Protected groups must be executed in off-peak hours. Execution when I/O activities are busy may fail.
• In case of continuous application frozen when a fault occurs during the execution of a protected group, the host agent automatically starts to time the frozen period of applications in the protected group. If the host agent does not receive an unfreezing command within set time, it automatically unfreeze the applications. If the host agent receives an unfreezing command after set time, it returns an error message indicating unfreezing failure.
  

  If applications are automatically unfrozen, the consistency of replication data cannot be ensured, you need to execute the protected group to ensure data consistency.

• Protected groups in the Executing, Disabled, Locked, or Invalid state cannot be executed.
• If timetables are specified in the protection policies of a protected group, the protected group will be automatically executed based on the timetable. Perform the following steps to manually execute a protected group.
• If the time policy of the protected group is set to Period-based scheduling, during the execution of the protected group, the timeout period of step Monitor data replication status is the same as the time period in the time policy. If the time policy of the protected group is set to On-demand scheduling, during the execution of the protected group, the default timeout period of step Monitor data replication status is two hours.

Procedure

1. On the menu bar, choose Protection.
2. Select the protected group for which you want to execute and click Execute on the Operation list.

   If the protection policy is HyperMetro and Array-Based Replication (Synchronous), the protected group cannot be executed.

3. In the Question dialog box that is displayed, read the content of the dialog box carefully. Then click OK.

   The protection policies of the protected group are executed immediately. On the Execution Records tab page, you can view the execution result and details.

   

   If the protected group is in the Executing state for a long period, click in the upper right corner to refresh information.

Result

After the protected group is executed, a historical record is generated on the Execution Records tab page. eReplication clears the execution records of each protected group at 00:00 every day. Only the latest 1000 records are retained. If the number of historical records exceeds 1000, the system deletes the earliest records.