steve 6450bf1b88
CI / Test (linux/amd64) (push) Has been cancelled
CI / Lint (push) Has been cancelled
CI / Build (windows/amd64) (push) Has been cancelled
CI / Build (linux/amd64) (push) Has been cancelled
CI / Build (linux/arm64) (push) Has been cancelled
P2-02 (agent side) + P2-03: agent scheduler + schedule.fire dispatch
Closes the schedule reconciliation loop end-to-end.

* New `internal/agent/scheduler` package wraps robfig/cron/v3 with
  the lifecycle the agent needs:
  - Apply(ScheduleSetPayload, Sender) stops the prior cron (waiting
    for in-flight entries to return), rebuilds from scratch, starts,
    and emits schedule.ack with the version we just applied.
  - Disabled entries skipped silently; bad cron exprs (which
    shouldn't reach us — the server validates — but defensive)
    log a warn and skip.
  - On each cron tick the entry sends a new schedule.fire envelope
    to the server with {schedule_id, scheduled_at}. The scheduler
    itself never builds CommandRunPayloads — server is the source
    of truth for jobs.
  - tx is swapped on every Apply, so reconnect is handled
    naturally: cron entries that fire against a dropped tx log
    "no active connection" and skip the tick.
  - Stop() is idempotent and waits for the cron's in-flight
    workers via cron.Stop().Done().

* New wire message api.MsgScheduleFire + api.ScheduleFirePayload
  for the agent → server "I just fired locally" RPC.

* Server-side dispatch (schedule_push.go: dispatchScheduledJob):
  looks up the schedule by id, validates ownership + that it's
  enabled, builds args from kind (paths for backup; other kinds
  are still arg-less in Phase 2 and grow as those job kinds land
  in P2-05..08), persists a jobs row with actor_kind=schedule +
  scheduled_id, and writes command.run back on the same conn so
  the agent runs through its existing dispatch path.

* store.CreateJob now writes scheduled_id. This column was in the
  schema since 0001 but never populated — the original P1 path
  only had operator-driven jobs, so actor_kind was always 'user'
  and scheduled_id was always nil.

* cmd/agent/main.go integration: dispatcher gains a
  *scheduler.Scheduler; the MsgScheduleSet case now hands the
  payload to scheduler.Apply (in a goroutine so the WS read loop
  keeps draining other messages).

* WS dispatcher gains OnScheduleFire alongside OnScheduleAck.

* Tests:
  - scheduler unit tests (4): ack-on-apply, cron tick fires
    schedule.fire envelope, disabled entries don't fire, replace-
    prior-state stops the old cron.
  - Server-side end-to-end: schedule.fire → command.run with the
    right job_id / kind / args, plus jobs row with actor_kind=
    "schedule" and scheduled_id linking back to the schedule.

Persistence of next-fire times across agent restarts is
deliberately deferred. A missed fire window during downtime
simply fires once on reconnect — that's the desirable behaviour
(the operator wants the missed backup to run, not be silently
skipped because we lost track of when it was due).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-02 11:29:12 +01:00
2026-05-01 00:03:59 +01:00
2026-05-01 00:03:59 +01:00
2026-04-30 23:55:52 +01:00
2026-05-01 00:03:59 +01:00
2026-05-02 11:12:58 +01:00
2026-05-02 11:12:58 +01:00
2026-05-01 00:03:59 +01:00

restic-manager

Self-hosted, browser-based, single-pane-of-glass for managing restic backups across a fleet of Linux and Windows endpoints.

Status: pre-alpha. Phase 0 (project bootstrap) complete; Phase 1 (MVP) in progress. See spec.md for the design and tasks.md for the roadmap.

What it does (target)

  • Central visibility into backup state for every endpoint
  • Trigger any restic operation remotely (backup, forget, prune, check, unlock, snapshots, stats, diff, restore)
  • Manage per-host backup schedules from the UI
  • Live job progress streamed back to the UI
  • Restore wizard (browse snapshots, pick paths, restore to original or alternate host)
  • Repo health surfacing (size, dedup ratio, last check, lock state)
  • Alerting on failure or staleness
  • Cross-platform agent (Linux + Windows)
  • Ransomware-resistant repo access via append-only credentials

Architecture (one-line summary)

A small Go control-plane on the Proxmox host, lightweight Go agents on each endpoint that hold an outbound WebSocket to the control-plane, and a restic/rest-server on Unraid that holds the actual backup data. The control-plane never touches backup bytes.

Full architecture diagram and component breakdown: spec.md §3.

Repository layout

cmd/server/        control-plane binary
cmd/agent/         endpoint agent binary
internal/api       shared API types (REST + WS envelopes)
internal/server/   HTTP, WS, UI handlers
internal/agent/    service integration, restic runner, local scheduler
internal/restic    restic CLI wrapper
internal/store     SQLite persistence
internal/crypto    secret encryption
internal/auth      passwords, sessions, agent tokens
web/               server-rendered templates + static assets
deploy/            Dockerfile, docker-compose.yml, install scripts
design/            UI wireframes (Phase 0 design pass)

Local development

Requires Go 1.25+ (built and tested on 1.26). The floor is set by modernc.org/sqlite v1.50.

make build           # builds cmd/server and cmd/agent into ./bin
make test            # runs go test ./...
make lint            # runs golangci-lint
make run-server      # runs the server (dev defaults)

License

PolyForm Noncommercial 1.0.0 — see LICENSE. Free for personal, hobby, research, educational, governmental, and other noncommercial use. Commercial use requires a separate license.

S
Description
No description provided
Readme 2.9 MiB
2026-05-09 12:58:56 +01:00
Languages
Go 68.6%
HTML 28.5%
CSS 1.4%
TypeScript 0.5%
Makefile 0.4%
Other 0.5%