git:20260728.b7e78fc to git:20260804.5567c51

---

name: "Restore-Test Verification"

description: >

Whether a backup is actually recoverable rather than merely present: the

ranked hierarchy of restore evidence (actual restore performed, full

boot/virtualization verification, screenshot verification, spot-check

restore drill, no evidence at all), adequate test cadence per

data-criticality tier, and why a never-tested backup is the

highest-priority finding — outranking even an actively failing job.

when_to_use: >-

When determining whether a backup is actually recoverable, not just present

— tracking restore/DR test history, screenshot or boot-verification status,

and testing cadence adequacy. Use when: restore test, DR test, can we

actually restore this, backup verification, has this ever been restored,

restore drill, boot verification, screenshot verification, untested

backups.

---

# Restore-Test Verification

## Overview

A backup job reporting "success" proves that data was copied somewhere. It proves

nothing about whether that data can be turned back into a working system or a usable

file when someone actually needs it. Corruption, encryption-key problems, application-

consistency failures, and format incompatibilities routinely surface only at restore

time — never during the backup run itself. The gap between "backed up" and

"recoverable" is where most DR failures actually happen, and it is invisible from a

job-success dashboard. This skill exists to make that gap visible: tracking what

restore-test evidence actually exists per protected system, and flagging where it

doesn't.

This skill assumes backup jobs are already running (see `backup-job-health` for that

layer) and asks the next question: if this needed to be restored today, is there any

evidence it actually could be?

## Key Concepts

### "Exists" vs. "recoverable" evidence, ranked

Not all restore evidence is equally strong. From strongest to weakest:

1. **Actual restore performed** — a real recovery event (production failover, file

recovery request, or a deliberate DR drill) where the data was genuinely restored

and validated. Strongest possible evidence; also the rarest.

2. **Full boot/virtualization verification** — the protected system was virtualized

from its backup image and confirmed to boot and respond (some BCDR appliances,

e.g. Datto BCDR, run this automatically). Strong evidence for image-based

appliance backups — it proves the image is bootable, though it doesn't fully

validate application-level data integrity inside the guest.

3. **Screenshot verification** — an automated screenshot of the virtualized boot

screen, confirming the OS reached a login prompt or desktop rather than a boot

error. Weaker than full boot verification but far stronger than nothing — it's

the closest-to-continuous proxy most appliance vendors offer. Treat a "successful

backup" with a *failed* screenshot verification as a recovery risk, not a pass —

see `backup-job-health` for the point that both signals must be checked together.

4. **Spot-check restore drill** — a manual, periodic restore of a sample file,

mailbox, or object to confirm data integrity, without a full system failover. This

is the primary evidence type available for SaaS-data snapshot backups (Datto SaaS

Protection, Spanning), which generally don't offer a "boot" concept at all — a

spot-check restore of a mailbox or SharePoint file is the equivalent verification

action.

5. **No test evidence at all** — a backup with a clean job-success history and no

restore, boot-verification, screenshot, or spot-check record of any kind. Treat

this explicitly as **untested**, not merely "unverified" — it should be reported

as a finding in its own right, not omitted because nothing failed.

Never let a long streak of successful backup *jobs* stand in for restore evidence.

They answer different questions.

### Adequate testing cadence by data-criticality tier

There is no universal "right" cadence — it should scale with how critical the

protected system is to the client's operations. In the absence of an org-documented

policy, apply these as defaults and state explicitly that they're defaults:

| Criticality tier | Example systems | Suggested minimum test cadence |

|---|---|---|

| Tier 1 — mission-critical | Line-of-business database/ERP, domain controllers, production file servers | Quarterly full or partial restore drill; continuous screenshot/boot verification where the vendor supports it |

| Tier 2 — important | Departmental servers, secondary application servers | Semi-annual restore drill |

| Tier 3 — standard | Workstations, non-critical file shares | Annual restore drill, or continuous screenshot verification alone if the vendor offers it and no drill has occurred |

| SaaS mailboxes/files (Datto SaaS Protection, Spanning) | M365/Google Workspace/Salesforce data | Semi-annual spot-check restore of a sample of mailboxes/files per protected tenant |

Where the org has documented its own required cadence (e.g., in a connected

documentation platform or contract), use that instead and say so.

### Flagging never-tested backups

A backup that has never been restore-tested by any of the evidence types above,

regardless of job-success history or how long it's been running, is the single

highest-priority finding this skill produces. Rank never-tested Tier 1 systems above

everything else, including active job failures caught by `backup-job-health` — a

currently-failing job is at least a known, visible problem; a never-tested backup is

an unknown one that looks fine until the moment it matters most.

### If no backup/BCDR tool is connected

State plainly that restore-test verification cannot run: "No backup or BCDR connector

is connected through the gateway, so there's no restore-test history to check."

Do not fabricate test dates or pass/fail status.

## Common Workflows

### Portfolio-wide untested-backup sweep

1. Discover connected backup/BCDR tools via `conduit__search_tools`.

2. For each protected unit, pull the strongest available restore-evidence type (per

the ranking above) and its most recent date.

3. Classify against the criticality-tiered cadence table: current, due, overdue, or

never-tested.

4. Report never-tested Tier 1 systems first, then overdue Tier 1, then the rest in

descending criticality/staleness order.

### Single-client restore-readiness check

1. Resolve the client to its protected units across connected tools.

2. Pull restore-evidence history for each unit.

3. Report per-unit status against the applicable cadence, with a recommended next

test date.

## Error Handling

- **No backup/BCDR connector connected:** stop and say so; do not fabricate restore

history.

- **A connector doesn't expose restore/screenshot history via its API:** report job

health normally (per `backup-job-health`) and mark restore-test status "unable to

verify — connector does not expose restore-test history" rather than assuming

untested or omitting the system from the report.

- **Criticality tier unknown for a given system:** state that the default (Tier 2)

cadence was applied pending a documented criticality classification, rather than

guessing a tier silently.

## Best Practices

- Recommend, don't schedule or execute, an actual restore drill — this skill flags

the gap; performing the drill is a human/scheduled action with its own change-

control considerations.

## Related Skills

- [Backup Job Health](../backup-job-health/SKILL.md) — confirms jobs are running at

all; this skill assumes that and asks whether the result is recoverable.

- [Retention/RPO Compliance](../retention-rpo-compliance/SKILL.md) — a recoverable

backup that doesn't retain far enough back, or isn't frequent enough to meet an

RPO target, is still a compliance gap even when restore-tested successfully.