# 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.