What a restore test actually proves

What it means

A recovery goal is the outcome you need to demonstrate: which data must be recovered, where it must be usable, which application behavior must work and, when relevant, within what time limit. A restore drill gathers evidence against those requirements rather than treating backup status as the result.

Here, a fixture means a small set of known test records. The expected fixture is a=20, b=30 and c=50. These fixed expectations let you distinguish missing data, changed values and a blocked application check. This page concerns evidence from recovery testing, not how to create a backup or establish database snapshot consistency.

Try it

Example: this is a local synthetic comparison, not a restore operation. Keep Test target = isolated test; production is a STOP branch, not an authorized destination. Start with Restored fixture = missing row and Application dependency = available, then change only Restored fixture to complete. Inspect what changes and why. Use Compare with baseline to contrast the current result with the initial failure; it does not keep a history.

Fixture recovery check failed. Recovered 2/3 rows; sum 50/100. Missing IDs: c; changed values: none. The two recovered values match, but record c and its amount of 50 are absent. An existing archive or successful copy command does not establish the expected data result.

Keep Application dependency = available and Test target = isolated test while changing Restored fixture from missing row to complete. This isolates the effect of restoring the missing record.

Reset restores Restored fixture = missing row, Application dependency = available and Test target = isolated test. It clears input errors and the baseline comparison, returning the result to the initial fixture failure. It does not change which FAQ answers or About this model panel you have opened. There is no running clock or event history to reset.

How it works

Backup completion, restored-data verification and application usability answer different questions. Completion says an operation reached its reported end; it does not itself show that the resulting data matches what recovery requires. Data verification supplies that next observation. Application checks then address whether the restored environment can perform the required work.

For valid inputs, this model checks the target first. Test target = production produces STOP: test target is not isolated. It does not evaluate the fixture in that branch. This is a safety boundary of the rehearsal, not a database protocol rule or permission to perform a real restore.

For an isolated target, the model constructs the selected fixture, compares its record IDs and amounts with the expected records, and calculates the count and sum. Missing or changed records cause Fixture recovery check failed. For example, wrong value changes b from 30 to 31: all three rows remain, but the sum is 101/100 and b is identified as changed. A correct row count therefore cannot override the value mismatch.

Only after the data matches does the dependency choice determine the next result. An unavailable dependency leaves the application check unknown. An available dependency permits Declared fixture checks pass, but this is still a local rule based on a declared condition—not an executed application test.

Worked example

This is a synthetic baseline, not a captured production observation. The inputs are Restored fixture = missing row, Application dependency = available and Test target = isolated test.

The recovered amounts total 20 + 30 = 50 rather than 100. The result is Fixture recovery check failed: Recovered 2/3 rows; sum 50/100. Missing IDs: c; changed values: none.

“Changed values: none” does not mean the fixture is complete. It means the records that are present have their expected amounts. The missing-ID comparison supplies the decisive evidence that the recovery requirement was not met.

What changes when the condition changes

Change Restored fixture to complete. Keep Application dependency = available and Test target = isolated test.

Declared fixture checks pass. Recovered 3/3 rows; sum 100/100. Missing IDs: none; changed values: none.

The added record c contributes the missing 50, bringing both the count and total to their expected values. The model now finds no missing ID or changed value. Only this data fixture and available dependency are covered. Actual timing, permissions, other records and application behavior remain separate checks.

Now change only Application dependency to unavailable. The data still matches, but the result becomes Data fixtures match; application check unavailable. This is unknown, not a data failure or a demonstrated service recovery: the required application-level evidence is missing.

In practice

Use the following as a planning checklist for an authorized drill, not as database restore commands. The environment must be a separate test destination with permission to read the selected backup and create or change only the named test resources. Use the official restore procedure for your exact engine, version and backup method.

STOP before any restore if the destination identity, isolation, permissions or applicable restore/rollback procedure is uncertain. A production cutover is outside this drill's scope.

1. Define the scope and expected observations. Record the backup identifier, intended recovery point, engine and application versions, exact test destination, and required configuration and dependencies. Choose data checks and representative application behavior before starting. If the goal includes a recovery-time limit, state that limit and arrange to record actual elapsed time; this Example supplies no timing evidence.
2. Perform a read-only preflight. Inspect backup metadata, destination paths, account permissions and the test environment's configuration. Confirm that test writes, messages and notifications cannot reach production destinations. Preserve the original backup and record the destination's before-state. Prefer a disposable destination that contains no data you need to retain. Do not proceed if the backup's required consistency conditions are unknown.
3. Authorize the minimal test-only change. Follow the applicable restore runbook for that backup and destination only. A successful completion message is an intermediate observation, not the acceptance criterion. Expect the required restored objects to be available for inspection. If the operation fails or reaches an unexpected target, stop rather than extending its scope or repeating it blindly.
4. Verify separate layers. Compare restored data with the declared expectations, confirm the required configuration and permissions, and exercise the chosen application behavior with its dependencies. Record mismatches, unavailable checks and elapsed time separately. A data mismatch is a failed check; an application check that could not run is missing evidence. Neither justifies a production cutover.
5. Close or roll back within the agreed scope. Before starting, specify how the test destination and any test-only configuration will return to their recorded before-state. On failure or uncertainty, stop application testing, preserve the failure evidence, and use that approved rollback procedure. Remove test artifacts only when their exact scope and removal are authorized. Verify the resulting test state and that the original backup and production environment remain unchanged.

Keep an evidence record containing the backup and destination identities, versions, checks performed, expected and observed results, failures, timing and untested items. That record makes the conclusion inspectable instead of reducing the drill to a completion badge.

Limits and unknowns

Three invented records and one sum check cannot establish a real restore, full integrity, security or recovery time. The model also compares the declared IDs and values, but it has no coverage of other records, database relationships, permissions or application behavior. Selecting Application dependency = available does not run an application or verify a real dependency.

The result follows the evidence available at each branch. A production target stops the exercise before fixture comparison. A missing or changed record produces a fixture failure even if the dependency is unavailable; matching data with an unavailable dependency produces an unknown application result. If the visible input is invalid, no calculated outcome applies until it is corrected or Reset is used.

The initial example remains readable without JavaScript. Interactive controls require JavaScript. No real machine, account, archive, request or service is inspected, and no inputs are sent to a restore system.

What to carry forward

Match the recovery claim to the evidence collected. Verified records support a data claim; demonstrated application behavior supports a service-usability claim; recorded elapsed time supports a timing claim. If a required check could not run, name that gap rather than treating it as a pass. Your next step is to collect the missing evidence in an authorized isolated environment, not to infer readiness from backup completion.