What it does
Checks that a backup archive is complete and not truncated, confirms both the database export and the file archive were captured together (not just one half), and where a spare environment is available, walks through an actual test restore to confirm the site comes up cleanly rather than just trusting the backup log.
Install
This skill isn't packaged in an installable registry. It's a plain SKILL.md file you can copy directly. Copy it from the SKILL.md tab and save it at the path for your assistant:
Use it in your AI assistant
Claude Code
.claude/skills/backup-verification-checker/ (or ~/.claude/skills/backup-verification-checker/ for all projects)
GitHub Copilot (VS Code)
.github/skills/backup-verification-checker/
OpenAI Codex
.codex/skills/backup-verification-checker/
Cursor
.cursor/skills/backup-verification-checker/ (or ~/.cursor/skills/backup-verification-checker/ globally)
Compatibility
Any WordPress site with an existing backup solution (plugin or host-level); a spare staging environment is needed to run a true restore test.
The complete SKILL.md for this skill:
---
name: backup-verification-checker
description: Use when a user wants to confirm a backup actually works, asks "can I restore from this", or hasn't tested a restore since setting up automated backups.
---
# Backup Verification Checker
## When to use
Backups are running on a schedule but nobody has confirmed they can actually be restored, and the user wants that confirmed before they need it in an emergency.
## Procedure
1. Confirm the backup includes both a database export and the wp-content files (uploads, themes, plugins), not just one of the two.
2. Check the archive isn't truncated or corrupted by verifying file size against prior successful backups and, where possible, testing that the archive opens/extracts cleanly.
3. Confirm the backup's timestamp and scope match what the user expects (full site vs. database-only, and how far back it goes).
4. If a spare staging environment or sandbox is available, perform an actual restore into it and confirm the site loads, logs in, and key pages render, rather than assuming success from a backup completion log.
5. Note the backup's age and how much data would be lost if restored right now, so the user knows their actual recovery point.
6. Report clearly: verified restorable, restorable with caveats, or could not be verified, with the specific reason.
## Guardrails
- Never perform a test restore against the live production site; it must go to a disposable staging environment or sandbox only.
- Do not report a backup as "verified good" from its existence or file size alone if no actual restore test was possible, say plainly that verification was only partial.