AWS Backup Restore Tests: Check Coverage, Validation and Cleanup

Interpret an AWS Backup restore-testing run by selected scope, actual target, validation evidence and cleanup. Includes a constructed EC2 review record.

Primary sources checked 2026-10-17

Read the run before accepting the recovery claim

A completed AWS Backup restore-testing job answers a narrower question than whether an application can recover. Review which resource and recovery point were exercised, the target actually created, the checks behind any validation result and the state of cleanup. Keep those conclusions separate in one durable run record.

This guide helps a platform engineer interpret an existing restore-testing run. Its output is an evidence disposition: what was exercised, what the observations support and which requirements remain failed or unverified. The worked record concerns one EC2 resource, one plan and an isolated application-read requirement. It is constructed teaching data, not an AWS response, account inspection or completed recovery test.

The default workflow is authorized read-only review. It does not create a plan, start a restore, submit a validation result, change permissions, delete resources or reconnect production. Cross-account recovery authority, regional disaster recovery, traffic promotion and production-scale recovery objectives require their own evidence.

Establish the expected population before counting successful jobs

An AWS Backup restore-testing plan supplies scheduling and recovery-point rules; resource selections identify protected resources to include. Compare the intended workload inventory with the run, rather than treating the jobs returned by a query as the entire population.

AWS documents that a selected protected resource can be omitted when no recovery point meets the plan's criteria. That is an unexercised resource, not necessarily a failed restore job. Its absence must remain visible beside the jobs that did run. Restore-testing coverage and point determination.

Record the account, Region, plan, selection revision, expected resource and observation interval. Preserve exclusions explicitly. If the review concerns one EC2 instance, do not silently expand its result to an application database elsewhere, every account resource or all historical backups.

Check the actual resource and Region against AWS Backup feature availability. General backup support is insufficient evidence of restore-testing support for a particular path. This guide's EC2 example does not provide a universal supported-resource list or admit every configuration.

If a resource has no matching job, investigate selection scope, eligible points, timing and observation coverage. A denied read, incomplete inventory or missing result remains UNKNOWN until resolved. Do not relabel it “not applicable” merely to improve a success percentage.

Bind the decision to the selected recovery point

The plan's recovery-point selection defines included vaults, point types, a selection window and a latest-or-random algorithm. AWS evaluates the window from actual execution time. Keep the selected point's identity in the run record; the schedule and algorithm describe selection intent, not the resulting application state. Recovery-point selection fields.

There is also a tag boundary. AWS matches protected-resource tag conditions using the latest recovery point, but those conditions do not select the particular recovery point restored. An older point chosen by the algorithm may not match those tags. Confirm the actual point's suitability rather than treating a qualifying latest-point tag as permission to expose every earlier copy.

For an application-read requirement, suitability includes the expected data revision and compatible application release. A latest point may contain an unwanted change; an older point may omit a required record. Selection does not decide either issue for the application owner.

Retain the point, original resource, restore job and created-resource identities together. Similar names are inadequate when repeated tests produce multiple copies. A validator reaching the original service or yesterday's target supplies evidence for the wrong resource.

Compare intended metadata with the target that exists

AWS Backup infers restore metadata and permits resource-specific overrides. The inferred-metadata documentation describes EC2 subnet, security-group and instance-profile options. An inferred value is chosen to support restoration, not an application owner's isolation approval.

Inspect both the saved selection and the metadata of the particular job. Then obtain authorized evidence of the resulting target's actual placement and identity. A preview of inferred metadata is useful before a separately approved test, but cannot replace the job record afterward.

EC2 recovery also has application limitations. AWS documents that it does not back up and restore EC2 launch user data or automatically rejoin a restored instance to an Active Directory domain. A compatible application environment may therefore require work beyond a completed restore. EC2 restore considerations.

Do not infer harmlessness from a new instance ID or private subnet. Restored disk state can contain schedules, workers or integration configuration. Before any separately authorized application attachment, its owner must verify the intended network, identity and outbound-effect controls. If these observations are missing, hold that attachment and its acceptance claim. Read-only review does not authorize changing the target to make the test pass.

Keep four permission paths distinct

