Skip to content

Backups & Restore

Local and dev database backup procedures for dichit-backend.

Production backups are handled by the managed AWS RDS policy — see production.md and aws.md.

Local / dev scripts

package.json ships pg_dump/psql helpers that write to backups/:

# Dump the local DB (postgres:16 on localhost:5434, db "app")
pnpm backup:db:local
# => backups/postgres_data_local.sql

# Restore it
pnpm restore:db:local

# Dev DB (localhost:5433, db "dichit_dev")
pnpm backup:db:dev
pnpm restore:db:dev

Both dumps use:

  • --data-only — schema comes from migrations, not the dump.
  • --disable-triggers — avoids constraint ordering issues on restore.
  • --exclude-table-data=public._prisma_migrations — migration history stays authoritative.

Why data-only

Restoring data-only on top of a migrated schema keeps code and migrations in sync and avoids drift. If you need a schema dump (e.g. disaster recovery), create one explicitly:

pg_dump -h localhost -p 5434 -U user -d app --schema-only > backups/schema_local.sql

Restore procedure (local)

# 1. Ensure schema is migrated
pnpm migrate:local:reset --skip-seed   # or migrate:local:up

# 2. Restore data
pnpm restore:db:local

# 3. If the app needs seed references, re-run seed
pnpm seed:local:up

Rules

  • Never commit backups/*.sql that contain real PII/secrets; the dump files are local tooling output.
  • Prefer migrations + seeders over restoring data for reproducible environments.
  • For prod/DR restore, follow the RDS snapshot/point-in-time procedure in production.md.