v2.2.0 — SQLite databases by file path (auto-mount)

Highlights

🗃️ SQLite databases by file path — automatic volume mounting

A type: sqlite database is dumped by reading its file (sqlite3 <path> .dump), so that file must live inside the gobackup engine. Now you just declare the DB by the path it has in your application container, and the supervisor mounts it in for you:

labels:
  gobackup.enable: "true"
  gobackup.name: "shop"
  gobackup.databases.main.type: "sqlite"
  gobackup.databases.main.path: "/app/data/bot_database.sqlite3"

The supervisor discovers the volume backing that path, re-mounts it into the recreated gobackup container at /volumes/<model>/…, and rewrites databases.<id>.path to the mounted location — the same discovery + recreate machinery as archive auto-mount, driven by the same gobackup_container.* spec and gobackup-docker.component: "gobackup" marker.

• Read-write mount (archive mounts are read-only): .dump opens the DB and a WAL-mode database writes -wal/-shm sidecars next to it. The volume's directory is mounted so the sidecars have somewhere to go.
• Mounts that collide on a target are deduped with read-write winning over read-only (a volume shared by an archive include and a sqlite path resolves once, writable).
• A path already under /volumes/, or not backed by any volume, is left untouched (with a log). The stock gobackup image already bundles sqlite3 — no extra setup.

Verified end-to-end (spike/e2e-sqlite/): the app's DB volume is mounted read-write at /volumes/shop/app/data, databases.main.path is rewritten, and the produced tgz archive contains the seeded row INSERT INTO orders VALUES(1,'sqlite-e2e-ok').

Multi-arch image ghcr.io/ekho/gobackup-docker tags 2.2.0, 2.2, 2, latest.