Backup strategy is documented

The most common backup failure mode is not a missing backup — it is discovering that backups exist but no one knows where they are, how long they are retained, or how to use them during an incident at 2 AM. ISO 25010 recoverability requires a defined, documented, and actionable recovery procedure, not just an assumption that the cloud provider is doing something. Managed databases like Supabase Free include only basic backups; teams that assume PITR is included on the free tier discover the gap after the incident. A documented backup strategy converts an implicit assumption into an auditable commitment.

Add a Backup Strategy section to DEPLOYMENT.md covering frequency, retention, location, and access procedure. For Supabase, document the plan tier and PITR availability explicitly.

## Database Backup Strategy

**Platform:** Supabase Pro
**Automatic backups:** Daily snapshots, 7-day retention
**PITR:** Available (last 7 days)
**Access:** Supabase dashboard > Settings > Backups

### Manual backup (before major migrations)
```bash
pg_dump $DATABASE_URL > backup_$(date +%Y%m%d_%H%M%S).sql
aws s3 cp backup_*.sql s3://myapp-backups/

Last restore test: [date — update after each test]

Also verify your platform plan actually includes the backup retention you need — Supabase Free provides basic backups only, not PITR. Upgrade to Pro ($25/month) for daily PITR, Team for per-minute PITR.

• ID: backup-strategy-documented

• Severity: high

• What to look for: List all backup-related documentation across the project. Check: README.md (ops or deployment section), DEPLOYMENT.md, docs/ directory (runbooks, operations guides), infrastructure-as-code files (Terraform, Pulumi) for backup resource definitions, and any CI/CD pipeline steps that perform backups. For managed databases, check whether the project documents the platform's automatic backup schedule and how to access/restore from backups. The documentation should answer: how often backups are taken (frequency), how long backups are retained (retention), where backups are stored (location), who is responsible for backup monitoring, and how to access backups if needed.

• Pass criteria: Backup strategy is documented specifying at least 3 of these 4 items: backup frequency (e.g., daily snapshots, WAL archiving for continuous), retention period (e.g., minimum 7 days), where backups are stored (e.g., S3, managed platform dashboard), and how to access them. Documentation is findable in the project (README, DEPLOYMENT.md, or a runbook).

• Fail criteria: No backup documentation anywhere in the project. No evidence the team has considered or verified the backup strategy. README mentions the database but says nothing about backups.

• Skip (N/A) when: Development-only SQLite database with no production deployment and no data worth protecting.

• Detail on fail: Example: "No backup documentation found in README, DEPLOYMENT.md, or docs/. No evidence the team has confirmed or configured backup strategy for the Supabase production database.".

• Remediation: Document your backup strategy:

  <!-- DEPLOYMENT.md — add a Backup Strategy section -->
  
  ## Database Backup Strategy
  
  **Database:** Supabase PostgreSQL (project: axgbubfqinuhuyjmtebf)
  **Automatic backups:** Supabase Pro provides daily backups with 7-day retention.
  **Backup location:** Supabase dashboard > Settings > Backups
  **At least 1 PITR mechanism is available. Point-in-time recovery:** Available on Pro plan (last 7 days)
  
  ### Accessing Backups
  1. Log into Supabase dashboard at supabase.com
  2. Navigate to Settings > Backups
  3. Download backup file or use PITR to restore to a specific timestamp
  
  ### Manual Backup (run before major migrations)
  ```bash
  pg_dump $DATABASE_URL > backup_$(date +%Y%m%d_%H%M%S).sql
  # Upload to S3: aws s3 cp backup_*.sql s3://myapp-backups/
  

  Backup monitoring: Supabase sends alerts for backup failures to [ops email]. Last restore test: [date] — restore to staging environment, verified data integrity.