Dell RecoverPoint for Virtual Machines 6.0.3.1 Installation and Deployment Guide

PDF

Upgrade from RecoverPoint for VMs  5.3.SP4 P1 to 6.0.SP3 and later

Perform the following procedure to upgrade your RecoverPoint for VMs from 5.3.SP4 P1 to 6.0.SP3 and later.

Prerequisites

Ensure that the vCenter version and ESXi version you are using is vSphere 7.0U3 to 8.0U2.

Ensure that your RPAs are running on RecoverPoint for VMs 5.3.SP4 P1.

Ensure that your current system matches the scale limits of RecoverPoint for VMs 6.0.SP3 and later defined in RecoverPoint for Virtual Machines Scale and Performance Guide.

If the vCenter Server SSL certificate is changed, ensure that the new certificate is valid, and that the RecoverPoint for VMs is updated.

Ensure that the VIB URLs are trusted. See the VMware KB93130 for more information.

You can enable secure boot after upgrading to 6.0.SP3 and later.

Ensure that there are no IDE disks available in the Virtual Machine that needs protection in your vSphere environment. RecoverPoint for VMs 6.0.SP1 and later does not support VM protection for IDE disk.

About this task

  1. Backup:
    • Runs the pre‑check automatically and creates a pre‑check report.
    • Review the report manually and acknowledge.
    • Unprotect all CGs.
  2. Upgrade or Migrate (5.3.4.1 → 6.0.3 and later) :
    • Follow the standard migration steps for migrating from the existing 5.3.4.1 version to 6.0.SP3 and later.
  3. Restore
    • Deploy a binary patch to every RPA so that each CG restored thereafter begins in a paused state.
    • Restore the compatible CGs from the backup automatically.
    • Examine the restore‑status report to spot any CGs that were skipped and may need manual handling.
  4. Resume
    • Resume the CGs in batches (either using the script — random selection — or manually through the UI (based on user preference or priority)).
    • Limit each batch to ≤ 10 CGs to avoid high load problems in RPA.
  5. Post‑Restore Configuration
    • After all CGs show Active status, apply any additional CG settings that were backed up.
    • Revert the binary patch that was previously applied to all RPAs.
Upgrade RP4VM

Here are some key considerations and recommendations before proceeding:

  • Do not run the script in parallel or on the same machine or on different machines. Running multiple instances can corrupt backup data or the CG configuration in the RP system.
  • Always run only one instance at a time. If you restart or re-run the script, first terminate any existing script processes (close the script window or kill the process using Task Manager).
  • Run the script from a Windows host on the same network as RPC or use a Windows VM as a host which is deployed in the VC.
  • When re‑running a backup, remove the previous backup folder or specify a new folder. Corruption of backup files or reports may occur.
  • In a connected-cluster environment, use a single RPC IP for the backup and resume phases, and up to two RPC IP for the restore phase.
  • After taking a backup in a connected‑cluster setup, upgrade all clusters before initiating the restore. The backup‑restore sequence should be performed only once.
  • Pre‑check before backup
    • The script runs a system pre‑check and creates a precheck report that lists any limitations of RecoverPoint for Virtual Machines 6.0.SP3 and later depending upon the version which the user upgrades.
    • Review this report carefully; any parameter that exceeds the limits is skipped during restore and may require manual intervention.
    • The script cannot automatically verify every limitation. Refer to the Dell RecoverPoint for Virtual Machines Scale and Performance Guide, Dell RecoverPoint for Virtual Machines Release Notes to review the full list of limitations.
    • Resolve any non‑compliant items (or make the environment RecoverPoint for Virtual Machines 6.0.3 and later compatible) before proceeding with the CG backup and restore.
  • After the restore is complete, a detailed status report is generated. Review the status report after restore to identify any skipped CGs that need manual intervention.
  • The script cannot restore VM priority or critical flags of consistency groups in the VM startup sequence. Note these settings before taking a backup and manually reassign the respective flags to each VM after the restore is complete.
  • Resume CGs
    • CGs should be resumed in batches (recommended batch size <= 10CGs).
    • By default, the script uses a batch size of 10 and selects CGs randomly.
    • To manually resume CGs in the UI, keep the batch size under 10 to avoid excessive load on the RPAs.
  • Post‑restore configuration – Run the final script to apply any additional CG settings only after all CGs displays Active status.
  • In large‑scale environments, the whole process or only resuming CG process can take weeks or months, depending on factors such as VM size and protected CGs. Plan the process carefully by monitoring progress accordingly.
  • The script does not work if datastores (where the protected VM resides) have space on their name.
  • Protection or Unprotection does not work if a virtual machine has snapshots.

