Files
felhom.eu/documentation
admin b5a73e050b Move the local whole-guest backup off the guest's own device (demo-hp + demo-felhom)
Supervised operational run. No code, no version bump, nothing deleted.

Primary backup tier on both demo boxes moved from `local` (a dir storage on
/var/lib/vz -- the SAME physical device as the guest) to `felhom-backup`, a dir
storage on each box's secondary drive:

  demo-hp      /mnt/nvme-1tb  uuid:91d2dc2d-...  archive 2,256,044,492 B
  demo-felhom  /mnt/hdd_1     uuid:47a3361a-...  archive 5,957,878,962 B

Both proven end to end via the real UI path: archive lands on the secondary
drive (df delta matches the archive byte-for-byte), restore-test auto-selects it
and passes with mount_parity: ok, and freshness survives an agent restart with
an empty in-memory store -- so the age can only have come from the new storage.

Phase 0: the target is CONFIGURATION, not converged (the sole writer of
agent.json touches only escrow.pbs_storage_id and preserves unknown keys), so
the runbook's STOP did not fire. No consumer hardcodes "local" on the backup path.

Findings:
- F-1  the storage path must BE the mountpoint; a subdirectory fails exactMount
       and the target reports disconnected permanently (observe.go:321)
- F-2  --is_mountpoint 1 is load-bearing; proven live, an unguarded storage on a
       non-mounted path reports active with the ROOT filesystem's free space and
       had already created dump/ on pve-root -- a silent retarget onto the very
       device this change escapes
- F-3  FelhomAgentStore is granted per storage path; without it every backup
       403s. felhom-host-install.sh must issue it for new installs
- R-109 (new) the DR recipe records no backup target, and each box now carries
       two content=backup dir storages, one live and one frozen
- R-105 narrowed and TRACED: dr_recipe drives was [] fleet-wide because the
       enrolled drives were never PVE storages, so isUserDataDrive never saw
       them. Both boxes now populate drives; SMART on the backup drives too

Absent-drive behaviour today is fail-loudly with no silent retarget (PVE half
live-proven; agent half source-traced). That is NOT the intended fall-back-and-
alarm design -- filed as E-2 with the honest single-drive label.

Reported in full in the record: the agent was restarted with a felhom-pbs backup
in flight, producing a spurious tier failure. The backup had in fact succeeded
(PVE task OK, 6,264,034,053 B snapshot) and the spurious failure reached no
channel -- R-84 ground truth superseded it.

Outstanding: full drive-loss recovery (needs physical access) and the agent half
of the absent-drive behaviour.
2026-07-28 21:38:13 +02:00
..

Felhom — Documentation

Felhom is a managed home-server service for Hungarian households, built on a three-component model over Proxmox:

  • Hub — operator backend on k3s (hub.felhom.eu). Repo: felhom.eu/hub/.
  • Host agent — one per Proxmox host; operator-tier; owns all Proxmox interaction. Repo: felhom-agent/.
  • In-guest controller — one per customer LXC; Docker-only; manages the customer's apps. Repo: felhom-controller/.

This directory is the central, code-verified documentation home for all three components plus the platform and the security-audit record.

Sections

Controller (in-guest) — controller/

The Docker-only app-domain controller. Full per-area docs grounded in current source (v0.59.0). → controller/README.md: module map, deploy & stack lifecycle, backup architecture, storage/monitoring/metrics, auth/hub/sync/integrations.

Host agent & platform — architecture/, proxmox-platform.md

The operator-tier agent and the Proxmox platform.

Hub (operator backend) — architecture/05

Security audits & remediation — audits/

Spike & test findings — tests/

Per-slice spike/validation findings (phases 05, slices 710). See tests/.

Conventions

  • Code-verified, not memory-derived. Architectural claims here are checked against the actual current source; if a claim can't be verified it is omitted and flagged, not guessed.
  • Per-repo operational working files (CLAUDE.md, CONTEXT.md, CHANGELOG.md, BUGHUNT.md, REPORT.md, TASK.md) live in their own repos — they are operational, not published docs.
  • Authoritative versions at last refresh: controller v0.59.0, agent v0.29.1, hub v0.11.0.