Recovery Plan Compliance Checks

Compliance checks scan recovery plans to verify and validate all configurations and mappings between a protected site and a recovery SDDC.

Each recovery plan provides continuous compliance checks to ensure that all plan configurations and mappings are valid before you run a plan. Compliance checks run regularly every 30 minutes.

Compliance checks also make sure that the specified protection groups are live on the protected site and are replicating successfully to the target recovery SDDC. A plan can become out of compliance if any of its conditions become violated because of environmental or plan configuration changes.

Failing compliance checks transition a recovery plan into a degraded health state of warning or critical. When a plan fails a compliance check, an email is sent to the recipients configured in the VMware Live Cyber Recovery settings. Health checks run on a per-plan basis. Some plans can have an OK health status, while others can be in degraded states at the same time.

As a recovery plan is created, tested for compliance, and run, VMware Live Cyber Recovery maintains detailed logs of all the actions that were performed, the plans that were completed, and the compliance checks on those plans. You can generate and download these reports as a PDF or have them emailed on an automated schedule.

Compliance state for a plan does not restrict failover or test operations. Even if a plan is non-compliant in some areas, you can still run as a failover or test failover plan.

As a best practice, check your recovery plan compliance before you run it. You can also set email alerts in the plan to notify you if a recovery plan is out of compliance.

Note: Only run a recovery plan if the compliance check is green. If a recovery plan compliance check is not green, the plan will likely not run successfully.

To check plan compliance, select a recovery plan, and then check the compliance box:

To view plan compliance, click the Show button. To run the compliance report on demand, click the small refresh button at upper-right of the Continuous compliance box.

You can view the Compliance column in the list of recovery plans to quickly identify plans that are out of compliance:

Recovery plan compliance reports check for the following configurations and mappings:

Protected Site

Connection to source site	Checks the presence and availability of all source vCenters referenced in the plan and checks connectivity of the vCenter.
Replication health	Checks the relationship between source and destination replication to make sure replication is possible.
Datastores exist on source site	Checks for the existence and health of all source datastores defined in the plan. Datastore capacity is checked as part of snapshot replication health.
Protected groups replication schedule	Checks the snapshot retention for protection groups referenced by the plan. If snapshot retention for protection groups in the plan is less than 90 days, this item is flagged.
Networks exist on source site	Checks the existence of all source DNS servers and gateways listed in plan.
Resource pools exist on source site	Checks the existence of all source resource pools listed in the plan. If a cluster resource pool is mapped for either source or destination, the compliance check ensures that the Distributed Resource Scheduler (DRS) is activated.
Folders exist on source site	Checks for the existence of all source folders listed in the plan.
Protection groups are healthy	Each recovery plan compliance verifies the existence and live status of protection groups referenced by the plan on the source site. Recovery plan compliance checks indicate if any VMs in the snapshot were not snapshotted, according to the protection group configuration. For example, if you configure a protection group to quiesce all VMs before taking a snapshot, and some VMs were not quiesced, then the recovery plan compliance report indicates the mismatch. Protection group health compliance is also evaluated by these factors: If the most recent snapshot fails, has no VMs, is missing some VMs, or has expired. If the most recent snapshot was not queisced, and was configured to quiesce. If the most recent snapshot was taken on schedule or not. If a protection group snapshot schedule is expired. If a snapshot is empty (has no VMs), which might indicate that the queries defined in the protection group are not capturing any VMs. If a snapshot has any warnings during the operation, which indicates not all VMs were captured as configured in the protection group.
Snapshot parity	Checks to make sure that at least one snapshot exists for every VM referenced in the plan.
Clusters exist in source site and cluster name	Checks if all clusters referenced in the plan exist on the destination site, and checks to verify the name of the cluster as configured in the plan. If the cluster name changes or is deleted, then the plan is out of compliance. To be compliant, the name in the plan must match both the source and destination cluster name.

Recovery Site

