Database backups & disaster recovery

[mondial7]

Today docker compose down -v permanently destroys data and there's no documented restore path.

Scope

• Scheduled mongodump (daily incremental, weekly full) to S3/GCS — sample compose service + cron entry.
• Documented point-in-time recovery using oplog tailing (or doc mongodump --oplog).
• Monthly automated restore test (CI job that pulls latest dump and runs it against a throwaway Mongo).
• Restore runbook in docs/ — exact commands, expected duration, who to page.

Effort: small-medium (1–2 days).

[mondial7]

Note after #54: the datastore is now PostgreSQL, so this is pg_dump (not mongodump). The deployment guide already recommends a scheduled off-host pg_dump; automating it is still open.

[mondial7]

Addressed by #61: scripts/backup.sh + scripts/restore.sh, a make backup target, and a Backups & DR section in the deployment guide (nightly cron, Docker variant, restore drill). Validated end-to-end against Postgres. Scheduling/offsite copy remains a per-deployment concern, documented in the guide.