backups

# Backups & disaster recovery ## Start here One question decides whether you have backups or a hope: **if you restored right now, would it work — and how do you know?** If the answer is "we have a nightly job and it hasn't errored," you do not have backups. You have a job. A backup you have never restored is an untested assertion about the future. This skill exists to turn that assertion into evidence: pick the numbers, lay out the copies so ransomware can't reach them, and run a *real* restore on a schedule so the answer becomes "yes, we restored it last Tuesday in 41 minutes." This is the cross-engine **strategy + verification** skill. Engine-specific SQL knobs (the actual `archive_command`, VACUUM, schema migrations) belong to `../postgresdb/SKILL.md`. Encryption-key management as a general security control belongs to `../secure-coding/SKILL.md`. ## 1. Decide RPO and RTO first — numbers, not adjectives Everything downstream derives from two numbers. Never start from "what does the tool do." - **RPO** = maximum acceptable *data loss*, the gap between the disaster and your last good copy. It sets **backup frequency**. "RPO 1 hour" means a copy at least hourly. - **RTO** = maximum acceptable *downtime* until you're serving again. It sets **topology**: a snapshot restore is hours; a warm standby you promote is minutes. Get a real number from whoever owns the revenue, not "as little as possible." Then map it: | RPO target | Required cadence + mechanism | |---|---| | 24...