Recovery Testing Should Prove More Than the VM Boots

A recovery test that ends when the VM reaches a login screen has answered a useful question. It has not answered the business question.

Rubrik Security Cloud can orchestrate VM recovery, map target compute and storage, apply recovery networks, control boot order, schedule recurring tests for supported workloads, and produce recovery reports.[1][2][3][4] For vSphere Recovery Plans, Rubrik also supports post-failover scripts specifically intended to confirm that the protected application is online and ready for users.[2]

That last detail is the part I would build the test around. The VM boot is evidence. Application usability is the outcome.

A Green Recovery Job Does Not Mean the Service Is Back

Rubrik Orchestrated Recovery uses Recovery Plans to group virtual machines and their target recovery specifications. A plan can define priority groups, target resources, storage placement, network configuration, and supported scripts. During a test failover, RSC instantiates recovery VMs at the recovery site, maps the resources defined in the Recovery Plan, and starts the VMs according to the configured priority order.[1][2][3]

If that workflow completes, the result matters. It proves that the selected recovery points were consumable, the target infrastructure could create the VMs, the configured resource mappings were usable, and the orchestration reached its completion state.

The business service can still be broken.

The application may be listening on the wrong interface. DNS may resolve to production. A service account may not authenticate in the recovery environment. A certificate may be tied to a hostname or key service that is unavailable. A database can mount while an application schema check fails. A web tier can start while its database, API, message queue, file share, license server, or load balancer path is missing.

Those failures sit above the hypervisor console, which is why a test that stops at boot is too shallow for service recovery.

Rubrik Gives You a Recovery Test Framework, Not Your Application Acceptance Criteria

A Recovery Plan is useful because it turns part of the recovery design into executable configuration. Rubrik documents priority groups as the mechanism that controls VM boot order; VMs in the same group can boot simultaneously.[2] For vSphere disaster Recovery Plans, RSC can also map compute, datastores, target networks, IP configuration, DNS servers, gateways, and post-instantiation scripts.[5]

That gets the recovered machines into a deliberate target state. It does not tell Rubrik what a valid business transaction looks like for your application.

For vSphere Recovery Plans, Rubrik's post-failover scripts are explicitly intended to confirm that the protected application is completely online and ready for users.[2] That is a strong place to automate checks that the guest can perform reliably, such as confirming a service is running, opening a local application endpoint, testing a database connection, or executing an application-specific health command.

The script still needs an acceptance criterion. A command returning zero is meaningful only when the command represents something the service owner actually cares about.

Architecture point Recovery automation should execute the known recovery sequence. Recovery validation should prove the service-level outcome. The same workflow can support both, but the acceptance logic has to come from the application and business design rather than from the existence of a completed restore task.

Test the Network the Application Will Actually Need

Rubrik disaster recovery test failovers use test networks configured in the Recovery Plan so the recovery VMs can run without colliding with the production environment. Production continues to run at the primary site during the test and continues replicating to the recovery target.[3]

That isolation is exactly what makes a test safe, but it can also hide or create dependencies if the test network is not designed carefully.

A test network may need its own route set, firewall policy, DNS resolution, authentication access, load balancer configuration, or controlled access to a dependency that is intentionally shared. If the test substitutes a flat sandbox where every recovered VM can talk to everything, it may prove a path that will not exist during a real recovery. If the test isolates too aggressively and omits DNS or authentication, it can fail for reasons unrelated to the protected application.

Rubrik's cyber recovery documentation calls this out directly. For a completely isolated recovery environment, Rubrik says to include the fundamental infrastructure services required by the recovered objects, including DNS and authentication services.[7]

I want the recovery network to be safe enough for testing and realistic enough to expose the dependencies the service will have when it matters.

Boot Order Is Only the First Dependency Test

Priority groups are useful because they let the plan express startup order. A database tier can come up before an application tier, and independent systems can start in parallel.[2]

Startup order does not describe the entire dependency graph.

An application may need DNS before its database connection works. The database may need storage and a domain service. A middleware tier may need a certificate authority, secrets service, or external API before the application becomes writable. A user-facing service may be technically healthy inside the recovery network while the load balancer, reverse proxy, or client route still points somewhere else.

The recovery test should therefore separate at least four states:

A recovery team should know which of those states its test report actually reached.

Scheduled Tests Are Valuable Because They Expose Drift

RSC can schedule periodic tests of disaster and cyber Recovery Plans for vSphere and AHV virtual machines. The scheduled workflow performs prechecks, runs the recovery, cleans up the test environment, generates a recovery report, runs postchecks as needed, and can send notifications.[4]

For scheduled recovery, RSC selects the latest non-quarantined snapshot. If no eligible snapshot is available, the scheduled recovery does not run.[4]

Non-quarantined is a scheduling eligibility rule, not a finding that the recovery point is clean. For cyber recovery, the team still needs to examine available threat-hunting results and validate recovered application data before accepting that point as usable.

The recurring test is valuable because recovery plans age even when nobody edits them. Compute targets change. Datastores move. Networks are renamed. Permissions change. A VM is added to an application but never added to the plan. An IP mapping that was correct six months ago may be wrong after a subnet change.

Rubrik exposes this kind of drift in the Recovery Plan state. Current documentation includes statuses such as missing resource mapping, invalid resource mapping, test paused on error, test failed, and test job succeeded.[10]

A scheduled test is therefore more than a calendar event. It is a repeated check that the encoded recovery configuration still maps to infrastructure that exists.

The application acceptance checks need the same treatment. If the health script still checks an endpoint that no longer represents the service, the recovery plan can be technically current while the validation is stale.