The evidence reader needs permission to inspect approved metadata and logs. The restore selection identifies the role used for resource restoration. AWS also has a restore-testing service-linked role. A validator or application reader has a separate execution and data-access path.

The service-linked-role documentation describes AWSServiceRoleForBackupRestoreTesting. Its presence does not establish that the selected restore role or application identity has the required access. The EC2 restore guidance separately distinguishes the restored instance's application profile from the AWS Backup service role.

For encrypted EC2 volumes, trace the actual EBS snapshot/key dependencies rather than assuming that the backup vault's key describes every object. AWS's encryption table distinguishes EC2 image and EBS encryption from independently managed vault encryption. A visible key identifier does not establish effective use permission.

Ask the security owner to review the intended principals, policies, keys and request contexts. Do not remove a deny, attach administrator access, change a key policy or delete a service-linked role to complete this worksheet. Control-plane read access also supplies no authority to read restored customer records. Record an inaccessible observation as a gap, with the responsible owner.

Read restore, validation and deletion as separate states

DescribeRestoreJob exposes distinct status families. Preserve each value, message and observation time. Do not compress them into one green result.

Restore job

What to inspect: Status, job/source/point/created-resource identities and timestamps

What it cannot establish alone: Application correctness or coverage of resources with no job

Reported validation

What to inspect: ValidationStatus, workflow logs, validator revision and checked target

What it cannot establish alone: Checks that the validator did not perform

Cleanup

What to inspect: DeletionStatus, messages and exact remaining resources

What it cannot establish alone: End of every related charge or removal of unrelated test infrastructure

Application acceptance

What to inspect: Required fixture observations and accountable owner's disposition

What it cannot establish alone: Production recovery or permission to move traffic beyond the tested scope

A missing validation observation differs from a recorded failed check. VALIDATING is not a passed result. TIMED_OUT needs investigation of the workflow and its observation window; it does not, by itself, identify an application-data failure. Likewise, a failed restore and an unexercised resource require different next actions.

Retain expected checks separately from actual observations. An application owner can reject a known mismatch or hold acceptance for missing evidence while still recording that the restore job completed.

Find the checks behind a reported validation success

AWS supports optional event-driven validation after a restore job completes. The team's workflow determines what is checked and reports a result. Inspect the implementation revision, event/job binding, target identity, logs and fixtures. AWS's validation example leaves the actual validation logic as a TODO. A sample success assignment is not a usable acceptance test.

The validation-result API accepts independent self-run results. Read ValidationStatus through DescribeRestoreJob alongside the validation evidence. It records the reported result, not an AWS judgement that every business requirement passed. PutRestoreValidationResult itself returns an empty HTTP 204 response. This guide supplies no command to write or revise that status.

For a bounded read function, the owner might require an exact synthetic record under the intended application identity and rejection of an excluded identity. A health endpoint can answer a different question. Define those checks before interpreting the report, not after finding that the existing validator does less.

Preserve a validation result's original scope even if a later investigation finds a gap. Add a separately identified evidence/disposition record. Do not rewrite the history as though the earlier workflow had performed the later checks.

Collect an existing run through approved read paths

Use AWS CLI v2 only with an explicitly authorized read profile, confirmed account and Region, and exact plan, selection and job identities supplied by the owner. Replace every placeholder. The following documented examples were not run in an AWS account.

aws backup get-restore-testing-plan --restore-testing-plan-name APPROVED_PLAN --profile APPROVED_READ_PROFILE --region APPROVED_REGION --no-cli-pager

aws backup get-restore-testing-selection --restore-testing-plan-name APPROVED_PLAN --restore-testing-selection-name APPROVED_SELECTION --profile APPROVED_READ_PROFILE --region APPROVED_REGION --no-cli-pager

aws backup describe-restore-job --restore-job-id APPROVED_JOB_ID --profile APPROVED_READ_PROFILE --region APPROVED_REGION --no-cli-pager

aws backup get-restore-job-metadata --restore-job-id APPROVED_JOB_ID --profile APPROVED_READ_PROFILE --region APPROVED_REGION --no-cli-pager

Command references: plan, selection, job and job metadata. These reads do not prove application access, fixture correctness or absence of other resources.

