Backup image: four issues I found on a second review pass (.env dropped, no set -e, plaintext DB password, priv-files skipped)

1. The config backup silently drops .env (and every other dotfile). This is the one I'd fix first, because it breaks your own documented restore.

backup.sh:145 sets conf_files="*" and then cd $talkyard_dir; tar -czf ... $conf_files. That's an unquoted shell glob with no shopt -s dotglob, so dotfiles are excluded — .env never makes it into config...tar.gz. The comment two lines up (:143-144) even shows the pre-refactor list it replaced, which explicitly included .env, so this looks like an unintended regression from the 'just back up everything' change, not a deliberate exclusion.

Why it bites: .env holds COMPOSE_PROJECT_NAME, the version pin, and all the static container IPs/subnets — and your restore guide (docs/how-restore-backup.md:40) runs mv old-conf/.env ./, which must fail because .env was never in the archive. So a from-scratch restore stops right there.

I reproduced it: running the exact umask 027; conf_files="*"; cd; tar -czf lines against a dummy tree produced a tarball with docker-compose.yml, conf/, secrets/ — but no .env and no .gitignore. One-line fix: shopt -s dotglob before the tar (or restore the explicit file list). I notice your main2 tip commit is literally "Rest bkp w. Forgot .env !" — but that edits the restore docs; the glob in the image script is still there on main/master.

2. No set -e — a failed dump still 'succeeds'. backup.sh never sets -e or pipefail. If pg_dumpall can't reach Postgres, the pg_dumpall ... | gzip > file.sql.gz pipeline still writes a valid ~20-byte gzip that decompresses to 0 bytes, the script carries on through Redis/uploads, and exits 0. Cron (schedule-daily-backups.sh runs it as ... >> talkyard-maint.log 2>&1 with no status check) therefore sees a clean success.

So the failure mode is a directory full of recent-looking archives, one of which is an empty database. The random-freshness-marker design is clearly meant to catch exactly this off-site — and I see main2 now adds the check-talkyard-backups.sh / alert-if-... scripts that finally consume it, which is great. A local set -e (or just checking pg_dumpall's exit status before declaring success) would fail fast at the source too. I reproduced the empty-gz-on-failure behavior in a scratch shell.

3. The plaintext Postgres password ends up inside an unencrypted archive (by default). Because the config glob (*) does include secrets/, secrets/postgres_password.txt lands in config...tar.gz. The backup container runs as root, so the 0600 root:root secret is readable through the :ro mount. And GPG encryption is off unless you set backup_password — which is commented out by default (docker-compose.yml:28 and the backup service's #- backup_password at :313).

So on a stock install the DB password sits in cleartext inside the config archive, protected only by file perms (the script's umask 027 → 640 root:root, dir 750). Not a remote hole, but it raises the blast radius of anyone/anything that can read the archives (including once they're copied off-site). Worth a README nudge to enable backup_password, and/or excluding secrets/ from the config tarball when encryption is off.

4. priv-files is mounted into the backup container but never actually backed up. The compose backup service mounts it read-only (docker-compose.yml:319, priv-files:/var/talkyard/v1/priv-files:ro), but backup.sh only archives pub-files/uploads (backup.sh:76 and the uploads loop). Nothing reads the priv-files volume. So any private/access-controlled uploads would be silently absent from every backup. Either back the volume up or drop the unused mount so it doesn't imply coverage that isn't there. (On our instance this is currently moot — no private uploads — but it'd be a nasty surprise for anyone who does use them.)

A few small talkyard-prod-one docs things, while I'm here (all on main — some may already be handled on main2):

• docs/release-channels.md tells you to set RELEASE_BRANCH=regular or ...=lts, but scripts/upgrade-if-needed.sh:54 rejects any value that doesn't contain -v1- (and no such branches exist), so following the doc errors the upgrade immediately — it should read tyse-v1-regular.
• A couple of dead links on main: how-restore-backup.md → docs/setup-https.md (only on the v0 branch), troubleshooting.md → ./scripts/stats.sh (now ./view-stats), copy-backups-elsewhere.md → ../scripts/check-talkyard-backups.sh (actually under scripts/impl/).
• Publishing note: docs.talkyard.io/self-hosting/ currently builds from the ty-prod-one-v0 branch (its sidebar matches that branch's docs/, and the page still says "Debian 11 or 12"), so the v1 README/docs fixes won't show up there until the site build is repointed at a v1 branch. Flagging in case that's easy to miss.

Follow-up (2026-07-04): the new main2 backup-check script misses GPG-encrypted backups.

Update from actually turning on encrypted daily backups on this instance: the maintainer's new offsite-check scripts on the main2 branch of talkyard-prod-one (scripts/offsite-backup-checks/check-talkyard-backups.sh, commit 75f3dce) look for yesterday's backups like this:

components=("postgres.sql.gz" "redis.rdb.gz" "config.tar.gz")
backup_file=$(find "$backup_dir" -maxdepth 1 -type f -name "*${cur_date}*${comp}" | head -n 1)

No trailing wildcard. But with backup_password enabled (the fix for issue 3 above, the plaintext DB password), the backup image's /ty/backup.sh appends .gpg to every archive name, e.g. ...-2026-07-04T2117Z-daily-postgres.sql.gz.gpg. So for anyone running encrypted backups, the checker reports "Yesterday's backup missing" for all three components every day, even when the backups are fine — the exact users who followed the encryption advice get permanent false alarms.

Verified live here on v1.2026.003: an encrypted run produces only .gpg-suffixed files, and the find pattern matches none of them. (The uploads-directory check is unaffected — dir names don't get the suffix.)

Suggested fix: -name "*${cur_date}*${comp}*", or match the optional suffix explicitly the way delete-old-backups.sh already does (-regex ".+/.+-$what_files(\.gpg)?" — that script gets it right).