Backup and restore validation

Checks whether backups can restore a usable system within stated data-loss and recovery-time objectives.

backup-restore-validation

Team members using this skill

AgentOtto

See how it helps

When is it useful?

Use when backup jobs appear successful but recovery has never been demonstrated.

What does it help you do?

Inventories databases, files, configuration and required decryption access.
Plans isolated restore exercises disconnected from production messages and effects.
Checks restored schema, representative data and measured recovery time.

Try asking this

Prepare a restore drill for our database and uploads in an isolated environment, showing integrity checks and remaining coverage gaps. Open a restored order and its attachment, then compare counts and checksums. Record the achieved recovery point and elapsed restoration time.

Detailed documentation

Read the skill’s original instructions, examples and checks in their authored language.

Details…Show less

Backup & Restore Validation

An untested backup is only a wish. Reliability is measured not by whether a backup cron job exited 0, but by RPO (Recovery Point Objective: how much data can be lost) and RTO (Recovery Time Objective: how quickly a verified system can be restored).

Complete Backup Coverage & Isolation

Inventory every stateful store:
- Primary relational/document databases (Postgres, MySQL, SQLite, MongoDB).
- Object storage buckets (user uploads, generated artifacts, invoices).
- Configuration state, KMS/encryption key access, and infrastructure state files.
Follow the 3-2-1 & Blast-Radius Isolation Principle:
- Store encrypted backups in a separate storage bucket/region or isolated account with immutable retention / Object Lock (WORM) so a compromised application credential or accidental terraform destroy cannot delete both the live database and its backups.
- Verify that the encryption keys required to decrypt backups are not stored exclusively inside the system being backed up.
Automated retention & lifecycle policies:
- Define explicit retention tiers (e.g., continuous WAL / PITR for 7–35 days, daily snapshots for 30 days, monthly snapshots for 1 year) and monitor backup job completion, age of latest snapshot, and backup size anomalies (e.g., a backup suddenly shrinking to 0 KB).

Restore Verification Protocol (Never Test on Live Production!)

Never claim backup recovery works based solely on backup job logs:

Verification Check	How to Execute Safely
1. Integrity & Non-Empty Check	Verify checksum, snapshot status, and non-zero size immediately after backup creation.
2. Isolated Restore Drill	Provision a disposable, network-isolated staging/verification database instance (never pointing to production queues, webhooks, or email senders!) and restore the latest snapshot or PITR timestamp into it.
3. Schema & Data Sanity Check	Connect the application or verification script to the restored instance; verify migration table state, row counts on core tables, foreign-key integrity, and recent timestamp bounds.
4. Measure & Document	Record the exact commands run, wall-clock duration from start of restore to healthy query response (measured RTO), latest recoverable transaction timestamp (measured RPO), and any manual steps discovered.

Pre-Migration & Pre-Release Safety Snapshots

Before executing any high-risk data migration, bulk backfill, or major version upgrade, trigger or verify a fresh on-demand snapshot and record its identifier in the release checklist.

Included files 1

SKILL.md