[Feature Request] Aggregate synced client backups and plans into the server's Summary Dashboard (Centralized Monitoring)

[bearbroz]

Summary

The multihost docs describe Centralized Monitoring as pushing backup status from multiple machines to a single dashboard. Today, sync delivers client operation history to the server's operation log, and it's fully browsable through per-client peer views, but the Summary Dashboard (the landing page) only aggregates activity executed by the server instance itself. Synced client backups and client-defined plans are invisible there, so the "single dashboard" at-a-glance view promised by the docs doesn't exist yet.

I'd like to request that the Summary Dashboard aggregate backup activity across all synced instances.

Use case

A typical hub-and-spoke setup: a NAS acts as the monitoring hub, several machines run their own backup plans as clients, and the hub itself runs only a few plans plus maintenance. After sync is configured, the operator should be able to glance at the hub's dashboard and see the backup status of the whole fleet — repo cards reflecting client activity, plan cards for client plans, and recent activity across all machines — without clicking into each peer view.

Current behavior (Backrest v1.14.1)

What works:

• Sync sessions establish and stay connected; client operation history is present in the server's operation log
• Each client's peer view renders its plans and full backup history
• Operations returned for repo/plan selectors include synced client activity
• Plans declared on the hub render correctly on the dashboard

What's missing:

• Repo cards show stats only from server-executed backups; client activity against the same repo (identical GUIDs) is omitted
• Plans that exist only on clients never appear as plan summaries
• Recent Activity is derived from plan summaries, so client backups never appear there
• Repo overdue detection doesn't account for plans that live only on clients, so a repo backed up exclusively by clients can never be flagged

Expected behavior

• Repo cards on the server include backup activity from all synced instances whose operations match locally-configured repos (operations already carry the matching repo GUID)
• Client plans appear as plan summaries alongside local plans. The client's plan definitions (including schedules) are already available to the server via each peer's synced config, so schedule-based status/overdue indicators can be computed
• Recent Activity reflects backups from all instances

Notes

• Operations are only ever pushed to the server by the instance that created them, so aggregation can't double-count
• If a client granted only Read Operations (the docs' Centralized Monitoring recipe), the server may not have received that client's plan definitions — in that case it would be reasonable to fall back to repo-level aggregation only, or to update the docs to suggest also granting Read Config for full plan cards