Nightly DB snapshots to the 1TB storage box (live DB stays local)

The 'external drive' turned out to be a CIFS-mounted Hetzner storage
box — SQLite cannot run on a network mount (WAL shared memory and
locking break), and the live DB is only ~7MB anyway. So: the hot
database stays on the local volume, and a nightly VACUUM INTO snapshot
(transactionally consistent, a plain sequential file write — perfect
for CIFS) lands in /data/archive, which compose binds to the storage
box via HOST_ARCHIVE_DIR. 14-day retention, plus a snapshot at boot.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

deploy/cup26.compose.yml

@@ -20,12 +20,14 @@ services:
       # opt-in unofficial sources (usually blocked from a datacenter IP; ESPN is primary)
       - ENABLE_SOFASCORE=${ENABLE_SOFASCORE:-false}
       - ENABLE_FOTMOB=${ENABLE_FOTMOB:-false}
+      - ARCHIVE_DIR=/data/archive
     volumes:
-      # HOST_DATA_DIR (in .env) may point at a host path — e.g. the external
-      # 1TB drive — so the growing SQLite DB stays off the small root disk.
-      # An absolute path = bind mount; unset = the original named volume.
-      # The container runs as node (uid 1000): chown 1000:1000 the host dir.
+      # The LIVE SQLite must stay on a real local filesystem (WAL + locking do
+      # not survive network mounts). HOST_DATA_DIR can override if ever needed.
       - ${HOST_DATA_DIR:-cup26-data}:/data
+      # Nightly VACUUM INTO snapshots land here — point HOST_ARCHIVE_DIR at the
+      # 1TB storage box (CIFS is fine for sequential snapshot files).
+      - ${HOST_ARCHIVE_DIR:-cup26-archive}:/data/archive
     security_opt:
       - no-new-privileges:true
     mem_limit: 384m
@@ -43,6 +45,7 @@ services:
 
 volumes:
   cup26-data:
+  cup26-archive:
 
 networks:
   proxy: