On this page
Choose the exercise that answers the recovery question
| Exercise | What it can establish | What remains outside the result |
|---|---|---|
Selected file or sample restore | Whether chosen data can be retrieved from a selected recovery point and checked against agreed criteria. | Recovery of the whole application, all data or its business dependencies. |
Application recovery exercise | Whether an agreed workload and its included dependencies can support selected business checks in the test environment. | Unincluded workloads, different failure conditions or production failover unless explicitly tested. |
Tabletop exercise | Whether people can work through a scenario, identify decisions and expose gaps in responsibilities or instructions. | Proof that backup data can be restored or an application can run. |
Authorized failover exercise | Whether a defined change to a recovery environment works under the approved conditions, including selected business checks. | Every possible incident or a guarantee of future recovery time; return to normal operation also needs a plan. |
Write the test boundary before restoring anything
A recovery test plan should make the boundary visible before work starts. Isolation must be designed and checked; calling an environment a test system does not prevent it from reaching production dependencies.
- Name the business workflow and the application owner who can judge whether it works.
- Select the recovery point and included data, systems and dependencies. Record excluded systems and how their absence limits the test.
- Identify the required identities, permissions, name resolution, network paths, licenses and available recovery capacity.
- Define the destination environment and isolation controls, including restrictions on outbound email, scheduled jobs and external integrations.
- Assign the test operator, decision maker, business validator and person authorized to stop the exercise.
- Agree timing boundaries, evidence handling, cleanup, stop conditions and return-to-normal or rollback steps as applicable.
- Obtain explicit approval for production impact, failover or any change outside the planned test environment.
Use a business workflow to expose missing dependencies
Hypothetical example: a team needs to recover its order-processing application. The restored server starts, but an application owner must still sign in, open the selected historical order and produce the agreed internal output. Those checks may depend on identity, DNS, a database and access permissions beyond the server itself.
The exercise should prevent test activity from creating live orders or contacting production integrations. Use an approved test transaction or a read-only workflow where appropriate. If an external dependency is simulated or excluded, record that limitation in the result. This scenario illustrates test design; it is not a completed customer recovery or a claim that Root supports a particular application.
Agree how business users will judge the restored result
| Acceptance layer | Example check | Responsible participant | Evidence to retain |
|---|---|---|---|
Selected data | Confirm the recovery point, included records and agreed data-integrity or currency checks. | Data or application owner with the test operator. | Recovery point, sample selection, check method, observed result and any gaps. |
Technical restore | Verify that the agreed restored workload starts and exposes the required test services. | Authorized workload operator. | Restore record, environment details, observed timings and relevant errors. |
Dependencies and access | Confirm the included identity, DNS and network paths and the intended user permissions. | Owners of the included dependencies. | Dependencies exercised, access results and exclusions or simulated connections. |
Business workflow | Run the approved application task and inspect its result without creating unintended production effects. | Named business or application validator. | Expected and observed result, validator decision and remaining exceptions. |
Exercise closure | Confirm test data, resources and temporary permissions are handled according to the agreed cleanup plan. | Exercise owner and relevant system owners. | Completed cleanup checks, retained evidence and assigned follow-up actions. |
Keep recovery objectives separate from observed results
The recovery point objective (RPO) expresses the targeted tolerated data-loss interval. The recovery time objective (RTO) expresses the target time to restore the required service. They are planning objectives, not measurements established by a successful backup job.
Record the actual recovery point used and any observed data gap relative to the exercise reference time. For timing, define when measurement starts and what ends it: beginning the restore, booting a server and accepting a business workflow describe different intervals. Include the elapsed time to the agreed acceptance point and explain any preparation or dependency work excluded from the clock.
Compare observed results with the agreed objectives using those boundaries. A controlled test can expose readiness gaps and demonstrate what worked under its conditions; it does not guarantee recovery time or data availability in a different incident.
Turn test exceptions into owned corrections and retests
Record the result and its limits
Retain the exercise scope, selected point, conditions, checks and results. Identify whether each criterion passed, failed or was not tested; an untested dependency must remain visible.
Assign the exception
Explain the business effect and name an accountable owner. A missing permission, unavailable key or unclear application check requires a different correction from a failed restore process.
Authorize and complete the correction
Choose a corrective action, approval path and completion evidence. Changes to production protection or recovery design need their own approval rather than being treated as an automatic test follow-up.
Retest the affected workflow
Repeat the failed check and relevant dependencies, then obtain the appropriate owner’s acceptance. Record what the focused retest establishes and whether a wider exercise is still needed.
Connect the test to the systems it depends on
Protection and objectives
Backup and disaster recovery planning covers protection scope, retention and the recovery objectives that inform an exercise.
Workload ownership
Server and workload administration provides the maintenance and ownership context needed to identify a usable restored system.
Incident decisions
Security response responsibilities govern security decisions around an actual compromise. A planned exercise does not authorize reconnecting potentially affected systems.
Platform dependencies
Review cloud and virtualization dependencies when permissions, capacity, networking or platform placement affect the recovery environment.
Recovery testing questions
Does a successful backup job prove that our application can recover?
No. Job completion is one piece of evidence. The relevant restore, dependencies and agreed business checks must be exercised to establish what is usable within the tested scope.
Can a test use backups managed by another provider?
That depends on the platform, permissions, licenses, data ownership and cooperation available. Review those prerequisites before agreeing a test; access to a backup file alone does not establish a supported recovery path.
How often should we test recovery?
Set the cadence according to business criticality, material system changes, prior exceptions and applicable organizational obligations. Revisit it when dependencies or recovery arrangements change rather than relying on a universal interval.
Does meeting an RTO in a test guarantee an incident recovery time?
No. Retain the timing boundaries, test conditions and exclusions alongside the result. A real incident can introduce different access, infrastructure and dependency constraints.
Is this an emergency recovery service?
This page describes a planned, controlled exercise. Emergency work, incident responsibilities and availability must be confirmed separately; a test inquiry does not establish emergency response coverage.
Plan a recovery exercise around one business workflow
Identify the workflow, its application owner, the current backup arrangement and the decision the test must support. Root can discuss an exercise boundary and acceptance checks around that need. Begin with a summary; arrange approved access and record sharing during scoping.
The email action opens a draft in your email app for you to review and send.