Backup Strategy

---
name: backup-strategy
description: |
  Trigger when the user asks about backup strategy, disaster recovery, RPO/RTO,
  or restoring from backup. Phrases: "backup strategy", "disaster recovery",
  "RPO", "RTO", "restore test", "point-in-time recovery".
allowed-tools:
  - Read
  - Write
---

# Backup Strategy

Design a backup and restore plan that actually works. Covers the 3-2-1
rule, test restores, and the RTO/RPO decisions that drive cost.

## Prerequisites

- Critical data identified (databases, user uploads, config)
- Downtime tolerance discussed with stakeholders

## Steps

1. **Define RTO and RPO first.** Everything flows from these:
   - **RTO** (Recovery Time Objective) - max acceptable downtime
   - **RPO** (Recovery Point Objective) - max acceptable data loss window

   RTO of 4 hours means you need a restore path that completes in 4 hours.
   RPO of 5 minutes means backups at least every 5 minutes, typically
   continuous replication.

2. **3-2-1 rule as the baseline:**
   - **3** copies of your data
   - **2** on different storage media
   - **1** offsite (different cloud region at minimum)

   For a production web app: primary DB, RDS automated snapshots in-region,
   and snapshot export to S3 in a second region.

3. **Backup classes:**
   - **Databases** - use the provider's point-in-time recovery (PITR).
     RDS: automated backups + PITR to any second. DynamoDB: continuous backups.
   - **User uploads** - S3 versioning + cross-region replication.
   - **Config and secrets** - Secrets Manager and Parameter Store both
     keep version history. Back up the IaC that defines them.

4. **Test restores quarterly.** An untested backup is not a backup. Pick
   a random backup and restore it to a staging environment. Time the
   restore. If it takes longer than your RTO, the strategy is broken.

5. **Document the restore runbook:**
   - Which backup to use for which scenario
   - Exact commands to run
   - Who has the credentials
   - Expected time to each milestone

   Run the runbook on the scheduled test. If the person on call can't
   follow it, it's not a runbook.

6. **Protect against your own mistakes.** Most data-loss incidents aren't
   hardware failure; they're accidental DELETE statements. Enable:
   - Database audit logs
   - S3 bucket versioning + MFA delete
   - IAM policies that require MFA for destructive actions

## Common failures

- Backups run daily; RPO is 5 minutes. Math doesn't work.
- Restore tested once, a year ago. When you need it, it doesn't work.
- Backups in the same region as primary. Regional outage loses both.
- No audit trail on who ran DROP TABLE.

## Output

- RTO and RPO documented and agreed
- Backup schedule wired
- Restore runbook written
- First test restore completed and timed