Steps

  1. Download migration_utility.zip file from support site and extract to backup_restore directory on any Windows operating system. Change the directory to backup_restore and open Window command prompt or PowerShell prompt from that folder.
    NOTE:Extracted folder contains cg_backup_restore_1.7.exe and libmanagement_libs-release.deb file.
  2. Take backup of CGs.
    1. Run the .exe in backup mode by entering the following command:
      cg_backup_restore_1.7 Script1 -a backup -i <RPC_IP> -u <USERERNAME> -p <PASSWORD> -o <BACKUP FOLDER NAME>
      Here <USERERNAME> and <PASSWORD> are VC username and password. <RPC_IP> is plugin server IP. For PowerShell, use ./cg_backup_restore_1.7.
    2. Detailed precheck_report.txt is generated inside the backup folder for manual review.
  3. If vCenter and ESXi are in 7.0U3, then first upgrade both to 8.0 U1 and later.
  4. Unprotect all CGs.
    1. Run the .exe in unprotect mode by entering the following command:
      cg_backup_restore_1.7 Script1 -a unprotectall -i <RPC_IP> -u <USERERNAME> -p <PASSWORD> -o <BACKUP FOLDER NAME>
      1. Unprotection might fail for a few CGs with the error that is shown in the image here.

        Unprotect CG error message

        Verify if CG is still available in the plugin server UI. If CG is available, retry the unprotect command else ignore this error.

  5. Upgrade from 5.3.4.1 to 6.0.3 and later.
    1. Download the upgrade package. See the section The Upgrade and Maintenance package.
    2. Upgrade vRPA clusters to 6.0.SP3 and later. See section Upgrade a vRPA cluster.
      If there are multiple RP clusters that are installed in a VC, upgrade all RP Clusters. 
      When vRPA clusters are upgraded, older versions of RecoverPoint for VMs are shown under the vSphere summary section of vRPA virtual machine vSphere Notes. You can verify the upgraded RPA version from Plugin server UI or RecoverPoint CLI. If you want to see upgraded version in vSphere Notes, click edit button of vSphere Notes and update the new RecoverPoint for VMs version.
    3. Uninstall the 5.3.SP4 P1 Plugin and Install the 6.0.SP3 and later plugin as follows:
      1. In the RecoverPoint for VMs plugin for vSphere Client, select System > vCenter Servers > Administration > vCenter Server.
      2. Delete all vCenter Servers from the plugin server.
      3. Power off and remove the plugin server VM. See the section Uninstall the plugin server .
    4. Deploy a new 6.0.SP3 and later plugin server. See the section Deploy the plugin server.
    5. Configure the deployed plugin server. See the section Configure the plugin server.
    6. Remove the 5.3.SP4 P1 Splitter from the hosts.
      1. On the ESXi host, vMotion all VMs to another ESXi host.
      2. At ESXiCLI, enter maintenance mode. From the ESXi host console, use SSH to run the command ESXicli system maintenanceMode set -e=true

        For vSAN environments, this command requires an additional switch (see the vSphere documentation for the vSphere version that you are using).

      3. To uninstall the splitter, enter the command ESXicli software vib remove -n RP-Splitter.
      4. Exit maintenance mode on the ESXi host by entering the command ESXicli system maintenanceMode set -e=false
    7. Upgrade splitter and Jiraf for ESXi cluster. See the section Upgrade Splitter and Jiraf for Entire ESXi Cluster. This installs the 6.0.SP3 and later splitter and upgrades the Jiraf.
      After removing the vSCSI Splitter from ESXi manually, the auto push mechanism may push the new RecoverPoint for VMs6.0.3.1 and later Splitter to ESXi Cluster which is registered with RP.
      After upgrade is complete, the following message is displayed.

      Upgrading ESXi splitter and JAM VIBs completed successfully

      .
    8. When the vRPAs, splitter, and Jiraf are migrated, check the ESXi cluster status. In the plugin, go to System > ESXi Cluster section.
      Ensure that the ESXi cluster status is green. If the status is not green:
      1. Unregister the ESXi cluster. See the section Remove ESXi clusters from vRPA clusters.
      2. Reregister the removed ESXi cluster. See the section Register ESXi clusters.
  6. Validate upgrade or migration.
    NOTE:After migration, ensure that all vRPA clusters, ESXi clusters are in green status. Failing to check this before proceeding may result in problems when restoring. Refer to Troubleshoot the Migration Issues section in this topic.
  7. Apply Binary patch fix on all RPAs.
    1. Copy the libmanagement_libs-release.deb downloaded in Step1 to all the /root folder of RPA.
    2. To perform backup of the original binary to /root, run the following command.
      cp /usr/lib/recoverpoint/libmanagement_libs-release.so /root/libmanagement_libs-release.so
    3. To install the debug libs, run the following command in /root:
      dpkg -i libmanagement_libs-release.deb
    4. To kill the control process after lib replacement, do the following:
      1. Run the command pkill -9 control_proces
      2. Wait until the dashboard returns to green status.
  8. Restore all CGs.
    1. To run the .exe in restore mode, enter the following command:
      cg_backup_restore_1.7 Script1 -a restore -i <RPC_IP> -u <USERERNAME> -p <PASSWORD> -o <BACKUP FOLDER NAME> -e
      1. Give the same backup folder name as Step 2.
      2. -e is required only when restoring Consistency Groups (CGs) using existing copy VMs. If you choose to create copy of VMs, this parameter is not needed in the command. However, the script may use the available datastores to create the replica copies.
      3. Restored CGs are start in a pause state.
      4. For restore action, you can provide upto two RPC IP to manage restore load on the environment. For example : -i 10.xx.xx.xx 10.xx.xx.xx (space separated).
      5. In the restore summary shown here, if there are any pending CGs then do the following: Restore summary
        1. Open the cg_status.txt file generated inside the backup folder and check which Consistency Group (CG) entries have the status column marked as PENDING.
        2. If the above CG is visible in the plugin server Consistency Groups list, it can be ignored. However, if it is not listed, retry the restore command.
  9. Resume CGs in batches.
    1. To run the .exe in resume mode, enter the following command:
      cg_backup_restore_1.7 Script2 -i <RPC_IP> -u <USERERNAME> -p <PASSWORD> -b 10
    2. The script selects 10 CGs based on ascending order of the CG name list.
    3. 10 is the maximum number of CGs you can provide in a window.
    4. The script keeps all CGs in a queue and ensures that always 10 CGs are replicating in parallel.
    5. Detailed cg_resume_status.txt report is generated inside resume_logs/resumereports folder for manual review.
  10. Apply postrestore configurations. Run this final script only if all CGs are in Active status.
    1. To run the .exe in postrestore mode, enter the following command:
      cg_backup_restore_1.7 Script3 -i <RPC_IP> -u <USERERNAME> -p <PASSWORD> -o <BACKUP FOLDER NAME>
    2. This command reapplies or restores additional CG settings such as:
      • Protection policies
      • Re-IP settings
      • Failover-network mappings
      • Copy policies
      • Additional remote copies
      • All Group Sets
  11. Revert Binary patch fix applied in Step 7.
    1. To copy the backup binary back to the lib folder to revert the changes on all RPAs, do the following:
      1. Run the command cp /root/libmanagement_libs-release.so /usr/lib/recoverpoint/.
      2. To kill the control process after lib replacement:
        1. Run the command pkill -9 control_proces .
      3. Wait until the dashboard returns to green status.

