# Automated database backups scheduled and tested; retention at least 7 days; restore procedure verified

- **Pattern:** `ab-000980` (`deployment-readiness.rollback-recovery.database-backups`)
- **Severity:** medium
- **Lifecycle:** active
- **Last modified:** 2026-04-18
- **Canonical URL:** https://auditbuffet.com/patterns/ab-000980
- **License:** CC-BY-4.0 — attribute to AuditBuffet Pattern Catalog (https://auditbuffet.com/patterns/ab-000980)

## Why it matters

Without automated database backups with at least 7-day retention, a corrupted migration, accidental `DELETE` without a `WHERE` clause, or infrastructure failure can result in permanent data loss. SOC 2 A1.2 and NIST CP-9 require backup and recovery capabilities and periodic restore testing. ISO 25010 reliability.recoverability cannot be satisfied by a backup that has never been successfully restored — untested backups have an unknown failure rate.

## Severity rationale

Medium because automated backups address a catastrophic but infrequent failure mode; the risk is bounded by the fact that most deployments don't corrupt data, but when they do the impact is irreversible.

## Remediation

Enable automated backups with at least 7-day retention. For AWS RDS via Terraform:

```hcl
resource "aws_db_instance" "main" {
  identifier             = "my-app-db"
  backup_retention_period = 7          # minimum; 14-30 days recommended
  backup_window          = "03:00-04:00"  # off-peak UTC
  # ... other config
}
```

Document the restore procedure in `DEPLOYMENT.md`:

```markdown
## Database Restore
1. AWS Console → RDS → Automated backups → select snapshot
2. Click "Restore to new DB instance"
3. Configure new instance (same instance class as primary)
4. Update DATABASE_URL env var to point to restored instance
5. Promote to primary after validating data integrity
```

Schedule a quarterly restore test to a throwaway instance to confirm the backup is actually restorable.

## Detection

- **ID:** `database-backups`
- **Severity:** `medium`
- **What to look for:** Enumerate every relevant item. Look for database backup configuration in infrastructure code (terraform, CloudFormation), cloud console setup (AWS RDS automated backups, Azure SQL, Google Cloud SQL), or third-party backup service (Backblaze, Veeam). Check for backup retention policy (at least 7 days). Look for evidence of restore testing in documentation or incident logs.
- **Pass criteria:** Automated database backups are enabled and scheduled. Backup retention is at least 7 days. Evidence exists of a successful restore test within the last 3 months.
- **Fail criteria:** No automated backups configured, or backups exist but retention is less than 7 days, or no restore testing has been done.
- **Skip (N/A) when:** The project has no database, or data is fully ephemeral and loss is acceptable.
- **Detail on fail:** `"No database backup configuration found."` or `"AWS RDS automated backups enabled but retention is only 3 days (below 7 day minimum)."` or `"Backups configured but no evidence of restore testing."`
- **Remediation:** Configure automated backups. For AWS RDS:

  1. In AWS Console → RDS → Databases → Modify your DB instance
  2. Set "Backup retention period" to 7 days (or longer)
  3. Set "Preferred backup window" to off-peak hours
  4. Save changes

  Or with Terraform:

  ```hcl
  resource "aws_db_instance" "main" {
    allocated_storage = 20
    backup_retention_period = 7
    # ... other config
  }
  ```

  Document restore procedure in DEPLOYMENT.md:

  ```markdown
  ## Database Restore
  1. In AWS Console, go to RDS → Automated backups
  2. Select the backup to restore
  3. Click "Restore to new DB instance"
  4. Configure the new instance, then promote to primary
  ```

## External references

- iso-25010 reliability.recoverability
- nist CP-9
- soc2 A1.2

Taxons: data-integrity, operational-readiness

HTML version: https://auditbuffet.com/patterns/ab-000980
