No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Search

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

OceanStor BCManager 6.5.0 eReplication User Guide 02

Rate and give feedback :
Huawei uses machine translation combined with human proofreading to translate this document to different languages in order to help you better understand the content of this document. Note: Even the most advanced machine translation cannot match the quality of professional translators. Huawei shall not bear any responsibility for translation accuracy and it is recommended that you refer to the English document (a link for which has been provided).
DR Recovery

DR Recovery

This section describes the DR recovery methods provided by the DR solution in active-passive mode.

Self-defining Execution Steps in a Recovery Plan

During DR, if you want to reset the DR network or stop some services at the DR site to release system resources for smooth service recovery, you can self-define the execution steps on eReplication. This operation can be performed only on eReplication of the DR site.

Prerequisites

You have logged in to the DR management server at the DR site.

Context

The management server provides the default recovery plan execution steps for different types of recovery, including testing, clearing, planned migration, fault recovery, and reprotection, to ensure correct recovery and switchover. The existing functions of eReplication cannot meet all service recovery requirements. For example, during DR, the DR network of the DR site must be reset or non-critical services must be stopped at the DR site to release the system resources to recover critical services. Therefore, eReplication allows you to modify the steps of a recovery plan.

Execution steps in a recovery plan are classified into two types, as described in Table 6-1.
Table 6-1  Recovery plan execution steps

Type

Description

Default execution steps

For default recovery plan execution steps, eReplication defines which steps can be selected and which steps can be modified and provides default configurations to meet basic recovery requirements. You can modify the default recovery plan execution steps to control whether some steps take effect in recovery plan execution based on functions to be achieved using steps and service recovery requirements.

Self-defined execution steps

If the default recovery plan execution steps cannot meet recovery service requirements, you can self-define your recovery plan execution steps by adding script steps to flexibly meet recovery requirements in a wide range of scenarios. Note that you cannot add a step before the first or after the last step of the default recovery plan execution steps. You can modify or delete steps when site conditions change.

For testing and clearing, two opposite operations, if testing execution steps are self-defined, you must determine whether opposite operations must be performed during test environment clearing to correctly recover the environment. If opposite operations must be performed, ensure that opposite operations are added to the clearing process. For example, add setting the DR routing network into the testing process, and add clearing the DR routing network into the clearing process.

Procedure

  1. On the menu bar, select Utilization > Data Recovery.
  2. Select the recovery plan whose execution steps you want to self-define and click the Procedure tab below it.
  3. Click Edit.

    The Edit dialog box is displayed.

  4. Select the phase whose steps you want to self-define, for example, test, or clear.
  5. Click Add.

    The Add Step dialog box is displayed.

  6. Based on your requirements, self-define an execution script for recovery plans.

    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.

    NOTE:

    When the protected object is a NAS file system or VMware VM, execution steps cannot be self-defined.

    1. 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).

      When the protected object is an Oracle, IBM DB2, Microsoft SQL Server database, Microsoft Exchange Server, NTFS local file system, or LUN, log in to the host where the protected object resides and obtain the script template for self-defining the execution script.

      • 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/bin/thirdparty/sample and the script sample name is sample.sh.

    2. Log in to the DR management server at the DR site or to the service host, place the self-defined execution script in a specified path.

      • When the protected object is a FusionSphere VM, the path for placing the script is as follows:
        • In Windows: the path is %OceanStor BCManager Server installation root directory%\Runtime\LegoRuntime\tools\.
        • In Linux: the path is $OceanStor BCManager Server install root path$/Runtime/LegoRuntime/tools/
      • When the protected object is an Oracle, IBM DB2, Microsoft SQL Server database, Microsoft Exchange Server, NTFS local file system, or LUN, the path for placing the script is as follows:
        • In Windows: the path is %OceanStor BCManager Agent install path%\bin\thirdparty\
        • In Linux/UNIX: the path is /home/rdadmin/Agent/bin/thirdparty/

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

      • When the protected object is a FusionSphere VM, the setting requirements are as follows:
        • In Windows, settings are not required.
        • In Linux/UNIX, run the chown ICUser:LEGO xxx.sh command to set the script owner to ICUser:LEGO. Run the chmod 500 xxx.sh command to set the script execute permission to 500,

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

      • When the protected object is an Oracle, IBM DB2, Microsoft SQL Server database, Microsoft Exchange Server, NTFS local file system, or LUN, the setting requirements are as follows:
        • In Windows, settings are not required.
        • 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 execute 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.

  7. Enter Step Name and Script Name.
  8. Select Step Execution Policy and Step Location, and click OK.

    Step Execution Policy is described as follows:

    • After failure process to be continued: The recovery plan execution continues for DR after this step fails.
    • After failure process termination: The recovery plan execution stops for DR after this step fails.

    The value of Step Location can be Before the selected step or After the selected step. You can set the step execution sequence, but you cannot add a step before the first or after the last step of the default recovery plan execution steps.

  9. In the right group box, select or deselect Start the step to enable or disable a step and click Apply.
  10. Click Close.

Follow-up Procedure

After recovery plan execution steps are modified, the modification takes effect when the recovery plan is executed the next time. When a recovery plan is executed, eReplication combines the default recovery plan execution steps, self-defined recovery plan execution steps and sequentially performs the steps in workflow mode. You are advised to implement recovery plan testing and clearing immediately after the recovery plan execution steps are modified to ensure configuration correctness.

Defining Startup Parameters for a Protected Object

If upper-layer services have special requirements on the startup sequence of databases or VMs, or on the recovery network of VMs, you can modify startup parameters based on live network conditions before performing DR. Therefore, databases or VMs can start services after DR. This operation can be performed only in the DR management system at the DR site.

Prerequisites

  • You have logged in to the DR management system at the DR site.
  • The status of the recovery plan is Ready, Planned migration failed, Fault recovery failed, Reprotection completed, Clearing completed, Rollback failed, or Rollback completed.

Procedure

  1. On the menu bar, select Utilization > Data Recovery.
  2. When the protected objects are Oracle, IBM DB2, , SAP HANA or Microsoft SQL Server databases, you can define the startup sequence of databases during DR.
    1. Select a recovery plan whose protected objects are databases and click the Protected Object tab below it.
    2. Click .

    3. If you choose to start databases during DR testing, planned migration, or fault recovery, you can set the database startup sequence.

      • When multiple databases in a protected group are mutually dependent or upper-layer services have requirements on database startup sequence, you can set the startup sequence of databases. The default startup sequence number is 10. The database with a smaller number starts earlier. A smaller sequence number indicates a higher startup priority. Databases with the same priority start randomly.
      • For databases whose Database Type is Container database (CDB), you can choose whether to start pluggable databases of container databases.

    4. In the Warning dialog box that is displayed, read the content of the dialog box carefully and select I have read and understood the consequences associated with performing this operation.
    5. Click OK.
  3. When the protected objects are VMware VMs or FusionSphere VMs, you can define the startup sequence and DR network of VMs.
    1. Select a recovery plan whose protected objects are VMs and click the Protected Object tab below it.
    2. Click Startup Settings.

      • VMware VMs or FusionSphere VMs (Non-OpenStack Architecture)

      • FusionSphere VMs (OpenStack Architecture)

    3. Choose whether to start VMs during DR testing, fault recovery, or planned migration.

      • If you select Yes, you can set the VM startup sequence. The default startup sequence number is 10. The startup sequence number for a VM ranges from 1 to 512. A smaller sequence number indicates a higher startup priority. VMs with higher priorities start earlier. VMs with the same priority start randomly. Template VMs cannot be started during recovery. By default, they cannot be started or modified.
      • If you select No, the VMs cannot be started during DR testing, fault recovery, or planned migration.

      NOTE:

      For FusionSphere VMs (OpenStack architecture), if you want to set the DR network, you need to set the Placeholder VM.

    4. If you want to modify the configurations for VM DR network, select a VM to be modified and click Test Network Settings in the operation button area of the VM. In the Test Network Settings or Configuring Test Network dialog box that is displayed, modify the configurations.

      • FusionSphere VMs (Non-OpenStack architecture)

        If you specify a recovery network when recovering a VM, the system automatically assigns this network to the VM. If you do not specify a recovery network, the VM keeps original network settings after being recovered.

        In the FusionManager scenario:





        In the FusionCompute scenario:



        NOTE:
        • Before configuring this parameter for a VM, ensure that the VM at the production site has been configured with specifications attributes, or the template for creating the VM has been configured with specifications attributes. Only a VM that meets the prior requirements supports IP address customization. For details, see sections Configuring Specifications Attribute Customization for a Linux VM and Configuring Specifications Attribute Customization for a Windows VM in the document based on the actual version of FusionSphere.
          • If the version of FusionSphere is FusionSphere V100R005C00, see FusionCompute V100R005C00 Virtual Machine Management Guide.

          • If the version of FusionSphere is FusionSphere V100R005C10, see FusionCompute V100R005C10 Virtual Machine Management Guide.

          • If the version of FusionSphere is FusionSphere V100R006C00, see FusionSphere Product Documentation (Server Virtualization,FusionCompute V100R006C00U1).

        • In the FusionCompute scenario, you can modify configurations of the VM network in a batch.
          1. Click Export IP Configuration to export the configuration template.
          2. Modify the configurations of the VM network. If Enable IPv4 Address Settings is set to N, IPv4 address settings are disabled. For details about how to modify the configuration information, see Note in the configuration template.
          3. Click Import IP Configuration to import the configuration template.


        • Currently, only IPv4 and IPv6 address settings are supported.
        • When configuring a customized IP address for a DR test or planned migration, if you need to enable the function of modifying the MAC address of a network adapter, go to the installation directory of eReplication, open the Runtime/LegoRuntime/conf/lego.properties configuration file, and add information changemac_when_modify_ip=true to the end of the file. Save the modification and exit, and restart eReplication for the modification to take effect. If you want to disable the function of modifying the MAC address of a network adapter, you can delete information changemac_when_modify_ip=true from the configuration file, and then restart eReplication for the modification to take effect.
        • Before configuring the DR network for a Linux VM, go to /etc/init.d and check whether the passwd_conf and setpasswd.sh files exist. If yes, delete the files and then select the network adapter whose recovery network you want to configure and configure an IPv4 address or elastic IP address.
        • Before configuring the DR network for a Windows VM, go to the root directory of drive C and check whether the setpass.vbs and passwd.inf files exist. If yes, delete the files and then select the network adapter whose recovery network you want to configure and configure an IPv4 address or elastic IP address.

          When configure the DR network for a Windows VM, the administrator account of the Windows operating system cannot be disabled.

      • FusionSphere VMs (OpenStack architecture)

        Before testing VMs, configure a test network for the VMs.



        • The test network can be configured only after Placeholder VMs are set in Startup Settings.
        • If you want to configure multiple test networks, Click Add Test Network to add new test networks.
      • VMware VMs

        When recovering a VM, if you have specified a recovery network, the system automatically assigns this network to the VM. If you do not specify a recovery network, the VM keeps original network settings after being recovered.

        NOTE:

        Only Windows and Linux VMware VMs can be configured with the network recovery function. For details about supported versions of the two operating systems, see the Guest OS Customization Support Matrix, which can be obtained from the VMware official website.

        • For VMs running Windows, first enter the administrator authentication information about the VM operating system, then select a network adapter whose recovery network you want to configure, and choose to manually specify or automatically obtain the IP address/DNS server addresses based on your requirements.

          If you choose the latter, the system automatically assigns the IP address/DNS server addresses of the production network to the DR network.



        • For VMs running Linux, first select a network adapter whose recovery network you want to configure, then choose to manually specify or automatically obtain the IP address/DNS server addresses based on your requirements, and finally configure the global DNS server address.

          If you choose the automatically obtain the IP address/DNS server addresses, the system automatically assigns the IP address/DNS server addresses of the DR VM.



DR Testing in the DR Center

This section describes how to test data in the DR center. DR tests are implemented by snapshot mapping in the DR center. The test is to verify that data or snapshots replicated to the DR center are available. The test process has no adverse impact on the production site. After a test is complete, the test data generated at the DR site needs to be cleared and resources need to be restored to the status before the test to facilitate future DR or planned migration.

