Fixes client profiles applying a run time without its timezone.
Applying a profile could leave plans running hours apart (#411)
Set a profile to run at 01:00, apply it, and some clients would show 01:00 while others showed 07:00 — with the edit dialog for those plans still saying 01:00.
A schedule stores its own timezone, taken from whoever created the plan, and falls back to America/New_York when that session had none. A profile carried run hours but no timezone, so applying one wrote the same 01:00 into schedules that each read it in a different zone. The schedules list renders every schedule in the viewer's zone, so the same profile appeared to run at different hours on different clients. 01:00 in America/New_York viewed from central Europe is 07:00 — the six hours in the report.
It also explains the two puzzling parts. The edit dialog shows the stored time without converting, so it disagreed with the list. And a plan "suddenly" correcting itself is what happens when you save it: saving rewrites that schedule's zone to the editor's.
A profile now states the timezone its run hours are in, and applying it writes the zone along with the time, so every client in the profile runs at the same moment. Left blank it means the server's timezone, resolved when the profile is applied rather than frozen when it was saved. Creating a plan takes the zone from the client's profile too, rather than from whoever happens to be creating it.
If you have already applied a profile, re-apply it to bring those schedules onto one timezone. Existing schedules are deliberately not rewritten by the update itself — that would silently move when backups run on every install.
Thanks to @kosli for the report, and for noticing that the list and the edit dialog disagreed. That detail is what identified it.
The profile's Run Hours field is also now labelled as 24-hour. The plan editor's AM/PM display is separate and follows each user's own 12/24-hour preference.
Dashboard data over the API
GET /api/v1/dashboard now also returns archive totals — recovery points, original and deduplicated bytes, what is on disk, dedup savings and the last backup — plus jobs_24h, twenty-four hourly buckets of job counts. Both are scoped to the clients the caller can see.
GET /api/v1/server-stats is new and admin-only: CPU, memory, network and per-mount disk figures as numbers rather than formatted strings.
Neither changes anything existing. They exist so an API client can draw the same cards the web dashboard has.
Notes
- The agent is unchanged; clients on 2.90.0 do not need to update.
- Adds one database migration.