restore-test-verification

# 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). Stro...