Prerequisites

  • The production center communicates with the DR center properly.
  • At least one recovery plan has been created on eReplication.
  • For details about requirements on storage licenses for the tested recovery plan, see Checking License Files.
  • For database applications, all check items related to DR environments are passed. For details about the check items, see Oracle, IBM DB2, Microsoft SQL Server, and Microsoft Exchange Server, SAP HANA.
  • If the protected objects are FusionSphere VMs (non-OpenStack architecture):
    • If host-based replication is used for DR, the VRGs at the production and DR sites have been paired. VMs at the DR site have consistency snapshots.
    • If storage array-based replication is used for DR, remote replication secondary LUNs of the recovery plan must be mapped to VMs at the DR site.
    • If the networks of the production site and DR site are not isolated, you can configure different recovery IP addresses for test VMs and production VMs on the Protected Object tab page to avoid IP address conflicts and ensure service continuity at the production site.
    • After adding or removing disks for a protected VM, refresh the information about the VM and manually enable DR for the protected group where the VM resides in time.
  • If the protected objects are FusionSphere VMs (OpenStack architecture):

    On the Protected Object tab page of the recovery plan, Placeholder VM has been configured for the test VMs and the test network has been configured.

  • VMware VMs:
    • The name of a protect VM cannot contain pound signs (#). The VM configuration file cannot be modified during the recovery plan test if the protected VM name contains such signs.
    • If the networks of the ESXi clusters or hosts at the production site and DR site are not isolated, you can configure different recovery IP addresses for test VMs and production VMs on the Protected Object tab page of the recovery plan to avoid IP address conflicts and ensure service continuity at the production site.
  • If application data is automatically replicated by storage instead of being periodically replicated based on the schedule specified upon the protected group creation, the data replication must be stopped before you start the DR test to prevent possible test failures. You can use either of the following methods to stop storage-based replication on the device management software:
    • When the remote replication pair for the protected applications is in the synchronized state and the data is consistent, split the remote replication pair to temporarily stop data replication.
    • Change the remote replication policy to manual synchronization for the protected applications.
  • If the information about storage devices, hosts, or VMs is modified at the production or DR site, manually refresh the information. For details, see Refreshing Resource Information.

Context

The data test in the DR center is used to check its data availability.
  • You are advised to configure application-based protection policies for Oracle, SQL Server, DB2, VMware vSphere VMs, FusionSphere VMs, SAP HANA, and NAS file systems, streamlining the test procedure to a few clicks.
  • You are advised to configure LUN-based protection policies for other applications to enable automatic test configuration on the storage system. For this purpose, you need to manually or use self-defined scripts to start and test applications.

In the DR test, snapshots at the DR site can be mapped only to initiators.

For FusionSphere VM protected groups using host-based replication DR, VRGs must be used to synchronize data between the production and DR sites. If the DR status does not meet the requirements or the VRG process is faulty, snapshots may be lost.

Due to the importance of DR tests, notify the following:
  • During a DR test, system and service administrators are not allowed to perform any maintenance operation.
  • Test data must be cleared before the next DR test.
  • After a test is complete, test data must be cleared as soon as possible. If the environment is recovered after a network failure or eReplication environment shutdown during the test, it is possible that some data cannot be cleared. In this case, you must manually clear the test data, then perform clearing again.

Procedure

  1. Log in to eReplication in the DR center.
  2. Test a recovery plan.
    1. On the menu bar, select Utilization > Data Recovery.
    2. Select the recovery plan to be tested, and click Test in the Operation area.
    3. Perform the following steps based on the type of the recovery plan:

      NOTE:
      If Huawei UltraPath has been installed on the Linux-based DR host, ensure that I/O suspension time is not 0 and all virtual devices generated by UltraPath have corresponding physical devices. For details, see the OceanStor UltraPath for Linux xxx User Guide.
      • If the type of protected objects is LUN, Local File System, Oracle, IBM DB2, Microsoft SQL Server, SAP HANA, or Microsoft Exchange Server, perform the following operations:
        1. Select a DR site.
        2. Select a DR host or host group.
          NOTE:
          • If a T series V2 or later storage array is deployed at the DR site, the selected host that you want to recover can only belong to one host group on the storage array, and the host group can only belong to one mapping view. Moreover, the storage LUN used by protected applications and its corresponding remote replication secondary LUN must belong to one LUN group, and the LUN group must reside in the same mapping view as the host group. If the storage array version is 6.5.0, deselect the option for enabling hosts' in-band commands.
          • If the storage array is T series V2R2 or later, or 18000 series, automatic host adding and storage mapping are provided. Ensure that the storage is connected to hosts' initiators properly. In this manner, the system can automatically create hosts, host groups, LUN groups, and mapping views on the storage.
        3. Click Test.
        4. In the Warning dialog box that is displayed, read the content of the dialog box carefully and select In the Warning dialog box that is displayed, read the content of the dialog box carefully and select I have read and understood the consequences associated with performing this operation..
      • If the type of protected objects is VMware VM, perform the following steps:
        1. Select a test cluster.

          VMs will be recovered in the test cluster. Select Test Site, Test vCenter, and Test Cluster.

          NOTE:

          Upon the first test network selection, you need to set the test cluster information.

        2. Select a test network.

          The default test network is the network for resource mapping. If you want to change the default network, plan or select another network based on site requirements.

          NOTE:

          If Production Resource and DR Resource are not paired, select Production Resource and DR Resource, and click Add to the mapping view to pair them.

        3. Select non-critical VMs.

          In the Available VMs list, select non-critical VMs to stop them to release computing resources.

        4. Click Test.
        5. In the Warning dialog box that is displayed, read the content of the dialog box carefully and select I have read and understood the consequences associated with performing this operation.
        6. Click OK.
      • If the type of protected objects is FusionSphere VM (non-OpenStack architecture), perform the following steps:
        1. Select a cluster to be tested.

          VMs will be recovered in the test cluster. Set Test Site.

          NOTE:

          Upon the first test network selection, you need to set the test cluster information.

        2. Select a testing network.

          The default test network is the network for resource mapping. If you want to change the default network, plan or select another network based on site requirements.

        3. Select an available powered-on host.

          The available powered-on host can provide resources for VMs.

        4. Select non-critical VMs.

          In the Available VMs list, select non-critical VMs you want to stop to release computing resources.

        5. Click Test.
        6. In the Warning dialog box that is displayed, read the content of the dialog box carefully and select I have read and understood the consequences associated with performing this operation.
        7. Click OK.
      • If the type of protected objects is FusionSphere VM (OpenStack architecture), perform the following steps: In the Warning dialog box that is displayed, read the content of the dialog box carefully and select I have read and understood the consequences associated with performing this operation. Then click OK.

  3. After a test is complete, verify that applications are started in the remote DR center.

    Verify that applications are started and accessed successfully. If an application fails to be started or cannot execute read and write operations, contact Huawei technical support.

    • If the protection policies are based on applications, check whether the applications are started successfully and data can be read and written correctly.
    • If the protection policies are based on LUNs, log in to the application host in the DR center, scan for disks, and start applications. Then check whether the applications are started successfully and data can be read and written correctly.
      NOTE:
      You can use self-developed scripts to scan for disks, start applications, and test applications.

  4. The test data generated at the DR site needs to be cleared and resources need to be restored to the status before the test to facilitate future DR or planned migration.

    • If the protected group contains FusionSphere VMs and deleting a datastore fails during test data clearing, check whether non-DR VMs or disks exist on the datastore. If non-DR VMs or disks exist, migrate or delete them from the datastore.
    • If the protected groups are local file systems or NAS file systems, ensure that programs and files on the file systems at the DR site have been closed before clearing is performed.
    • If the information about storage devices, hosts, or VMs is modified at the production or DR site, manually refresh the information. For details, see Refreshing Resource Information.

    1. Select the recovery plan whose data needs to be cleared, and click More > Clear on the Operation list.
    2. Click OK.

Planned Migration of Services in the Production Center

If services in the production center are interrupted due to anticipated risks (such as outage and routine maintenance), a specific recovery plan can be executed to implement planned migration. The entire migration process is automatic without manual intervention. The DR site automatically takes over services. After the migration, services can be protected by implementing reprotection on the recovery plan, thereby implementing reverse protection for services taken over by the DR center.

Prerequisites

  • The production and DR centers communicate properly. The management system and the DR environment in the DR center are working properly.
  • Recovery plans for services to be migrated have been created on eReplication, which have succeeded in at least one test.

    If no DR test is performed before the planned migration, the migration has a higher rate to fail. A migration failure will interrupt DR services. For this reason, at least one recovery plan test must be executed successfully before the planned migration.

  • If the information about storage devices, hosts, or VMs is modified at the production or DR site, manually refresh the information. For details, see Refreshing Resource Information.

Context

  • You are advised to configure application-based protection policies for Oracle, SQL Server, DB2, VMware vSphere VMs, FusionSphere VMs, and NAS file systems, streamlining the Planned Migration to only a few clicks.
  • You are advised to configure LUN-based protection policies for other applications to enable automatic Planned Migration configuration on the storage system. You need to manually or use self-defined scripts to start and test applications.
  • The following DR solutions do not support reprotection:
    • The active-passive DR solution based on asynchronous replication (VIS)
    • The active-passive DR solution based on mirroring (VIS) and asynchronous replication (SAN)

Procedure

  1. Perform pre-migration configurations.

    • When the protected objects are databases, pre-migration configurations can be performed in the following two modes.
      • Method one: Manually stop applications and delete mapping views.
        1. Manually stop the service system and database applications and uninstall disks on the production host.
        2. Delete LUN mappings (to application hosts at the production sites) from the storage array in the production center.
          NOTE:
          • In the SQL Server cluster, the cluster must be in Maintenance mode before deleting the mapped LUNs.
          • In the asynchronous replication scenario of the HANA database, you need to log in to the database to create a snapshot for restoring the database before stopping the service system and database applications. For details, seeCreating a HANA Snapshot File.
        3. Log in to eReplication at the DR site, click Resources, select the site and the storage device, and refresh the storage device status, to ensure that all LUN mappings are removed.
      • Method two: Edit planned migration procedures. Before the planned migration, applications on hosts are automatically stopped and mapping views are automatically deleted.
        1. Log in to eReplication at the DR site, and on the menu bar select On the menu bar, select Utilization > Data Recovery.
        2. Select the recovery plan and click the Procedure tab.
        3. Click Edit.
        4. From the drop-down list, select Planned Migration.
        5. Click Stop production service and click Start the step.
        6. Click Apply.
    • When the type of protected objects is the FusionSphere VM, perform the following configurations:
      • Without configuration, the VM IP address for the planned migration is the same as that in the production center. You can configure one for the planned migration on the Protected Object tab page of the recovery plan. For details, see Defining Startup Parameters for a Protected Object.
      • After adding or removing disks for a protected VM, refresh the information about the VM and manually enable DR for the protected group where the VM resides in time.
    • When the type of protected objects is VMware VMs, perform the following configurations:
      • If any VM names contain pound signs (#), change them and avoid the use of pound signs (#). Otherwise, VM configuration files cannot be modified during the planned migration.
      • Without configuration, the VM IP address for the planned migration is the same as that in the production center. You can configure one for the planned migration on the Protected Object tab page of the recovery plan. For details, see Defining Startup Parameters for a Protected Object.
      • When the asynchronous replication (NAS) DR solution is deployed, you need to create a share and configure permissions on DeviceManager of the storage array at the DR site. Permissions must be the same as those in the production center.
        NOTE:

        If you fail to create a share and configure permissions, the planned migration will fail.

  2. Perform the planned migration to migrate services from the production center to the DR center.
    1. On the menu bar, select Utilization > Data Recovery.
    2. Select the recovery plan and click More > Planned Migration on the Operation list.
    3. Perform the planned migration based on different protected object types.

      NOTE:
      If Huawei UltraPath has been installed on the Linux-based DR host, ensure that I/O suspension time is not 0 and all virtual devices generated by UltraPath have corresponding physical devices. For details, see the OceanStor UltraPath for Linux xxx User Guide.
      • If the type of protected objects is LUN, Local File System, Oracle, IBM DB2, Microsoft SQL Server, SAP HANA, or Microsoft Exchange Server, perform the following operations:
        1. Select a DR site.
        2. Select a DR host or host group.
          NOTE:
          • If a T series V2 or later storage array is deployed at the DR site, the selected host that you want to recover can only belong to one host group on the storage array, and the host group can only belong to one mapping view. Moreover, the storage LUN used by protected applications and its corresponding remote replication secondary LUN must belong to one LUN group, and the LUN group must reside in the same mapping view as the host group. If the storage array version is 6.5.0, deselect the option for enabling hosts' in-band commands.
          • If the storage array is T series V2R2 or later, or 18000 series, automatic host adding and storage mapping are provided. Ensure that the storage is connected to hosts' initiators properly. In this manner, the system can automatically create hosts, host groups, LUN groups, and mapping views on the storage.
        3. Click Planned Migration.
        4. In the Warning dialog box that is displayed, read the content of the dialog box carefully and select I have read and understood the consequences associated with performing this operation.Click OK.
      • If the type of protected objects is VMware VM, perform the following steps:
        1. Select a recovery cluster.

          VMs will be recovered to the recovery cluster. Select DR Site, DR vCenter, and DR Cluster.

          NOTE:

          Upon the first network recovery, you need to set the cluster information.

        2. Select a recovery network.

          The recovery network is used to access recovered VMs.

          NOTE:

          If Production Resource and DR Resource are not paired, select Production Resource and DR Resource, and click Add to the mapping view to pair them.

        3. Set Logical Port IP Address to recover hosts in the cluster to access DR file systems over the logical port.
          NOTE:

          In scenarios where the asynchronous replication (NAS) DR solution is deployed, you need to set Access Settings.

        4. Stop non-critical VMs when executing recovery.

          In the Available VMs list, select non-critical VMs to stop them to release computing resources.

        5. Click Planned Migration.
        6. In the Warning dialog box that is displayed, read the content of the dialog box carefully and select I have read and understood the consequences associated with performing this operation.
        7. Click OK.
      • If the protected object type is FusionSphere VM, perform the following steps:
        1. Select the cluster you want to recover.

          VMs will be recovered to the cluster. Select DR Site.

        2. Select an available powered-on host.

          The host will provide resources for VMs.

        3. Select non-critical VMs.

          In the Available VMs list, select non-critical VMs you want to stop to release computing resources.

        4. Click Planned Migration.
        5. In the Warning dialog box that is displayed, read the content of the dialog box carefully and select I have read and understood the consequences associated with performing this operation.
        6. Click OK.
        NOTE:

        During the planned migration in host-based replication DR mode, if the migration task remains in the Stop the VM step for a long time, a possible cause is that the internal program of the operating system cannot be closed. You can log in to FusionCompute and then log in to the VM using Virtual Network Computing (VNC) as an administrator, identify the failure cause, and safely stop the VM. If the failure persists, forcibly stop the VM on FusionCompute. (Forcible VM stop may result in a planned migration failure.) After forcibly stopping the VM, go to the Recovery page, select the protected group of the VM, click Start on the Protected Object page, and select Consistency verification to synchronize data. After data synchronization, execute the planned migration again.

      • If the protected object is a NAS File System, perform the following operations: In the Warning dialog box that is displayed, read the content of the dialog box carefully and select I have read and understood the consequences associated with performing this operation. Then click OK.

  3. After the migration is complete, verify that applications are started and data is consistent in the DR center.

    After the planned migration is complete, check whether the applications and data are normal. If an application or data encounters an exception, contact Huawei technical support.

    • Note the following when checking the startup status of applications.
      • If the protection policies are based on applications, check whether the applications are started successfully and data can be read and written correctly.
      • If the protection policies are based on LUNs, log in to the application host in the DR center, scan for disks, and start applications. Then check whether the applications are started successfully and data can be read and written correctly.
        NOTE:
        You can use self-developed scripts to scan for disks, start applications, and test applications.
    • You can check data consistency by viewing the last entry of data written to the production and DR centers. If the last entry of data written to the production and DR centers is the same, the data consistency is ensured.

  4. Delete data after migration.

    If storage array-based remote replication DR is used, snapshots are created automatically on the storage array at the DR site to back up DR data during the planned migration. If snapshots are not automatically deleted after the planned migration is complete, manually delete them to release storage space.

    NOTE:
    • A snapshot name is a string of 31 characters named in the following format: DRdata_LUNID_YYYYMMDDHHMMSS_BAK, where YYYYMMDDHHMMSS is the backup time and LUNID may be the snapshot ID (a number ranging from 1 to 65535). This naming format enables you to quickly find the snapshots that you want to delete from the storage array at the DR site.
    • When the protection type is SAP HANA, you do not need to clear the data after the planned migration is complete.

  5. Check the environment before starting reprotection.

    • Databases:

      Ensure that underlying storage links, remote replication pairs, and consistency groups have been recovered.

    • FusionSphere VMs:
      • FusionCompute, FusionManager, storage devices, and VRGs at the production site are in the normal state, and the production site and DR site communicate with each other correctly.
      • In scenarios that uses storage array-based replication, ensure that storage configurations between the original production and DR sites are correct.
        • Ensure that all underlying storage units corresponding to protected groups have remote replication pairs.
        • Ensure that all remote replication pairs have secondary LUNs that belong to storage devices at the original production site.
        • If there are multiple remote replication pairs, they must belong to the same consistency group.
      • After adding or removing disks for a protected VM, refresh the information about the VM and manually enable DR for the protected group where the VM resides in time.
    • VMware VMs:
      • Ensure that all VM names contain no number sign (#). Otherwise, the VM configuration file cannot be modified during the testing of the recovery plan.
      • Ensure that underlying storage links, remote replication pairs, and consistency groups have been recovered.
      • On the original production array, unmap the volumes corresponding to the applications to be restored.

  6. Perform reprotection to protect services switched to the DR center.

    After the planned migration is complete, the application system is working in the DR center and protected groups become Invalid. You must perform reprotection to recover the replication status and synchronize the data from the DR center to the production center. Then, the original DR center becomes the new production center.

    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, re-configuration of protection and recovery policies is recommended to ensure the continuity of DR services.

    1. On the menu bar, select Utilization > Data Recovery.
    2. Select the recovery plan and click More > Reprotection on the Operation list.

      If the protected objects are VMware VMs and services are recovered through a planned migration, perform the following steps to clear redundant and incorrect data in the virtualization environment before and after the reprotection.

      1. If reprotection was performed, use vSphere Client to log in to vCenter at site B. Click Storage list, and click Rescan All of storage devices one by one, to ensure that no datastore exists on ESXi hosts. Otherwise, skip this step.
      2. On eReplication, perform reprotection.
      3. Log in to the in the vCenter server at site A using vSphere Client. In the Storage list, right-click storage devices and select Rescan All from the drop-down list one by one, to ensure that no residuals exist on ESXi hosts in the cluster where the migrated VMs reside.
      4. Return to eReplication, and update vCenter servers and storage resources of site A to obtain the latest VM environment information.

    3. Carefully read the content of the Confirm dialog box that is displayed and click OK to confirm the information.

      NOTE:

      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 is complete, the protected groups become normal.

Planned Switchback of Services in the DR Center

After services are switched from the production center to the DR center through planned migration, the services must be switched back to the production center based on a drill plan.

Prerequisites

  • Planned migration and reprotection have been successfully performed for the service system in the production center according to the recovery plan.
  • The production host is working properly and the service system in the original production center is in standby state.

Procedure

  1. Test the recovery plan and clear the test data on eReplication.

    Before the services are switched back, you need to perform a DR test to verify the data availability to ensure that services can be switched back successfully. After the test, you must clear the test data to avoid switchback failure caused by test data. For details, see DR Testing in the DR Center.

  2. Perform pre-migration configurations.

    • When the protected objects are databases, pre-migration configurations can be performed in the following two modes.
      • Method one: Manually stop applications and delete mapping views.
        1. Manually stop the service system and database applications and uninstall disks on the production host.
        2. Delete LUN mappings (to application hosts at the production sites) from the storage array in the production center.
          NOTE:
          • In the SQL Server cluster, the cluster must be in Maintenance mode before deleting the mapped LUNs.
          • In the asynchronous replication scenario of the HANA database, you need to log in to the database to create a snapshot for restoring the database before stopping the service system and database applications. For details, seeCreating a HANA Snapshot File.
        3. Log in to eReplication at the DR site, click Resources, select the site and the storage device, and refresh the storage device status, to ensure that all LUN mappings are removed.
      • Method two: Edit planned migration procedures. Before the planned migration, applications on hosts are automatically stopped and mapping views are automatically deleted.
        1. Log in to eReplication at the DR site, and on the menu bar select On the menu bar, select Utilization > Data Recovery.
        2. Select the recovery plan and click the Procedure tab.
        3. Click Edit.
        4. From the drop-down list, select Planned Migration.
        5. Click Stop production service and click Start the step.
        6. Click Apply.
    • When the type of protected objects is VMware VMs, perform the following configurations:
      • If any VM names contain pound signs (#), change them and avoid the use of pound signs (#). Otherwise, VM configuration files cannot be modified during the planned migration.
      • Without configuration, the VM IP address for the planned migration is the same as that in the production center. You can configure one for the planned migration on the Protected Object tab page of the recovery plan. For details, see Defining Startup Parameters for a Protected Object.
      • When the asynchronous replication (NAS) DR solution is deployed, you need to create a share and configure permissions on DeviceManager of the storage array at the DR site. Permissions must be the same as those in the production center.
        NOTE:

        If you fail to create a share and configure permissions, the planned migration will fail.

    • When the type of protected objects is the FusionSphere VM, perform the following configurations:
      • Without configuration, the VM IP address for the planned migration is the same as that in the production center. You can configure one for the planned migration on the Protected Object tab page of the recovery plan. For details, see Defining Startup Parameters for a Protected Object.
      • After adding or removing disks for a protected VM, refresh the information about the VM and manually enable DR for the protected group where the VM resides in time.

  3. On eReplication of the DR center, perform a planned migration.

    This step aims to switch services back to the production center from the DR center. After the migration, check the data and clear the test data. For details, see 2 to 4 in Planned Migration of Services in the Production Center.

    NOTE:
    • If the protected object type is LUN, Local File System, Oracle, IBM DB2, Microsoft SQL Server, SAP HANA, or Microsoft Exchange Server, select hosts or host groups in the production center as the recovery target.
    • If the protected object type is VMware VM, select vCenter and clusters in the production center as the recovery target.
    • If the protected object type is FusionSphere VM, select site in the production center as the recovery target.

  4. On eReplication of the DR center, perform reprotection.

    After you complete the planned migration, the application systems are working in the original production center and protected groups become Invalid. To ensure that the production center can be recovered from the DR center in case an event (planned or unplanned) happens on it after the switchback, perform reprotection and recover the replication relationship between the production center and the DR center to synchronize data and ensure that services are protected. For details, see 5 to 6 in Planned Migration of Services in the Production Center.

Result

Once the reprotection is complete, the protected groups become normal.

Service Migration in the Production Center After Fault Recovery

If data or applications in the production center become unavailable due to disasters or faults, you must quickly recover the data or applications from the DR center. Before a fault recovery, at least one recovery plan test must be executed successfully. This operation can be performed only on eReplication in the DR center.

Prerequisites

  • Application-based protection policies and recovery plans have been configured for database applications or VMware vSphere and FusionSphere 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.
  • If the type of protected objects is SAP HANA, perform Test and Clear first. For details about the operations, see DR Testing in the DR Center.

Context

If data or applications become unavailable due to disasters or faults in the production center, services will be quickly switched to and started in the DR center. After the production center recovers, the services will be switched back to it by performing planned migration.

For FusionSphere VMs (OpenStack architecture), delete the recovery plan after a fault recovery. After the primary OpenStack is installed and the relevant protected group is deleted, contact Huawei technical support engineers to clear the remote replication relationships on the array.

Procedure

  1. Perform pre-recovery configurations.

    • When the type of protected objects is FusionSphere VMs, perform the following configurations:
      • Without configuration, the VM IP address for fault recovery is the same as that in the production center. You can change it for the planned VM migration on the Protected Object tab page of the recovery policy. For details, see Defining Startup Parameters for a Protected Object.
      • After adding or removing disks for a protected VM, refresh the information about the VM and manually enable DR for the protected group where the VM resides in time.
    • When the type of protected objects is VMware VMs, perform the following configurations:
      • If any VM names contain number signs (#), change them and avoid the use of number signs (#). Otherwise, VM configuration files cannot be modified during the fault recovery.
      • Without configuration, the VM IP address for fault recovery is the same as that in the production center. You can configure one for fault recovery on the Protected Object tab page of the recovery plan. For details, see Defining Startup Parameters for a Protected Object.
      • When the asynchronous replication (NAS) DR solution is deployed, you need to create a share and configure permissions on DeviceManager of the storage array at the DR site. Permissions must be the same as those in the production center.
        NOTE:

        If you fail to create a share and configure permissions, faults cannot be rectified.

  2. Perform a fault recovery.

    NOTE:
    If Huawei UltraPath has been installed on the Linux-based DR host, ensure that I/O suspension time is not 0 and all virtual devices generated by UltraPath have corresponding physical devices. For details, see the OceanStor UltraPath for Linux xxx User Guide.

    1. On the menu bar, select Utilization > Data Recovery.
    2. Select the recovery plan to be recovered and click More > Fault Recovery on the Operation list.
    3. Perform fault recovery based on protected object types.

      • If the type of protected objects is LUN, Local File System, Oracle, IBM DB2, Microsoft SQL Server, SAP HANA, or Microsoft Exchange Server, perform the following operations:
        1. Select a DR site.
        2. Select a DR host or host group.
          NOTE:
          • If a T series V2 or later storage array is deployed at the DR site, the selected host that you want to recover can only belong to one host group on the storage array, and the host group can only belong to one mapping view. Moreover, the storage LUN used by protected applications and its corresponding remote replication secondary LUN must belong to one LUN group, and the LUN group must reside in the same mapping view as the host group. If the storage array version is 6.5.0, deselect the option for enabling hosts' in-band commands.
          • If the storage array is T series V2R2 or later, or 18000 series, automatic host adding and storage mapping are provided. Ensure that the storage is connected to hosts' initiators properly. In this manner, the system can automatically create hosts, host groups, LUN groups, and mapping views on the storage.
        3. Click Fault Recovery.
        4. In the Warning dialog box that is displayed, read the content of the dialog box carefully and select I have read and understood the consequences associated with performing this operation.Click OK.
      • If the type of protected objects is VMware VM, perform the following steps:
        1. Select a recovery cluster.

          VMs will be recovered to the cluster. Select DR Site, DR vCenter, and DR Cluster.

          NOTE:

          Upon the first network recovery, you need to set the cluster information.

        2. Select a recovery network.

          The network is used to access recovered VMs.

          NOTE:

          If Production Resource and DR Resource are not paired, select Production Resource and DR Resource, and click Add to the mapping view to pair them.

        3. Set Logical Port IP Address to recover hosts in the cluster to access DR file systems over the logical port.
          NOTE:

          In scenarios where the asynchronous replication (NAS) DR solution is deployed, you need to set Access Settings.

        4. Stop non-critical VMs when executing recovery.

          In the Available VMs list, select non-critical VMs to stop them to release computing resources.

        5. Click Fault Recovery.
      • If the type of protected objects is FusionSphere VM or NAS File System, perform the following operations: In the Warning dialog box that is displayed, read the content of the dialog box carefully and select I have read and understood the consequences associated with performing this operation. Then click OK.
        For protected groups of FusionSphere VMs that use host-based replication for DR, you can recover data using the latest data or snapshots.
        • Latest data: The system uses service backup data backed up to the DR center before the disaster for recovery and starts services in the DR center.
        • Latest snapshots: Before a manual or automatic protected group execution, the system automatically creates a snapshot for placeholder VMs of the DR site. If you choose this mode for fault recovery, the system will use the latest snapshot of the placeholder VMs to register and start VMs.

  3. In the production center, check the application startup status.

    After the fault recovery is complete, check whether the applications and data are normal. If an application or data encounters an exception, contact Huawei technical support.

    • Note the following when checking the startup status of applications.
      • If the protection policies are based on applications, check whether the applications are started successfully and data can be read and written correctly.
      • If the protection policies are based on LUNs, you need to log in to the application host in the disaster recovery center, scan for disks, and start applications. Then check whether the applications are started successfully and data can be read and written correctly.
        NOTE:
        You can use self-developed scripts to scan for disks, start applications, and test applications.

  4. Check the environment before starting reprotection.

    NOTE:
    For FusionStorage, you need to repair the production end. After it is repaired, manually unmap the LUNs on the production end.
    • Databases:

      Before reprotection, underlying storage links, remote replications, and consistency groups have been recovered.

    • FusionSphere VMs:
      • FusionCompute, FusionManager, storage devices, and VRGs at the production site are in the normal state, and the production site and DR site communicate with each other correctly.
      • In scenarios where storage array-based replication is used, ensure the following:
        • Primary LUNs of original remote replication pairs are removed from the production site.
        • Remote replication pairs are deleted from the production storage.
        • If protected groups of the recovery plan are created in consistency groups, consistency groups at the DR site are deleted and re-created. Besides, remote replication pairs at the DR site are added to the newly created consistency groups and data is synchronized.
        • LUNs that have not been used by other remote replication pairs are added to remote replication pairs on the storage at the original DR site. Newly created LUNs and LUNs removed from other remote replication pairs are mapped to hosts. If the primary LUN of the original remote replication pair has been mapped to hosts, VMs and datastores must be deleted from the primary LUN.
      • After adding or removing disks for a protected VM, refresh the information about the VM and manually enable DR for the protected group where the VM resides in time.
    • VMware VMs:
      • Ensure that all VM names contain no number sign (#). Otherwise, the VM configuration file cannot be modified during the execution of reprotection.
      • Ensure that underlying storage links, remote replication pairs, and consistency groups have been recovered.

  5. Perform reprotection to protect services switched to the DR center.

    After the planned migration is complete, the application system is working in the DR center and protected groups become Invalid. You must perform reprotection to recover the replication status and synchronize the data from the DR center to the production center. Then, the original DR center becomes the new production center.

    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, re-configuration of protection and recovery policies is recommended to ensure the continuity of DR services.

    1. On the menu bar, select Utilization > Data Recovery.
    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 virtualization 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. In the Storage list, right-click storage devices and select Rescan All from the drop-down list one by one to ensure 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.

    3. Carefully read the content of the Confirm dialog box that is displayed and click OK to confirm the information.

      NOTE:

      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.

Service Switchback in the DR Center After Fault Recovery

Services are migrated from the production center to the DR center due to a recoverable fault such as an unexpected power failure. After the production center recovers from the fault, you must synchronize data generated during the fault recovery period from the DR center to the production center and switch services back to the production center.

Prerequisites

  • Application-based protection policies and recovery plans have been configured for database applications or VMware vSphere and FusionSphere 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.
  • The fault recovery of the recovery plan is successfully executed in the original DR center.

Procedure

  1. Log in to the service system in the original production center and check the service startup status.

    Ensure that the applications in the production center have been stopped before uninstalling disks.

    NOTE:
    • In scenarios where VMware VMs are deployed, you must connect vSphere Client to VMware vCenter in the production center to power off the protected VMs and remove them from the list.
    • In scenarios where databases are deployed, you must manually close the applications in the production center.

  2. Uninstall disks on application hosts.

    In a VMware VM environment, you only need to uninstall datastores.

    NOTE:
    The purposes of uninstalling disks are to prevent application hosts from writing data into the disks in the service recovery process and to enable eReplication to report an error when disks are automatically mounted in the DR process.

  3. Perform reprotection.

    Data needs to be copied from the DR center to the production center to complete the initial data synchronization.

    1. On the menu bar, select Utilization > Data Recovery.
    2. Select the recovery plan and click More > Reprotection on the Operation list.
    3. Carefully read the content of the Confirm dialog box that is displayed and click OK to confirm the information.

      NOTE:

      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.

  4. Test the recovery plan and clear the test data on eReplication. During the test, select a host or host group in the production center if necessary.

    Before the services are switched back, you need to perform a DR test to verify the data availability to ensure that services can be successfully switched back. After the test, you must clear the test data to avoid switchback failure caused by test data. For details, see DR Testing in the DR Center.

  5. On eReplication, perform a planned migration.

    This step aims to switch services back to the production center from the DR center. After migration, data must be checked and test data must be cleared. For details, see 2 to 4 in Planned Migration of Services in the Production Center.

    NOTE:
    Before miagrating the protected groups in the SAP HANA cluster back, perform the following operations:
    1. Use PuTTY to log in to the server at the DR end as user root.
    2. Run the TMOUT=0 command to prevent PuTTY from exiting due to session timeout.
    3. Run the su - sidadm command to switch to user dbladm.

      sid indicates the SAP HANA System ID set when the user creates the database. The letter in the value is lowercase. In the following example, the value of sid is DB1.

      The following command output is displayed:
      suse11-hana:/ # su - db1adm
      suse11-hana:/usr/sap/DB1/HDB01>
      
    4. Run the hdbsql -i xx -n localhost:3xx15 -u system -p PW -d SID command to log in to the database.

      In the preceding command, xx indicates the instance ID, and yyy indicates the instance name. Change them based on the site requirements.

      The following command output is displayed:
      suse11-hana:/usr/sap/DB1/HDB01> hdbsql -i 01 -n localhost:30115 -u 
      system -p Huawei@123 -d DB1
      Welcome to the SAP HANA Database interactive terminal.
      Type: \h for help with commands
      \q to quit
      hdbsql DB1=>
      
    5. Run the alter system start database SID command to activate the database.

  6. On eReplication, perform reprotection again.

    Copy data from the production center to the DR center to recover the protected group status.

Test Report Management of Recovery Plans

This section describes how to view the test reports of recovery plans to know the test details.

Procedure

  1. Perform either of the following operations to go to the Recovery Plan Test Report page.

    • On the menu bar, choose Monitor > Report > Recovery Plan Test Report.
    • On the home page, click More in the lower right corner of the Recovery Plan Test Duration (Latest 3 Months) or Recovery Plan Test Status (Latest 3 Months) area.

  2. Select the recovery plan whose details you want to view. Table 6-2 lists the report parameters.

    Table 6-2  Parameters of a recovery plan test report

    Parameter

    Description

    Name

    Indicates the name of the recovery plan.

    Production Site

    Indicates the site where the protected objects in the group reside (the protected site). Service systems of enterprises are running on the site.

    DR Site

    Indicates the site running the DR system. This site provides DR backup services for the protected objects. If a disaster occurs, it can be used to recover services.

    Protected Object Type

    Indicates the types of protected objects in a protected group of the recovery plan. eReplication enables you to create protected groups based on the following applications:
    • Oracle
    • IBM DB2
    • Microsoft SQL Server
    • Microsoft Exchange Server
    • Local File system
    • NAS File System
    • VMware VM
    • LUN
    • FusionSphere VM
    • SAP HANA

    Avg. Test Time

    Indicates the average time required by tests of the recovery plan. If two tests have been conducted on the recovery plan, the value is the average value of the time required by the tests.

    If reprotection has been performed on the recovery plan, time values collected after the latest reprotection must be used.

    Max. Test Time

    Indicates the maximum time required by a test of the recovery plan. If two tests have been conducted on the recovery plan, the value is the maximum value of the time required by the tests.

    If reprotection has been performed on the recovery plan, time values collected after the latest reprotection must be used.

    Min. Test Time

    Indicates the minimum time required by a test of the recovery plan. If two tests have been conducted on the recovery plan, the value is the minimum value of the time required by the tests.

    If reprotection has been performed on the recovery plan, time values collected after the latest reprotection must be used.

    Execution Result

    Indicates the execution result of a recovery plan test.

  3. Optional: Click Export All to export the test reports and save them to a local computer.
Translation
Download
Updated: 2019-05-21

Document ID: EDOC1100075861

Views: 10409

Downloads: 55

Average rating:
This Document Applies to these Products
Related Documents
Related Version
Share
Previous Next