backup: include gitea in PD postgres dumps

automation/.env.example

@@ -43,7 +43,7 @@ PD_DATABASES_ROOT=/mnt/docker-ssd/docker/databases
 PD_TANK_DOCKER_ROOT=/mnt/tank/docker
 PD_DB_DUMP_ROOT=/mnt/tank/docker/backups/db-dumps
 POSTGRES_CONTAINER=shared-postgres
-POSTGRES_DB_LIST="n8n paperless"
+POSTGRES_DB_LIST="gitea n8n paperless"
 BACKUP_SSH_KEY=/home/truenas_admin/.ssh/serenity_backup_ed25519
 BACKUP_KNOWN_HOSTS=/home/truenas_admin/.ssh/known_hosts
 DOCKER_BIN=/usr/bin/docker

automation/README.md

@@ -30,7 +30,7 @@ automation/bin/karakeep_api.py /api/health --raw-path --pretty
 
 ## Backup scripts
 
-- `bin/pd_backup_postgres.sh` — creates gzipped `pg_dump` exports for the configured Postgres DB list (quote space-separated DB names in `.env`, e.g. `POSTGRES_DB_LIST="n8n paperless"`)
+- `bin/pd_backup_postgres.sh` — creates gzipped `pg_dump` exports for the configured Postgres DB list (quote space-separated DB names in `.env`, e.g. `POSTGRES_DB_LIST="gitea n8n paperless"`)
 - `bin/pd_backup_sync_to_serenity.sh` — `rsync`s configured backup/config roots to Serenity
 - `bin/run_pd_backups.sh` — wrapper that runs both steps in order
 - `bin/pd_restore_verify_postgres.sh` — restores the latest dump for each configured database into a throwaway Postgres container and fails on SQL errors
@@ -140,6 +140,7 @@ tail -100 /mnt/tank/docker/backups/pd-backups.log
 ## Safety notes
 
 - DB dumps are the priority restore artifacts; do not rely only on raw volume copies.
+- For Gitea specifically, keep the logical Postgres dump in `POSTGRES_DB_LIST`; a live rsynced Postgres volume alone is not the preferred recovery artifact.
 - The sync script uses `rsync --delete` inside the destination backup root, so point it at a dedicated backup path.
 - Keep `.env` and SSH material out of git.
 - If cron runs under a non-root PD account, `sudo -n /usr/bin/docker` must work or the DB dump step will fail.

docs/operations/PD_BACKUP_DEPLOYMENT.md

@@ -35,7 +35,7 @@ PD_DATABASES_ROOT=/mnt/docker-ssd/docker/databases
 PD_TANK_DOCKER_ROOT=/mnt/tank/docker
 PD_DB_DUMP_ROOT=/mnt/tank/docker/backups/db-dumps
 POSTGRES_CONTAINER=shared-postgres
-POSTGRES_DB_LIST="n8n paperless"
+POSTGRES_DB_LIST="gitea n8n paperless"
 BACKUP_SSH_KEY=/home/truenas_admin/.ssh/serenity_backup_ed25519
 DOCKER_BIN=/usr/bin/docker
 SUDO_BIN=/usr/bin/sudo
@@ -54,7 +54,7 @@ mkdir -p /mnt/tank/docker/backups/db-dumps
 
 Confirm:
 
-- fresh `*.sql.gz` files appear in `/mnt/tank/docker/backups/db-dumps`
+- fresh `gitea_*.sql.gz`, `n8n_*.sql.gz`, and `paperless_*.sql.gz` files appear in `/mnt/tank/docker/backups/db-dumps`
 - appdata/database/tank-docker content lands under the chosen Serenity backup root
 - no sudo prompt appeared during `docker exec`
 
@@ -98,6 +98,8 @@ What it proves:
 - expected files still exist inside the restored sample
 - the latest run state can be exported to Prometheus via node-exporter's textfile collector
 
+Current expectation: `POSTGRES_DB_LIST` includes `gitea` so the backup set contains a logical dump for the Gitea database in addition to the raw synced Postgres data directory.
+
 ## Important limitations
 
 - Do **not** use `systemctl restart docker` on PD.
@@ -105,3 +107,4 @@ What it proves:
 - `rsync --delete` is intentional; use a dedicated destination root, not a shared miscellaneous folder.
 - This scaffolding does not yet back up `.env` files here because those are already handled by the separate encrypted/private-repo process.
 - If you insist on a non-root cron user on PD, you will need passwordless Docker access (`sudo -n /usr/bin/docker ...`) and write access to the chosen dump directory.
+- For Gitea, do not treat the live-synced Postgres datadir as the main restore proof; keep and verify the `gitea` logical dump as part of the normal restore-verification cycle.