restore-test-verification

name	Restore-Test Verification
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.
description	Use this skill to track and verify whether backups are recoverable rather than merely present: the difference between "a backup exists" and "a backup is recoverable," how to use screenshot/boot-verification features and spot-check restore drills as evidence, what counts as an adequate testing cadence for different data-criticality tiers, and how to flag backups that have never been restore-tested.

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

• Treat "never tested" as a first-class, always-reported finding — not a null value that gets dropped from output.
• Always check screenshot/boot-verification status alongside job-success status for image-based appliance backups; a green job with a red screenshot is a recovery risk.
• State the cadence table (or the org-specific policy used instead) explicitly in every report — it's a judgment call the reader needs visibility into.
• 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 — confirms jobs are running at all; this skill assumes that and asks whether the result is recoverable.
• Retention/RPO Compliance — 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.