Move borg dump staging to backup share

ops/borg-ui/scripts/README.md

@@ -10,7 +10,7 @@ These scripts are intended to run on the Unraid host before a Borg backup starts
 
 Fresh dump artifacts are written to:
 
-- `/mnt/user/appdata/borg-ui/dumps/latest`
+- `/mnt/user/backups/borg/dumps/latest`
 
 Borg UI should include `/local/borg-dumps` as a backup source.
 
@@ -19,3 +19,21 @@ Borg UI should include `/local/borg-dumps` as a backup source.
 - The script is written for host execution where `docker` is available.
 - It does not assume Backrest.
 - It keeps only the latest dump set because Borg itself provides history.
+
+## Recommended automation path
+
+The recommended automation path is:
+
+1. Unraid User Scripts on the host
+2. host-side schedule / cron
+3. Borg UI backup job afterwards
+
+This is preferred over a Borg UI inline hook because the dump script expects:
+
+- host access to `docker exec`
+- host paths like `/mnt/user/...`
+- direct write access to the dump target directory
+
+Do not treat `pre-backup-dumps.sh` as a Borg UI inline script unless the architecture is deliberately changed later.
+
+See `USER_SCRIPTS_SETUP.md` for the intended host-side rollout.

ops/borg-ui/scripts/USER_SCRIPTS_SETUP.md

@@ -0,0 +1,50 @@
+# Unraid User Scripts Setup
+
+This document describes the intended automation path for `pre-backup-dumps.sh`.
+
+## Decision
+
+The pre-backup dump refresh should run:
+
+- on the Unraid host
+- through the User Scripts plugin or host cron
+- before the Borg UI repository job starts
+
+It should **not** be implemented as a Borg UI inline hook in the current design.
+
+## Why host-side
+
+`pre-backup-dumps.sh` currently assumes:
+
+- access to the host Docker daemon via `docker exec`
+- access to host paths under `/mnt/user/...`
+- the ability to write fresh dump artifacts into the shared dump directory
+
+That makes host execution simpler, more transparent, and lower-risk than giving Borg UI additional host-level responsibilities.
+
+## Recommended rollout
+
+1. Store the script on the host, for example at:
+   - `/mnt/user/appdata/borg-ui/scripts/pre-backup-dumps.sh`
+2. Make it executable:
+   - `chmod +x /mnt/user/appdata/borg-ui/scripts/pre-backup-dumps.sh`
+3. Create a User Scripts entry such as:
+   - `borg-pre-backup-dumps`
+4. Let that entry run:
+   - on a fixed schedule before the expected Borg backup window
+   - or manually before ad hoc Borg runs
+5. Keep Borg UI focused on backing up `/local/borg-dumps`, not on generating the dumps itself.
+
+## Operational model
+
+The intended sequence is:
+
+1. Host script refreshes `latest` dump artifacts.
+2. Borg UI backs up `/local/borg-dumps` together with the rest of `critical_infra`.
+3. Borg history preserves dump history, so the host only needs to keep the most recent dump set.
+
+## Current dump target
+
+- `/mnt/user/backups/borg/dumps/latest`
+
+This target is intentionally separate from live app state so that dump artifacts live under the backup share instead of `appdata`.

ops/borg-ui/scripts/pre-backup-dumps.sh

@@ -5,7 +5,7 @@ set -eu
 # It refreshes the latest database dumps in a stable directory so Borg can
 # version the dump artifacts instead of raw live database files.
 
-DUMP_ROOT="${DUMP_ROOT:-/mnt/user/appdata/borg-ui/dumps}"
+DUMP_ROOT="${DUMP_ROOT:-/mnt/user/backups/borg/dumps}"
 LATEST_DIR="$DUMP_ROOT/latest"
 TMP_DIR="$DUMP_ROOT/.tmp"
 SHARED_PG_ADMIN_USER="${SHARED_PG_ADMIN_USER:-mailarchiver}"