The AWS Backup authorization reference lists the corresponding read actions. Have the policy owner constrain the approved scope using the mechanisms the action supports. This is not a complete IAM policy. An access-denied response is not permission to switch to a broader identity.

Store raw evidence in the customer's approved restricted location. Retain its capture time and source revision. Compare current plan settings with the configuration applicable to the historical run; a changed plan cannot silently explain an earlier job. If an owner supplies a broader job inventory, preserve pagination and filter coverage instead of assuming one returned page is complete.

Worked scenario: completed restore, incomplete application evidence

The following worksheets form a constructed evidence record. Its aliases are not AWS identifiers, its statements are stipulated and its custom fields are not an AWS API schema. No instance, endpoint or customer data was inspected.

Assume plan PLAN-A selects one EC2 fixture resource APP-A. The actual exercise account and Region have been stipulated eligible and authorized for the example, without identifying a real environment. The application contract requires reading fixture revision F2 through its intended identity and rejecting an excluded identity. Production destinations are stipulated disconnected.

CONFIG-A is stipulated to retain the plan-r1 and selection-r3 settings applicable from 00:00 UTC on 16 October through, but not including, 00:00 UTC on 18 October 2026, covering this run. These are owner-recorded revision aliases and an applicability interval, not AWS-native immutable version fields. Without that historical record, the configuration binding would remain a gap even if today's settings matched. All sample times use one stipulated aligned UTC clock; real evidence must establish its own event sources, capture times and clock uncertainty.

Identity and selection worksheet

Record kind: constructed-teaching-record. Real AWS execution: false. The scope is one EC2 fixture resource, APP-A.

Plan and revision

Stipulated value: PLAN-A; plan-r1

Selection and revision

Stipulated value: EC2-SELECTION-A; selection-r3

Historical configuration record

Stipulated value: CONFIG-A; stipulated owner-retained historical settings

Configuration applies from

Stipulated value: 2026-10-16T00:00:00Z

Configuration applies until, exclusive

Stipulated value: 2026-10-18T00:00:00Z

Point selection algorithm

Stipulated value: RANDOM_WITHIN_WINDOW

Selection window

Stipulated value: 7 days

Point type and vault

Stipulated value: SNAPSHOT; VAULT-A

Latest-point tag

Stipulated value: exercise-selected

Chosen point and application revision

Stipulated value: POINT-OLDER; F1

Configured validation allowance

Stipulated value: 2 hours

Intended, job and actual-target worksheet

Metadata record META-A binds the requested settings, JOB-A metadata and actual created target EC2-TEST-A. Matching placement does not replace the separate isolation assumption.

Requested

Subnet alias: ISOLATED-SUBNET-A

Security-group alias: TEST-SG-A

JOB-A

Subnet alias: ISOLATED-SUBNET-A

Security-group alias: TEST-SG-A

Actual target EC2-TEST-A

Subnet alias: ISOLATED-SUBNET-A

Security-group alias: TEST-SG-A

Instance profile alias: UNKNOWN (null). Isolation record: ISOLATION-A: production paths stipulated disconnected.

Chronological event and observation worksheet

Every timestamp below is stipulated UTC on 17 October 2026. Event times and later observations remain distinct.

2026-10-17T10:00:00Z

Kind: Event

Bound event or observation: JOB-A created

2026-10-17T10:18:00Z

Kind: Event

Bound event or observation: JOB-A restore completed

2026-10-17T10:20:00Z

Kind: Observation

Bound event or observation: JOB-A restore Status: COMPLETED

2026-10-17T10:21:00Z

Kind: Event

Bound event or observation: Health check completed against EC2-TEST-A

2026-10-17T10:22:00Z

Kind: Report

Bound event or observation: Successful result reported for JOB-A

2026-10-17T10:23:00Z

Kind: Observation

Bound event or observation: JOB-A ValidationStatus: SUCCESSFUL

2026-10-17T10:24:00Z

Kind: Observation

Bound event or observation: JOB-A DeletionStatus: DELETING

2026-10-17T10:25:00Z

Kind: Review

Bound event or observation: This record reviewed

2026-10-17T10:25:00Z

Kind: Disposition

Bound event or observation: Owner dispositions recorded

