v0.12.7: mandatory HDD backup, pre-dump, restore for all apps

Fix 1: HDD data backup is now mandatory for all deployed apps.
resolveAppBackupPaths() iterates ListDeployedStacks() directly — no
longer reads GetAppBackupMap() or checks the Enabled flag. DiscoverAppData()
drops backupPrefs parameter; BackupEnabled is set from HasHDDData.
Five dead settings methods removed: IsAppBackupEnabled, SetAppBackup,
GetAppBackupMap, SetAppBackupBulk, GetAppBackupPrefs.

Fix 2: Cross-drive backup now triggers a fresh DB dump (DumpStackDB)
before running. DBDumper interface added to crossdrive.go; Manager
implements it; SetDBDumper wired in main.go. Non-fatal — proceeds with
user data backup even if DB dump fails.

Fix 3: Restore dropdown shows ALL deployed apps (not just HDD+enabled).
restore.go rewritten: always restores config+DB, adds user data if hasHDD.
UI shows restore type banner (full / config+DB / config only) with
color-coded styling. Snapshot API clarified for non-HDD apps.

Fix 4: "Docker kötetek" → "Konfiguráció" — named volumes are not in
the restic backup paths; compose files + app.yaml are what's backed up.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

controller/README.md

@@ -4,7 +4,7 @@
 
 A single, lightweight Go container that replaces Portainer + scattered systemd scripts with a unified, Hungarian-language web dashboard for managing Docker Compose stacks, backups, storage, monitoring, and notifications on customer hardware.
 
-**Current version: v0.12.6**
+**Current version: v0.12.7**
 
 ---
 
@@ -163,7 +163,10 @@ The `/apps/{slug}` page renders hero section, screenshots, setup guide, and opti
 
 ### 2. Backup System
 
-The backup system implements a 3-layer architecture ensuring data safety through redundancy and versioning.
+The backup system implements a **3-2-1 backup architecture**:
+1. **Nightly restic (mandatory, same drive)** — DB dumps + config + ALL user data (HDD). Every app with data is backed up automatically. No toggles.
+2. **Cross-drive backup (opt-in, different device)** — rsync or restic to a secondary physical drive. Protects against drive failure.
+3. **Remote backup (future)** — offsite copy for disaster recovery.
 
 #### Layer 1: Database Dumps (`internal/backup/dbdump.go`)
 
@@ -173,12 +176,14 @@ The backup system implements a 3-layer architecture ensuring data safety through
 - **Validation** after each dump: checks file size, header presence, counts `CREATE TABLE` statements
 - Results cached in `settings.json` surviving container restarts
 - Scheduled nightly at 02:30
+- Also triggered per-app by cross-drive backup before each run (`DumpStackDB`)
 
 #### Layer 2: Restic Snapshots (`internal/backup/restic.go`)
 
 - Auto-generated repository password (32 random bytes, base64url)
 - Password synced to hub for disaster recovery
-- Backs up: stacks directory + DB dump directory + enabled app HDD mount paths
+- Backs up: stacks dir + DB dump dir + **ALL deployed apps' HDD mount paths** (mandatory, no opt-in)
+- `resolveAppBackupPaths()` iterates all deployed stacks via `ListDeployedStacks()` — no `Enabled` flag
 - Auto-detects and unlocks stale locks
 - Weekly prune on Sundays with configurable retention (keep-daily, keep-weekly, keep-monthly)
 - Weekly integrity check (`restic check`) on Sunday 04:00
@@ -192,32 +197,39 @@ Implements the 3-2-1 backup rule by copying data to a different physical drive.
   - **rsync** — Simple mirror with `--delete` (fast, no versioning)
   - **restic** — Versioned, deduplicated, encrypted (shared repo across apps)
 - Per-app configuration: destination path, method, schedule (daily/weekly/manual)
+- **Pre-backup DB dump**: `DumpStackDB()` runs before cross-drive backup to ensure DB consistency; non-fatal on failure
 - **Drive-type-aware validation** (`ValidateDestination` / `CheckBackupDestination`):
   - External mount: block if <100 MB free; warn/block at 90%/95% usage
-  - System drive (same block device as `/`): require ≥10 GB free AND <90% usage to protect OS stability; allowed with a logged warning (no hard block for non-mount-point destinations)
-  - Web UI `CheckBackupDestination` matches runner thresholds — no surprise divergence between UI and actual enforcement
+  - System drive (same block device as `/`): require ≥10 GB free AND <90% usage; allowed with logged warning
 - **Rsync destination layout** (`runRsyncBackup`):
   - Single mount: data goes directly into `backups/rsync/<app>/` (no extra nesting)
-  - Multiple mounts: each gets a `backups/rsync/<app>/<leaf>/` subfolder named after the mount's base directory; duplicate leaf names disambiguated with `_N` suffix
-  - DB dump files excluded: `--exclude backups/*.sql.gz`, `--exclude backups/*.sql`, `--exclude backups/*.dump` — avoids duplicating data already managed by the pg_dump layer
+  - Multiple mounts: each gets `backups/rsync/<app>/<leaf>/` subfolder; duplicate leaf names get `_N` suffix
+  - DB dump files excluded: `--exclude backups/*.sql.gz/sql/dump` — avoids duplicating pg_dump data
 - Safety guards: destination ≠ source, path-overlap check, writable check
-- **Chained execution**: cross-drive runs immediately after nightly restic backup (daily apps every night, weekly apps on Sundays) for DB/file consistency
+- **Chained execution**: cross-drive runs immediately after nightly restic backup (daily apps every night, weekly apps on Sundays)
 - Per-app concurrency lock prevents overlapping runs
 - Status tracking (last_run, duration, size, error) persisted to settings.json
 
 #### Restore (`internal/backup/restore.go`)
 
-- Per-app restore from restic snapshots
-- Snapshot filtering by app: `GET /api/backup/snapshots?stack={name}` returns only snapshots whose paths overlap the app's HDD mounts
-- **Auto stop/restart**: stops the app's containers before `restic restore`, restarts after (even on failure)
-- Human-friendly snapshot display: `2026-02-17 hetfo 03:00 (a3f2b1)`
+All deployed apps appear in the restore dropdown — not just those with HDD data.
+
+| App type | DB restored | Config restored | User data restored |
+|----------|------------|-----------------|-------------------|
+| Has HDD data | ✓ | ✓ | ✓ (always — mandatory) |
+| DB only, no HDD | ✓ | ✓ | n/a |
+| No DB, no HDD | — | ✓ | n/a |
+
+- Restore type info shown in UI when app selected (Hungarian banner: full / config+DB / config only)
+- Snapshot API: apps without HDD mounts return all snapshots (all contain stacks dir + DB dumps)
+- **Auto stop/restart**: stops app before `restic restore`, restarts after (even on failure)
 - Running flag prevents concurrent backup/restore operations
 
 #### Backup Page UI
 
 The backups page shows a unified per-app status table:
 - **Status dot**: green (fully covered), yellow (warning — failed run, system drive, disk full), red (HDD data without cross-drive), auto (no user data)
-- Expandable row per app showing all 3 backup layers (DB, Docker volumes, user data)
+- Expandable row per app showing all 3 backup layers (DB, Konfiguráció, user data)
 - Schedule overview with next run times
 - Snapshot history table (last 20 snapshots with ID, time, data added)
 - Repository info card (path, size, snapshot count, encryption key with show/copy)