Measure Recovery at More Than One Clock

Rubrik recovery information includes start and end time, duration, recovery result, and recovery outcome for performed recoveries.[9] Those timestamps are useful because they give the team an infrastructure recovery measurement from an actual execution.

They are not automatically the business RTO.

The business clock normally ends later. The application may need database recovery, dependency startup, cache warmup, credential validation, DNS changes, load balancer registration, user acceptance, or a controlled reconnect to external systems after the VM recovery task completes.

I would capture at least three times during a meaningful test:

1. Recovery workflow time: when the recovery starts until RSC reaches the relevant completion state.
2. Application ready time: when the recovered application passes its technical health and data checks.
3. Service usable time: when the intended user or transaction path works from the recovery environment.

Those numbers can be close for a simple workload. For a multi-tier application, they can differ significantly.

Operational view If the only recorded time is the backup platform's task duration, the organization may be measuring VM recovery while believing it measured service recovery.

Workload Support Changes What You Can Automate

Rubrik Orchestrated Recovery currently supports VMware, AHV, and Azure virtual machines, but the available recovery and testing capabilities are not identical across those workload types.[1][8]

The current documentation draws several boundaries that matter to test design:

• Disaster recovery test failover is supported for VMware and AHV virtual machines.[8]
• Scheduled Recovery Plan testing is supported for vSphere and AHV virtual machines.[4]
• Azure virtual machines are supported for cyber recovery, not Rubrik disaster recovery.[1][8]
• Recovery Plans can contain one VM type only: VMware, AHV, or Azure.[2]
• For data-center workloads, every VM in the same Recovery Plan must be protected by the same Rubrik cluster.[2]
• AHV disaster Recovery Plans also assign target compute, storage, and network resources to the selected VMs.[6]
• Post-failover scripts in Recovery Plans are currently documented for vSphere virtual machines only.[2]

A multi-tier service protected across different Rubrik clusters cannot fit in one Recovery Plan. Coordinate the separate plans or recovery runbooks and validate the complete service once those workloads are running. Do not assume the validation automation available in one successful vSphere test exists for every RSC workload.

Where Rubrik does not provide the exact application validation mechanism you need, keep the validation outside the product and still make it part of the recovery test. A synthetic transaction, API test, database query, monitoring probe, or service-owner checklist can be valid evidence when it is repeatable and records a clear pass or fail result.

Cyber Recovery Makes the Service Test Even More Important

Cyber recovery adds another reason not to stop at VM boot. In Rubrik's documented vSphere Export workflow, RSC can recover virtual machines into a local isolated recovery environment, use selected target compute and storage, preserve or change network settings, recover with networking disconnected, assign recovery order, and run post-recovery scripts.[7]

That Export workflow also offers Ignore network reconfiguration errors and continue. When selected, network configuration or post-script errors do not cause the recovery job to fail.[7] This is a setting in the documented cyber Export workflow, not a blanket statement about every Recovery Plan. Check the selected error-handling option, the guest network state, and each post-script result before calling the recovered application healthy.

The recovery environment may intentionally differ from production. That is often the point.

A service that depends on production-only DNS, an external identity path, a license service, a hard-coded IP, or an outbound API may boot perfectly and still fail in isolation. The test should tell you whether the dependency must be reproduced, redirected, mocked, temporarily permitted, or documented as outside the recovery objective.

This is also where the service owner matters. Infrastructure can prove that the VM exists and the port is open. The application owner should define what proves that the recovered data and behavior are actually usable.

A Recovery Report Should Tell You What Was Proved

Rubrik can generate recovery reports for orchestrated recoveries and scheduled tests.[4][9] I would keep that report as part of the evidence package, then add the application validation results that sit outside the recovery task itself.

For each tested service, I want the record to answer:

1. Which Recovery Plan and recovery point were used?
2. Which target compute, storage, and network resources were used?
3. Did the Recovery Plan prechecks and recovery workflow complete, and which error-handling options were enabled?
4. Which VMs started, and in what priority order?
5. Did the recovered network match the intended test or recovery design?
6. Could the application resolve required DNS names and reach required dependencies?
7. Did authentication, certificates, service accounts, and secrets work where required?
8. Did the database or application data pass an integrity or consistency check appropriate to the service?
9. Did application-specific health checks pass?
10. Did a representative user or synthetic transaction succeed through the intended path?
11. What were the workflow, application-ready, and service-usable times?
12. Which checks failed or were ignored, including network remapping and post-scripts; what was corrected, and what runbook or architecture change followed?

A result of test job succeeded is useful. It should be one field in the evidence package, not the entire evidence package.

The Architecture Should Define Recovery Success Before the Test Starts

The easiest way to get a passing recovery test is to define success after seeing what came back.

I would do the opposite. Before the test begins, write down the minimum technical and service outcomes that must pass. Decide which checks Rubrik will execute, which checks external tooling will execute, who owns each result, and which failures stop the exercise.

For a simple application, the acceptance criteria might be one VM, one network path, one authentication check, one database query, and one synthetic transaction. For a larger service, the list will be longer. It should still be bounded enough that the team can run it repeatedly and compare results over time.

Rubrik can automate a significant part of the recovery mechanics. The design is finished when the organization also knows how it will prove that the recovered service works.

Source Notes

Product behavior changes. These references were checked against Rubrik primary documentation available on September 22, 2026.

Documentation access: The Rubrik documentation links below may require an authorized Rubrik OnePassport account. If a link opens a sign-in page, sign in to OnePassport to view the reference. The current contents of pages behind authentication have not been independently reverified for this revision.