Validation-window start: UNKNOWN (null). Validation-window end: UNKNOWN (null). Cleanup completion time: UNKNOWN (null). These missing timestamps are not failed events or a promise of continued target availability.

Required and performed checks worksheet

Validator revision health-only-v1 targeted EC2-TEST-A. Its evidence record is VALIDATION-LOG-A. The application contract remains F2 under the intended identity, plus rejection of the excluded identity.

Health endpoint

Recorded evidence: Performed: health endpoint returned the stipulated response

F2 application read

Recorded evidence: Not performed

Excluded identity rejection

Recorded evidence: Not performed

Owner-disposition worksheet

These dispositions were recorded at 2026-10-17T10:25:00Z. They are owner decisions, not additional AWS status fields.

Point contract

Recorded disposition: FAILED_REVISION_REQUIREMENT

Application acceptance

Recorded disposition: HELD

Reason

Recorded disposition: required application checks unperformed; selected F1 point does not establish F2

Cleanup closure

Recorded disposition: OPEN

Billing closure

Recorded disposition: UNVERIFIED

Next owner

Recorded disposition: application owner and test-resource owner

Read the record in order. The plan selected APP-A, and JOB-A is stipulated to have created EC2-TEST-A. META-A records agreement between requested, job and target subnet/security-group aliases. ISOLATION-A separately stipulates the disconnected production paths; matching metadata alone would not prove that boundary. The restore completed. The reported validation refers to that target, but checked only health. It did not inspect the required fixture or excluded identity. Application acceptance is therefore held for missing evidence; those unperformed checks are not recorded failures.

The selected point contains F1 while the contract requires F2. That point fails the stated revision requirement; the application function remains untested. Keep the known mismatch separate from the unperformed checks. A qualifying latest-point tag did not establish the older point's suitability, and a successful health response cannot resolve it. The application owner must reject this point for the current requirement or separately authorize and evidence a changed requirement.

The timestamp fields distinguish events from observations. The restore completion at 10:18 is an event time; COMPLETED was observed at 10:20. VALIDATION-LOG-A stipulates a health check completed at 10:21 and a successful result reported at 10:22; the job's validation status was observed at 10:23. DELETING was observed at 10:24, not established to have begun then. These custom UTC fields collect different evidence sources. DescribeRestoreJob provides a restore CompletionDate but does not supply these validation-report or deletion-observation timestamps.

At the 10:25 review, seven minutes have elapsed since restore completion and three since the stipulated validation report. Those are sample clock differences, not measured AWS durations or proof of additional checks. The two-hour setting is a configured allowance, not two hours remaining at review. AWS describes retention after a restore test and cleanup on validation completion or retention expiry, whichever comes first. The cited definitions do not establish an exact service window-start timestamp for this record. Its start and end therefore remain null, meaning unknown, rather than deriving a 12:18 expiry or 113 minutes of remaining availability from CompletionDate.

DELETING at 10:24 is consistent with cleanup after early validation completion; the observed ordering does not prove the trigger or when deletion started. AWS's cleanup description separates initiation from resource-dependent removal. Cleanup remains open because DELETING is not completed removal; no exact completion deadline follows. Billing remains unverified independently, and early cleanup does not convert the health-only report into application acceptance.

Now change one assumption: suppose no point meets the same resource's selection criteria. There may be no corresponding restore job. Record APP-A as unexercised and investigate eligibility; do not invent a FAILED job or treat an empty job list as successful coverage. This is an alternative constructed branch, not a second tested resource.

Constructed teaching record, not AWS execution. The arrow retains evidence outside the temporary target. Point failure, unperformed checks, held acceptance, cleanup and billing remain separate decisions.

Constructed teaching record, not AWS execution. The arrow retains evidence outside the temporary target. Point failure, unperformed checks, held acceptance, cleanup and billing remain separate decisions.

Constructed teaching record, not an AWS response or executed recovery test. APP-A requires fixture revision F2 under the intended identity and rejection of an excluded identity. The selected POINT-OLDER contains F1. JOB-A creates temporary target EC2-TEST-A; the source, point, job, target and validator observations remain bound by their exact identities in the durable record. The example stipulates disconnected production paths separately from matching metadata.

