Veritas™ Resiliency Platform 2.2 Solutions for VMware
- Section I. Overview of Resiliency Platform
- Overview of Resiliency Platform
- Overview of Resiliency Platform Data Mover
- Overview of recovery to on-premises data center
- Managing assets protected by NetBackup
- Overview of Amazon Web Services
- Overview of vCloud
- Section II. Preparing your environment
- Using array-based replication
- Using Veritas Resiliency Platform Data Mover
- Managing disaster recovery network mapping
- Managing Replication Gateway pairs
- Using array-based replication
- Section III. Working with resiliency groups
- Managing resiliency groups
- Configuring resiliency groups for remote recovery
- Managing virtual machines for remote recovery (DR) using 3rd party replication technology
- Managing virtual machines for remote recovery (DR) using Resiliency Platform Data Mover
- Managing virtual machines for remote recovery (DR) in Amazon Web Services
- Managing resiliency groups
- Section IV. Managing disaster recovery
- Rehearsing DR operations to ensure DR readiness
- Performing disaster recovery operations
- Rehearsing DR operations to ensure DR readiness
- Managing resiliency plans
- Creating a new resiliency plan template
- Monitoring risks, reports, and activities
- Managing evacuation plans
- Appendix A. General troubleshooting
- Resolving the Admin Wait state
- Appendix B. Sample policy and trust relationships for AWS
Troubleshooting delete resiliency group operation
While performing the delete resiliency group operation, if any of the sub-tasks fail, you can perform the following steps to reclaim the resources.
Perform the following tasks on Replication Gateways on the production and Cloud data center
- Check for participating consistency groups.
/opt/VRTSsfmh/bin/xprtlc -l http://localhost:8080/ConsistencyGroup
- Verify that replication is stopped on the gateway.
/opt/VRTSsfmh/bin/xprtlc -l http://localhost:8080/ConsistencyGroup/<CG_ID>/state
- Abort replication on gateway if replication is not stopped.
/opt/VRTSsfmh/bin/xprtlc -m POST -l http://localhost:8080/ConsistencyGroup/<CG_ID>/abort
- Delete the consistency groups.
curl -X DELETE http://localhost:8080/ConsistencyGroup/<CG_ID>/delete
Perform the following tasks on the hosts on the production data center
- Verify that the consistency groups are deleted.
Linux host:
/opt/VRTSitrptap/bin/vxtapinfo status
Windows host:
C:\Program Files\Veritas\VRTSitrptap\cli\vxtapinfo status
- Delete the consistency groups if the state is active.
Linux host:
/opt/VRTSitrptap/bin/vxtapaction stop -cg <CG_ID> /opt/VRTSitrptap/bin/vxtapconfigure delcg -cg <CG_ID> -force
Windows host:
C:\Program Files\Veritas\VRTSitrptap \cli\vxtapaction stop -cg <CG_ID> C:\Program Files\Veritas\VRTSitrptap \cli\vxtapconfigure delcg -cg <CG_ID> -force
- Verify that the journal disk is removed from each of the virtual machines on the production data center.
Size of the journal disk is usually 1 GB and naming format is:
[<datastore-name>] <vm-hostname>/drl-<uuid>/ITRPSRDRLDisk.vmdk
Remove the journal disk using vSphere client or Hyper-V UI.
Ensure that the file is deleted.
- Unconfigure network setting on the virtual machines on the production data center.
Linux host:
/opt/VRTSsfmh/bin/perl /opt/VRTSsfmh/util/reconfig_vm_settings_on_prim -unconfigure
Windows host:
C:\Program Files\Veritas\VRTSsfmh\bin\perl.exe C:\Program Files\Veritas\VRTSsfmh\util \reconfig_vm_settings_on_prim -unconfigure
- For physical machines, you need to unsign the DRL disk:
Linux host:
Get the device name of DRL disk by executing the following command:
/opt/VRTSitrptap/bin/vxtapdrlfind
Execute the following command to unsign DRL disk:
/opt/VRTSitrptap/bin/vxtapdrlsign clear -drl_dev device_name
Where, device_name is the device name of the DRL disk.
Windows host:
Get the device name of DRL disk by executing the following command:
C:\Program Files\Veritas\VRTSitrptap\cli\vxtapdrlfind.exe
Execute the following command to unsign DRL disk:
C:\Program Files\Veritas\VRTSitrptap\cli\vxtapdrlsign clear -drl_dev device_name
Where, device_name is the device name of the DRL disk.
- Refresh the virtualization server if the resiliency group contains virtual machines.
Perform the following on cloud virtual machines:
Verify that the migrated cloud virtual machines are terminated and their volumes are deleted, including the Replication block tracking disk.
Note that the naming convention for Replication block tracking disk is
DRLVolume_RaaS_<GUID>
whereas for other disks the name starts withresiliency-group-name_virtual-machine-name
.Delete any snapshots for cloud volumes.
Detach the cloud volumes from the cloud gateway.
Remove the cloud virtual machines from the cloud IMS.
More Information