restore-test-verificationlisted

# 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? ## Anti-triggers - **Fetching a screenshot or boot-verification record** — the screenshot, activity, and asset endpoints are the appliance's own API surface; use `datto-bcdr-api-patterns`. This skill weighs what that evidence proves and flags where none exists. - **Answering "are backups tested?" on an insurance or audit form** — the evidence-labelling discipline for that context lives in `insurance-questionnaires` (compliance-pack), which draws on this skill's finding rather than reproducing it. ## Key Concepts ### "Exists" vs. "recoverable" evidence, ranked Not