Connection to failover site	Checks to ensure that there is network connectivity to the recovery site (a recovery SDDC), and checks connectivity to all destination vCenters referenced in the plan.. If you delete a recovery SDDC, then all compliance checks for that deleted SDDC are skipped. The plan compliance check will be healthy, but the plan cannot be run until the new recovery SDDC is added. Without having a recovery SDDC in place, a positive compliance report does not indicate DR readiness. It only means that the source site and protection group configuration is healthy. In order to ensure full compliance and DR readiness, you must deploy and fully configure all resources in an on-demand recovery SDDC and run a new compliance report to confirm DR readiness.
vCenter server registered in failover site	Checks to ensure that the vCenter server on the recovery SDDC is registered with VMware Live Cyber Recovery. The compliance check also verifies all vCenter authentication access and version compatibility, to make sure that source and destination vCenters are both accessible and version-compatible. Additionally, the compliance check ensures that a sufficient number of network ports are available in the vSwitch.
Datastores exist on failover site	Checks for the existence and health of all destination datastores defined in the plan. Datastore capacity is checked as part of snapshot replication health. Also checks that ds01 datastore is in a healthy state by checking for its existence, its maintenance mode status, free space statistics, and mounting and accessibility from hosts.
Protection groups can be recovered in failover site	Checks to ensure that all protection groups listed in the plan can successfully be failed over. Also ensures that at least one snapshot exists for every VM referenced in the plan.
Networks exist on failover site	Checks the existence of all destination DNS servers and gateways listed in plan. If you have defined IP address mappings, compliance checks report the presence of VMs without vSphere tools installed as warnings.
Resource pools exist on failover site	Checks the existence of all destination resource pools listed in the plan. If a cluster resource pool is mapped for either source or destination, the compliance check ensures that the Distributed Resource Scheduler (DRS) is activated.
Folders exist on recovery site	Checks for the existence of all destination folders listed in the plan.
Tags in protection group queries exist in recovery vCenter	Checks to ensure that any vSphere tags and tag categories associated with your protected VMs also exist on the destination recovery SDDC.
Clusters exist in recovery site and cluster name	Checks if all clusters referenced in the plan exist on the destination site and checks to verify the name of the cluster as configured in the plan. If the cluster name changes or is deleted, then the plan is out of compliance. To be compliant, the name in the plan must match both the source and destination cluster name.
VMs can be restored in recovery vCenter	Checks to ensure that there are sufficient snapshots that can be used to recover VMs in the plan. For all VMs referenced in the plan, the compliance check also verifies: The existence of VMs referenced by name in workflow steps on the source - VMs that are recovered outside of their Protection Groups. The existence of VMs referenced by name as targets for executing scripts. All VMs referenced by name are unique.

Orchestration

IP address mapping	If you have defined IP address mappings in a plan, compliance checks report the presence of VMs without vSphere tools installed as warnings.
Recovery steps	This compliance check ensures that all recovery steps can be run successfully without interference with other recovery steps. For example, it checks to determine if a named VM in a recovery step plan is actually in the protection group and can be recovered, and checks if elements and resources and items required to perform the steps can be found.
Script server recovered before script actions	Checks that the script server is configured to be recovered before any scripts are launched. This compliance check also verifies the user-supplied credentials required to run any custom scripts specified in the plan.

Ransomware Recovery

Item	Compliance Check Description
VMware Tools	Checks to see if the correct version of VMware Tools (11.2) is installed on the VM. If VMware Tools is missing or at a lower version, this item is flagged.
Carbon Black integration status	Checks the connection to Carbon Black Cloud Integrated security and vulnerability analysis. If VMware Live Cyber Recovery cannot connect with Carbon Black Cloud, then this item is flagged.
Carbon Black workload appliance health	Checks the health of the Carbon Black Cloud workload appliance.
Protection group snapshot retention	Checks the snapshot retention for protection groups referenced by the plan. If snapshot retention for protection groups in the plan is less than 90 days, this item is flagged.

Other Checks

VMC site health	Checks that VMware Cloud on AWS is healthy and reachable
VMC refresh token validity	Checks that the refresh token used for CLI operations is valid.