60 lines
3.5 KiB
Markdown
60 lines
3.5 KiB
Markdown
# 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.
|