Next steps

Troubleshoot the Migration Issues

  • Issue: While removing the vSCSI splitter from the host, the error can't remove '/tardisks/emcrpspl.t00' : Device or resource busy appears.
    • Resolution: Use SSH to run the following commands from the ESXi host console:
      1. Put the host in maintenance mode: ESXicli system maintenanceMode set -e=true.
      2. Stop the splitter daemon manually: /etc/init.d/rp-splitterd stop.
      3. Remove the splitter: ESXicli software vib remove -n RP-Splitter.
      4. Exit the maintenance mode on the ESXi host: ESXicli system maintenanceMode set -e=false.
  • Issue: In a multi cluster environment, when you upgrade all the vRPA cluster together, you can get Upgrade has failed error.
    Figure 1. Cluster upgrade error
    Cluster upgrade error
    • Resolution: Do not install the connected vRPA clusters together. Upgrade the connected clusters one after the other.
  • Issue: Upgrade splitter fails with Connection to server failed error.
  • Issue: Upgrade of Splitter and jiraf from the admin CLI fail with error Operation failed. Failed getting vibs from ESXi <hostname>.
    • Resolution: If any of the ESXi is still exiting maintenance mode, wait for it to complete and then retry upgrade from the admin CLI.
  • Issue: Upgrade of JIRAF from admin CLI fails with error Operation failed. Failed to install iofilter on <ESXi_hostname>.
    • Resolution: Possible causes and their solutions are listed below:
      • If an error message is displayed for all ESXi, then the reason could be that VIB URLs are not trusted in VC. Trust the VIB URLs and retry the upgrade. See the section Trust Splitter and Jiraf vSphere Installation Bundle (VIB) URLs in vCenter
      • Maintenance mode issue can cause jiraf upgrade to fail in some ESXi. To confirm, check the table of splitter and jiraf versions that are displayed in the admin CLI. Follow the below steps to proceed,
        • From vSphere UI, check if problematic ESXi is still entering maintenance mode. If any maintenance tasks are running in the vSphere task console, wait for them to complete.
        • Identify why one or more ESXi servers are not moving into maintenance mode. To resolve this issue, manually move the problematic ESXi servers into maintenance mode.
        • After the above issue is resolved, vSphere Life-Cycle Manager (vLCM) triggers the task to upgrade the jiraf automatically.
        • Log in to problematic ESXi and ensure that the jiraf is upgraded to the right version. Also verify the same at ESXi cluster level from vSphere using the path ESXi Cluster > Configure > I/O Filters > URL.
        • If there is a mismatch of JIRAF version on ESXi server in the above step, retry upgrade from admin CLI only after manually exiting from the maintenance mode on problematic ESXi.
  • Issue: Unable to restore CGs again after unprotecting all restored CGs.

    If a restore operation is performed once and because some issue the CGs are unprotected, attempting to restore them again from the same backup results in a script failure with an error. This error indicates that the CGs are already restored.

    Resolution: To restore CGs again from the backup, do the following:

    1. Open the cg_status.txt file in the output directory (backup folder) of the previous restore.
    2. Identify the CGs you want to restore again.
    3. Change the CG status from RESTORED to PENDING.
    4. Save the file and rerun the restore script.
    The script detects these CGs as pending and proceeds with the restore operation.

Rate this content

Accurate
Useful
Easy to understand
Was this article helpful?
0/3000 characters
  Please provide ratings (1-5 stars).
  Please provide ratings (1-5 stars).
  Please provide ratings (1-5 stars).
  Please select whether the article was helpful or not.
  Comments cannot contain these special characters: <>()\