All times are stipulated aligned UTC on 17 October 2026. Restore completion is an event at 10:18; Status COMPLETED is observed at 10:20. The health-only check completes at 10:21, its successful result is reported at 10:22 and ValidationStatus SUCCESSFUL is observed at 10:23. That report covers only health, not the required application read or excluded-identity rejection. DeletionStatus DELETING is observed at 10:24. This is neither the deletion start time nor completed removal.

At the 10:25 owner review, the point contract fails because F1 does not meet F2. Required application checks remain unperformed, not observed failures, so acceptance is held. Cleanup remains open, and billing closure is independently unverified. Preserve approved identities, configuration references, logs and actual checks outside the temporary target before depending on later access to it. A deletion status does not establish that every related charge has ended.

CONFIG-A stipulates plan-r1 and selection-r3 applying from 00:00 UTC on 16 October through, but excluding, 00:00 UTC on 18 October 2026. These are retained owner aliases, not AWS-native immutable revision fields. The configured two-hour validation allowance is not two hours remaining at review. Exact service window start, window end and cleanup completion remain unknown in this record. Neither an exact expiry nor remaining target availability can be calculated from the restore completion timestamp. In the alternative branch, no recovery point meets the same APP-A selection criteria. APP-A is unexercised, and there may be no restore job; do not invent a failed job or successful population coverage.

Preserve evidence before the temporary target disappears

The validation allowance is finite. The selection definition exposes ValidationWindowHours; it is not a general recovery-time objective or permanent retention policy.

Export approved logs, configuration references, identities and fixture results into the durable evidence location before relying on later access to the temporary target. Do not put secret values or unnecessary restored data into that record. Evidence retention and restored-resource retention are different decisions.

AWS describes cleanup after validation or the window closes, with resource-dependent deletion behavior. Do not remove restore-test tags to keep a target alive. A cleanup failure goes to the resource owner for a separately authorized disposition, with exact scope and preserved messages.

For EC2, account for associated restored artifacts rather than checking only whether the instance is still visible. AWS's EC2 restore documentation identifies AMI, volume and snapshot creation. Assign each observed remaining artifact a disposition; do not presume every related resource is either retained or deleted.

Financial closure needs its own usage/invoice evidence and owner. Ongoing storage, external validation infrastructure and retained evidence can have separate costs. This guide provides no price, zero-charge assertion or universal billing delay. A cleanup status supports only the resource scope it actually describes.

Choose and own the next evidence task

Use managed periodic restore testing when its selection and lifecycle are suitable for the intended recurring infrastructure evidence. An explicitly owned on-demand drill can answer additional application questions with a different scope and cost. Reviewing existing run records is the safer first step when authorization, data handling or cleanup is unresolved.

If new observations are necessary, commission a separate isolated exercise. Require approved synthetic or sanitized data, scoped identities, inert/non-delivering receivers, disconnected production integrations, spending/time limits, an independent stop path and a cleanup owner. No fault, restore or application mutation is authorized by this article. Stop further test activity on identity drift, unexpected production reachability, escaped effects, lost observation or an exceeded approved boundary.

Use this short record for the next review:

Population and selection

Required entry: Expected resource, exclusions, applicable plan/selection revision and unexercised reason

Run binding

Required entry: Actual point, job, created target and effective metadata evidence

Authority and isolation

Required entry: Approved reader, restore/validator/application identities, key and network references

Validation meaning

Required entry: Required versus performed checks, exact target, workflow revision and logs

Decision

Required entry: Restore, application and untested-boundary dispositions with named owners

Closure

Required entry: Deletion/readback, remaining artifacts, cost follow-up and evidence-retention owner

Reopen the affected entries when selection, target settings, application requirements, validator revision or authority changes. Do not inherit yesterday's application acceptance through an unreviewed change.

For destination-account authority, use the cross-account EFS restore playbook. For broader acceptance and external effects, use the recovery evidence paper. Those resources own deeper exercises; this run record owns the meaning of the managed test evidence.

Bring one completed record to the platform and application owners. Ask which exact required observation is still missing, which result is known to fail, and who owns the remaining temporary resources. Resolve that item before describing the application as recovered.