admin/felhom-controller
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Live drive: §5 backup tiers (F13) — tier1+PBS work, tier2 honest no-target, 3-2-1 weakened by F9

Browse Source
This commit is contained in:
authentik Default Admin
2026-06-14 00:31:54 +02:00
parent 6197eadeee
commit 5954763ed7
1 changed files with 8 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
LIVE-DRIVE-FINDINGS-2026-06-14.md
+8
View File
@@ -115,5 +115,13 @@ The demo dashboard has **no password set**, so the controller's `RequireAuth` an
- **remove guard**: `POST /api/stacks/brokentest/remove` while running → correctly **refused** (`"still running — stop it first"`). After stop, remove succeeded; the stack **directory is intentionally left** on disk (so a catalog app can be redeployed) — by design.
- **Verdict:** all lifecycle operations work and stay consistent with ground truth. **Severity: INFO (PASS).**
### F13 — Backup tiers: tier-1 + PBS offsite WORK; tier-2 honest no-target; but "primary" lives on the same OS disk as the data — MIXED (3-2-1 weakened by F9)
- **Area:** §5 backup.
- **Tier-1 (primary recovery units + DB dumps):** `POST /api/backup/run` → success. Recovery units (`compose/` + `manifest.json`) created for **all 7 deployed apps**; romm's MariaDB dumped to `backups/primary/romm/db-dumps/romm-mariadb.sql` (44K). `db_dump count=1` is **correct** — mealie runs embedded SQLite (single container, no postgres sidecar), so it has no SQL dump (captured as a volume in its unit). **Verdict: works.**
- **Tier-2 (off-drive secondary):** `POST /api/backup/tier2` → ran, processed 1 HDD app (romm), and **honestly refused**: log `Tier 2 for romm: no off-drive target — nincs másik fizikai meghajtó — a 2. mentéshez 2. meghajtó szükséges`; `backup-data` shows `secondary/romm/rsync exists:false`. No silent failure, no rootfs-fill. **Verdict: works (correct no-target handling).**
- **Tier-3 (PBS offsite, whole-guest):** `POST /api/guest-backup/trigger` → created a **new** PBS snapshot. `GET /api/guest-backup/status` → `phase done, started 2026-06-13T22:28:55Z, success, size 5.99GB, mode snapshot, crash_consistent`. Verified in PBS itself (read-only `pvesm list felhom-pbs --vmid 9201`): new snapshot `felhom-pbs:backup/ct/9201/2026-06-13T22:28:56Z` listed (3 snapshots total). **Verdict: works end-to-end.**
- **The 3-2-1 weakness (HIGH-ish, consequence of F9):** the "primary" tier (recovery units + DB dumps) is stored under `/mnt/sys_drive/felhom-data/backups`, which is the **same 32G OS rootfs (disk-0)** that holds the app data itself. So tier-1 gives **zero protection against disk-0 loss** — source and backup share a disk. With no second drive attached (F9), the only genuine off-host copy is PBS. Effective reality is **"2 copies on the same disk + 1 PBS"**, not 3-2-1. The UI/dashboard 3-2-1 framing would overstate resilience here.
- **Minor:** `/api/backup/status` reports only `db_dump` + `running`/`enabled` — it does not surface recovery-unit or tier-2 status, so "is my backup complete?" requires multiple endpoints. The earlier guest-backup status briefly showed a **stale prior run** (20:27Z) before my new run appeared — momentary staleness, not a clock bug.
### F4 — `/api/stacks/rescan` returns "stack not found: rescan" — LOW
- The runbook's documented rescan endpoint `GET /api/stacks/rescan` is routed as a stack name lookup → `{"ok":false,"error":"stack not found: rescan"}`. Either the route was removed/renamed or the runbook is stale. (Sync/rescan is reachable via `POST /api/sync`.) Cosmetic but documents a stale/missing endpoint.