backup-disaster-recoverylisted

# Backups & Disaster Recovery The line that defines a backup strategy: **"a backup you have not restored is a wish, not a backup."** Most teams have something called "backups" that have never been restored end-to-end. Sometimes they don't actually work; sometimes they work but are too slow; sometimes they work but the team forgot a critical piece of state and ends up with a half-restored system. This skill builds a strategy that survives the first real incident — not the strategy that looks good in a slide deck. Pairs with [`incident-response`](../incident-response/SKILL.md) (where backups get used) and [`postgres-hardening`](../postgres-hardening/SKILL.md) / [`backend-architecture`](../backend-architecture/SKILL.md) (where the data lives). ## When to invoke - "We have backups but nobody has ever restored them" - Adding a new system that holds production data - After a near-miss (almost lost data) or an actual data-loss incident - Before a major migration, version upgrade, or refactor that touches storage - Ransomware attack in the news that affects your stack (always periodic, treat as a prompt) - Periodic re-audit (quarterly is reasonable) ## Step 1 — Define what you're protecting against The right strategy depends on the failure class. Backups for ransomware look different from backups for "developer dropped the table accidentally." | Failure class | What you need | |---|---| | Hardware failure (disk, server) | Replica or snapshot in a different physical location |