To test a recovery plan for disaster recovery, you can run the plan as a test failover.
A test failover runs in the context of its own test failover environment on the recovery SDDC, specified by the recovery plan’s test mapping rules. The results of the test failover do not permanently affect a recovery SDDC. Test failovers cannot be failed back. VMs that are recovered for testing will be destroyed at the end of the disaster recovery test during the clean-up process.
The Orchestrator runs continuous compliance checks on a recovery plan to ensure that the plan is compliant with its own steps and mappings. But compliance checks alone do not catch all possible errors that can occur during a failover.
Run a test failover recovery plan on a periodic basis, so that you can determine if your plan works as you intended, to make sure that all IP address mappings work correctly on the VM guest OS, all your vCenter folders and settings can be recovered on the target, all scripts run correctly and in the proper order, and so on. Test failovers can also be used with periodic compliance reports to satisfy your company’s disaster recovery preparedness auditing policy.
A test failover stops on the first failure by default. You can override all other default behaviors using custom options. For unattended plan runs, you can configure a test failover to run to completion while ignoring all errors.
Test failover operations give you the option of performing a full Storage vMotion from the staging datastore to the SDDC datastore to simulate a real failover, or to leave VMs on the staging datastore to cut down on the failover time, and to allow you to test and debug your failover faster. With this more cost effective preview feature, the SDDC can be substantially smaller in size because VMs are kept on the cloud file system datastore, eliminating the vSAN storage capacity constraints, which can incur costs.
Once you have fully run the failover test and have checked the VMs in the vCenter, you must clean up the test. Click the Cleanup button to roll back all test side effects on test completion.
Creating an Optional Isolated Test Environment
When you configure a recovery plan, you can specify separate operating environments within the recovery SDDC, depending on whether the plan is run as an actual failover or failover test.
If you are performing a test failover, you can leverage this capability by testing with an isolated set of pre-configured networks, resource pools and/or folders on the recovery SDDC to ensure that there no impact on production. Isolating network segments for testing, for example, may help avoid issues like duplicate IP addresses if production failover networks are routed networks.
