V6.1 continue refining backup: switch to Synology Drive Client for remote backup

docs/backup_restore.md

@@ -1,19 +1,21 @@
 # Backup and Restore (V6.0 Phase 4)
 
-This guide defines operational backup/restore for clean-slate recovery of the Docker runtime and Synology replication.
+This guide defines operational backup/restore for clean-slate recovery of the Docker runtime with host-level backups that Synology Drive can replicate.
 
 ## 1. Backup artifacts (clean-slate recovery set)
 
-- Primary local backup location: `./data/backups`
+- Primary local backup location: `DATABASE_BACKUP_DIR` (recommended production value: `/backup`)
 - Local files created per run:
   - `postgres-YYYYMMDD-HHMMSS.dump` (PostgreSQL custom dump via `pg_dump -Fc`)
   - `backup-YYYYMMDD-HHMMSS.manifest` (artifact index)
-- Synology files created per run (when `SYNOLOGY_BACKUP_DIR` is set):
+- Optional Synology files created per run (when `SYNOLOGY_BACKUP_DIR` is set):
   - `postgres-YYYYMMDD-HHMMSS.dump` (copied from local)
   - `config-YYYYMMDD-HHMMSS.tar.gz` (deployment config snapshot: `.env.production`, `docker-compose.production.yml`, `deploy/cloudflared/config.yml` when present)
   - `logs-YYYYMMDD-HHMMSS.tar.gz` (snapshot of `/app/data/logs`)
   - `backup-YYYYMMDD-HHMMSS.manifest`
-- Synology incremental media mirror (copied only if missing):
+- Local app-data mirror (updated each run):
+  - `data/**`
+- Local incremental media mirror (copied only if missing):
   - `uploads/homepage.md`
   - `uploads/documents/**`
   - `uploads/photos/**`
@@ -28,21 +30,30 @@ sh deploy/backup/create_postgres_backup.sh
 
 Environment overrides:
 
-- `BACKUP_DIR` (default `./data/backups`)
+- `BACKUP_DIR` (default `DATABASE_BACKUP_DIR`, then `./data/backups`)
+- `APP_DATA_BACKUP_DIR` (default `${BACKUP_DIR}/data`)
+- `UPLOADS_BACKUP_DIR` (default `${BACKUP_DIR}/uploads`)
 - `BACKUP_RETENTION_DAYS` (default `14`)
 - `SYNOLOGY_BACKUP_DIR` (if set, dump/config/log/manifest are copied to this mounted path and media is synced incrementally)
 - `ENV_FILE` (default `.env.production`)
 - `COMPOSE_FILE` (default `docker-compose.production.yml`)
 
+Recommended production setup:
+
+- Mount a host-visible folder into `/backup` for both `app` and `worker` services.
+- Set `DATABASE_BACKUP_DIR=/backup` in `.env.production`.
+- Leave `SYNOLOGY_BACKUP_DIR` empty when Synology Drive Client handles replication from the host folder.
+
 Example with Synology mount:
 
 ```bash
 SYNOLOGY_BACKUP_DIR=/mnt/synology-backups sh deploy/backup/create_postgres_backup.sh
 ```
 
-## 2.1 Persisting Synology mount (LXC)
+## 2.1 Optional direct Synology mount (LXC)
 
-The backup copy step depends on a mounted NAS path. Manual `mount` commands are lost after reboot unless persisted.
+This section is only needed when using direct container-side Synology copy via `SYNOLOGY_BACKUP_DIR`.
+Manual `mount` commands are lost after reboot unless persisted.
 
 Use the template (copy, edit placeholders, then run):
 

docs/production-runbook.md

@@ -21,6 +21,7 @@ This runbook is the operational checklist for releasing and monitoring the trans
 
 1. Deploy artifact/config to target environment.
    - V6.0 Phase 1 production stack: `docker compose -f docker-compose.production.yml up -d --build`
+   - For Runtime Settings writes in production, mount `.env.production` into the app container and set `RUNTIME_SETTINGS_ENV_FILE=/app/.env.production`.
    - For SQLite -> PostgreSQL cutover, run `uv run python tools/export_import_migration.py verify --source-db <sqlite-path-or-url> --target-db <postgres-url>` before switching runtime.
 2. Validate service startup:
    - `/healthz` responds `200`
@@ -36,7 +37,7 @@ This runbook is the operational checklist for releasing and monitoring the trans
    - stdout aggregation receives events
    - file logs are written under `./data/logs`
 5. Create a fresh PostgreSQL backup after successful deployment:
-   - `sh deploy/backup/create_postgres_backup.sh` (creates local DB dump + Synology DB/config/log artifacts + incremental media mirror)
+   - `sh deploy/backup/create_postgres_backup.sh` (creates local DB dump + local incremental uploads mirror under `DATABASE_BACKUP_DIR`)
 
 ## 3. Rollback triggers and actions
 
@@ -108,7 +109,7 @@ This runbook is the operational checklist for releasing and monitoring the trans
 1. Verify `postgres` container is healthy and accepting connections.
 2. Confirm dump file exists and is non-zero size.
 3. Re-run backup/restore scripts with explicit `ENV_FILE` and `COMPOSE_FILE` if using non-default paths.
-4. If Synology copy fails, keep local backup and resolve mount/network before next backup cycle.
+4. If direct Synology copy fails, keep local backup and resolve mount/network before next backup cycle.
    - For LXC setups, use `deploy/backup/mount_synology_cifs.example.sh` as the persistent mount template.
 
 ## 6. Dependency upgrade policy

docs/ui/pages/settings.md

@@ -23,8 +23,10 @@ Settings manages installation-local registries, safe runtime .env settings, and
   - **Runtime Settings**
 - Runtime Settings exposes an allowlisted set of non-secret fields synchronized with `Settings` model fields except excluded secret/unsafe fields.
 - Runtime Settings is rendered as a compact two-column editor (**Setting**, **Value**) in a centered, narrower responsive container.
-- Runtime Settings persists changes to `.env`, validates by constructing a `Settings` instance, and reports validation failures through the shared UI error presenter.
+- Runtime Settings persists changes to the resolved runtime env file, validates by constructing a `Settings` instance, and reports validation failures through the shared UI error presenter.
+- The write target resolution order is: explicit function override (tests/tools), `RUNTIME_SETTINGS_ENV_FILE` environment variable (deployment override), then `Settings.model_config.env_file` (default `.env`).
 - Runtime Settings changes require application restart to take effect.
+- Runtime Settings renders a host-side restart command (`docker compose -f docker-compose.production.yml up -d --force-recreate app worker`) so operators can apply saved values without granting Docker control to the app container.
 - Runtime Settings includes an explicit "Other settings not shown here" markdown table listing:
   - secrets (`OPENROUTER_API_KEY`, `DATABASE__PASSWORD`)
   - high-risk database connection settings (`DATABASE__DRIVER`, `DATABASE__PATH`, `DATABASE__HOST`, `DATABASE__PORT`, `DATABASE__DATABASE`, `DATABASE__USER`)