Self-defining Execution Steps in a Protected Group

Prerequisites

• At least one protected group has been created in the system.
• The protected group's status is Normal.

Context

• When the protected group is LUN, you can modify the execution step in a protected group.
• When the clone (SAN) DR technology is used, you can modify the execution step in a protected group.

Procedure

1. On the menu bar, choose Protection > LUN.
2. In the function pane, select the recovery plan to be modified and click Procedure.
3. Click Edit.

   The Edit dialog box is displayed.

4. Select script name.
   

   A self-defined script is not provided by eReplication, so the script provider must ensure the script correctness. Before configuring the script, ensure that the script has been verified by tests.

   1. If the host type is Agent, perform the following operations:
      1. Log in to the service host where the protected object resides and obtain the script template for self-defining the execution script.

         The name of a self-defined execution script must contain 4 to 32 characters, including letters, digits, underscores (_) and hyphens (-), but cannot start with a hyphen (-). The script name extension must be .bat (for Windows) or .sh (for Linux/UNIX).

         • In Windows, the script path is %OceanStor BCManager Agent install path%\bin\thirdparty\sample and the script sample name is sample.bat.
         • In Linux/UNIX, the script path is /home/rdadmin/Agent/sbin/thirdparty/sample and the script sample name is sample.sh.
      2. Place the self-defined execution script in a specified path.
         • In Windows: the path is %OceanStor BCManager Agent install path%\bin\thirdparty\
         • In Linux/UNIX: the path is /home/rdadmin/Agent/sbin/thirdparty/
      3. Set the owner and execute permission of the self-defined execution script.

         In Linux/UNIX, run the chown root xxx.sh command to set the script owner to root. Run the chmod 500 xxx.sh command to set the script execution permission to 500,

         where xxx is the name of the self-defined script.

         

         If you do not set the owner and execute permission of the self-defined script, the script may be modified by hackers, posing security risks.

   2. If the host type is Agentless, perform the following operations:
      1. Log in to the Linux service host where the protected object resides, obtain the script template, and customize the execution script based on the template.

         The name of a customized script contains 4 to 32 characters, including only letters, digits, underscores (_), and hyphens (-), and must start with a letter, digit, or underscore (_). The script name extension is .sh.

         The script template is stored in /xxxx/Agentless/custom/sample, and the script template name is sample.sh. xxxx indicates the user-defined Agentless installation directory.

      2. Place the customized execution script in the specified path to ensure that the script can be queried in the BCManager system.

         The script is stored in /xxxx/Agentless/custom, where xxxx indicates the user-defined Agentless installation directory.

      3. Set the owner and execute permission of the user-defined execution script.

         Run the chown xxx:BCManager xxxx.sh command to set the script owner to xxx:BCManager. Run the chmod 500 xxxx.sh command to set the script execution permission to 500.

         xxx indicates the user-defined Agentless installation user, and xxxx indicates the user-defined script name.

         

         If you do not set the owner and execute permission of the customized script, the uploaded script cannot be executed.

      4. Run the following command to configure sudoer of the script of invoking the permissions of other users in the customized script.

         echo "xxx1 ALL=(xxx2) NOPASSWD:xxx3" >> /etc/sudoers.d/CUSTOM

         xxx1 indicates the user-defined Agentless installation user, xxx2 indicates another user, and xxx3 indicates the absolute path of the script or command invoked by the customized script.

5. Edit steps based on site requirements.
   1. Select the steps that need to be edited.

      If the protection policy is Clone: Local Protection Solution, steps that can be edited are shown in Table 1.

      Table 1 Description about editing steps

      Step	Description
      Unmount copy	You can unmount the copy mounted previously from the test host using the script you set. If step Mount copy is enabled, step Unmount copy must be enabled. The following describes how to edit step Unmount copy. Enable the step After it is selected, this step will be enabled. NOTE: If you deselect Enable the step, remove the mapping between the snapshots of cloned source LUNs and hosts. Otherwise, the snapshots may fail to be deleted. Unmount copy test host (group) Select the test host or test host group whose copy needs to be unmounted from the drop-down list box. The test host or test host group whose copy needs to be unmounted in Unmount copy must be consistent with the test host or test host group whose copy needs to be mounted in Mount copy. Unmount copy script Enter the name of the self-defined execution script. This script can be used to unmount the copy and shutdown the database. Remove mappings After you select and execute this step, the mapping between the host and copy will be removed. If you select Remove mappings in Unmount copy, you must select Map copies to hosts in Mount copy.
      Execute pre-script	After this step is activated, you can customize a script to prepare data for data replication, for example, freezing applications and refreshing applications' cache. If you customize a script of freezing an application's I/Os, you must also customize a post-processing script for unfreezing the I/Os. The following describes how to edit step Execute pre-script. Enable the step After it is selected, this step will be enabled. Host (group) Select the host or host group to which the self-defined execution script needs to be imported. The host or host group in Execute pre-script must be consistent with that in Execute post-script. Execute pre-script Enter the name of the self-defined execution script. This script can be used to freeze applications and refresh applications' cache.
      Execute post-script	After this step is activated, you can customize a script to recover data after data replication, for example, unfreezing applications' I/Os. The following describes how to edit step Execute post-script. Enable the step After it is selected, this step will be enabled. Host (group) Select the host or host group to which the self-defined execution script needs to be imported. The host or host group in Execute post-script must be consistent with that in Execute pre-script. Execute post-script Enter the name of the self-defined execution script. This script can be used to unfreeze applications.
      Mount copy	You can unmount the copy mounted previously from the test host using the script you set. If step Unmount copy is enabled, step Mount copy must be enabled. The following describes how to edit step Mount copy. Enable the step After it is selected, this step will be enabled. Mount copy test host (group) Select the test host or test host group to which the copy needs to be mounted from the drop-down list box. The test host or test host group to which the copy needs to be mounted in Mount copy must be consistent with that whose copy needs to be unmounted in Unmount copy. NOTE: If you select a host group, ensure that all the hosts in the host group belong to the same host group on the storage array. Otherwise, step Mount copy will fail. Mount copy script Enter the name of the self-defined execution script. This script can be used to mount the copy and start the database. Map copies to hosts After it is selected, the copy will be mapped to the host when you execute this step. If you select Map copies to hosts in Mount copy, you must select Remove mappings in Unmount copy.

   2. After you finish editing a step, click Apply.

6. After you finish editing all the steps, click Close.

Exception Handling

After protected group execution steps are modified, the modification takes effect when the protected group is executed the next time. You are advised to implement execute protected group immediately after the protected group execution steps are modified to ensure correct configurations.