Site Recovery Manager (SRM) is a powerful orchestration tool designed to manage the recovery of virtual machine compute nodes across sites. It supports two primary methods for replicating data between source and disaster recovery sites:
When creating Protection Groups and Recovery Plans within SRM, it is important to keep vSphere Replication VMs separate from Array Based Replication VMs, and to group VMs by their storage vendor to ensure proper management and recovery workflows. This guide provides detailed procedures for creating Protection Groups and Recovery Plans using both replication methods, helping administrators effectively protect and recover their virtual environments.
The cause for issues related to creating Protection Groups and Recovery Plans in Site Recovery Manager often stems from mixing different replication types or storage vendors within the same Protection Groups and Recovery Plans. Specifically, combining vSphere Replication VMs with Array Based Replication VMs, or grouping VMs from different storage vendors together, can lead to:
Proper segregation according to replication method and storage vendor is necessary to ensure successful replication and recovery operations.
Replicate files from source site to disaster recovery site (DR) or target site.
On the Target datastore page, select a datastore on which to replicate files. and click Next.
Notes:
Disk format for the automatically included disks is determined the following way:
On the Replication settings page, use the RPO slider to set the acceptable period for which data can be lost if a site failure occurs. The available RPO range is from 5 minutes to 24 hours.
(Optional) To save multiple replication instances that can be converted to snapshots of the source virtual machine during recovery, select Enable point in time instances and adjust the number of instances to keep.
Note: You can keep up to 24 instances for a virtual machine. For example, if you configure vSphere Replication to keep 6 replication instances per day, the maximum number of days you can set is four days.
The number of replication instances that vSphere Replication keeps depends on the configured retention policy, but also requires that the RPO period is short enough for these instances to be created. Because vSphere Replication does not verify whether the RPO settings creates enough instances to keep, and does not display a warning message if the instances are not enough, you must ensure that you set vSphere Replication to create the instances that you want to keep. For example, if you set vSphere Replication to keep six replication instances per day, the RPO period must not exceed four hours, so that vSphere Replication can create six instances in 24 hours.
(Optional) Activate quiescing for the guest operating system of the source virtual machine.
Note: Quiescing options are available only for virtual machines that support quiescing. vSphere Replication does not support VSS quiescing on vVOL.
(Optional) Select Enable network compression for VR data.
Compressing the replication data that is transferred through the network saves network bandwidth and might help reduce the amount of buffer memory used on the vSphere Replication server. However, compressing and decompressing data requires more CPU resources on both the source site and the server that manages the target datastore.
(Optional) Activate the network encryption of the replication traffic.
If you configure a replication of an encrypted VM, this option is automatically turned on and cannot be deactivated.
Optional Add to a new protection group. input the name for Protection group name: and click Next.
Procedure
Array-Based Replication Protection Groups and Datastore Groups requires the VM's to be storage vMotion to the replicated datastore.
Procedure
For more information for creating Array-Base Replication Protection Groups SRM 8.8 to 9.0, see Add and Remove Datastore Groups or Virtual Machines to or from a Protection Group.