igny8/master-docs/50-infra/BACKUP-AND-RECOVERY.md

Backup and Recovery

Purpose

Describe what needs backup and how to restore based on the runtime components present (Postgres DB, Redis, logs, sites data). No automated backup scripts are versioned here; guidance is derived from files in the repo.

Code Locations (exact paths)

• Database defaults: backend/igny8_core/settings.py (Postgres/SQLite selection via env)
• Compose mounts: docker-compose.app.yml (backend logs volume, sites data mounts)
• Example DB dumps present: backend/backup_postgres_20251120_232816.sql, backend/db_backup_20251120_232646.sqlite3

High-Level Responsibilities

• Preserve database state (Postgres primary target).
• Preserve published sites data (/data/app/sites-data) consumed by sites renderer.
• Preserve application logs for audit/debug.

Detailed Behavior

• Primary datastore: Postgres (preferred). settings.py falls back to SQLite only in DEBUG/no-env scenarios; production should use Postgres to enable reliable backups.
• Redis: used as Celery broker/result backend; not a system of record—no backups required beyond availability.
• Files to keep:
  • Postgres DB: dump regularly (e.g., pg_dump); sample dumps in backend/ illustrate format.
  • Sites data: mounted read-only into sites renderer from /data/app/sites-data; back up that directory to retain deployed static sites.
  • Logs: stored under /data/app/logs and backend/logs/publish-sync-logs; optional for troubleshooting.
• Static assets: backend/staticfiles can be regenerated via collectstatic; not required to back up if build pipeline exists.

Data Structures / Models Involved (no code)

• All Django models persist in Postgres; automation logs/files live in logs/ directory.

Execution Flow (Suggested)

• Postgres backup: pg_dump -Fc -h <db_host> -U <user> <db_name> > igny8_<date>.dump
• Sites data backup: archive /data/app/sites-data (and any uploads stored under /data/app/igny8/sites if used).
• Logs backup: optional tar of /data/app/logs and backend/logs/publish-sync-logs.
• Restore Postgres: pg_restore -c -d <db_name> -h <db_host> -U <user> igny8_<date>.dump (ensure DB created and app stopped before restore).

Cross-Module Interactions

• Billing, tenancy, automation data all live in the DB; restoring DB restores these states.
• Sites renderer consumes /data/app/sites-data; ensure it matches DB state if site URLs/records reference deployed assets.

State Transitions (if applicable)

• After restore, run python manage.py migrate to align schema, then restart backend/worker/beat.

Error Handling

• Backups should be verified via pg_restore --list or test restores; failed restores will surface at DB connection time.

Tenancy Rules

• Restoring DB restores tenant isolation; ensure backups are tenant-wide and protected.

Billing Rules (if applicable)

• Billing data (credits, invoices, payments) is DB-resident; backups must be handled securely due to financial data sensitivity.

Background Tasks / Schedulers (if applicable)

• Stop Celery beat/worker during restore to avoid tasks running on partial data.

Key Design Considerations

• Use Postgres in all non-local environments to avoid SQLite backups.
• Keep DB credentials and dumps secure; avoid storing secrets in dumps.

How Developers Should Work With This Module

• Add automated backup scripts (cron/Portainer stacks) external to this repo; document their paths and retention when added.
• Remove legacy .sql dumps from repo in production to avoid stale data exposure; rely on managed backups instead.