Thorsten
fb19795fdb
For moving this project to a new server: git tracks code, not the Postgres data directory, and raw volume/data-dir copying is fragile across Postgres versions or architectures (this repo already hit a collation-version mismatch once from just changing the Postgres image). pg_dump/pg_restore is the portable way to move the actual data instead. scripts/backup-db.sh dumps the running postgres container's database in pg_dump's custom format into ./backups/ (gitignored — dumps contain real user data and don't belong in git history). It reads POSTGRES_USER/POSTGRES_DB from the container's own environment rather than re-parsing .env, so it can't drift out of sync with the actual running config. scripts/restore-db.sh restores a dump into the running container (--clean --if-exists --single-transaction, so a failure rolls back atomically instead of leaving a half-restored database), with a confirmation prompt since it's destructive, skippable via -y. Added .gitattributes forcing LF on *.sh — Windows git would otherwise check these out as CRLF, breaking the bash shebang on the Linux server they're meant to run on. Verified end to end: took a real backup of the live database, restored it back over itself, and confirmed exact row-count matches across every table plus that pgvector similarity search still works on the restored embeddings (not just that the bytes round-tripped). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
19 lines
186 B
Plaintext
19 lines
186 B
Plaintext
.env
|
|
__pycache__/
|
|
*.pyc
|
|
.venv/
|
|
venv/
|
|
node_modules/
|
|
dist/
|
|
build/
|
|
*.egg-info/
|
|
.pytest_cache/
|
|
.mypy_cache/
|
|
caddy_data/
|
|
caddy_config/
|
|
pgdata/
|
|
backups/
|
|
frontend/dist/
|
|
*.tsbuildinfo
|
|
.DS_Store
|