Currently proxmox-backup-client is a stateless, outbound-only CLI, and PBS operates
purely as a passive storage endpoint. For non-PVE / standalone Linux
hosts, backups must be scheduled locally per-host (e.g. cron or systemd
timers). This creates operational gaps:
- No central control or unified view of backup schedules across hosts.
- No central task log visibility for non-PVE client backups.
- No proactive alerting when a host fails to run an expected backup
(a crashed host or a dead timer produces no signal at all).
I was wondering if anybody else runs backups at scale with PBS for regular
Linux machines (non PBS) and how do they solve this.
If I'm not missing anything, there might be space for improvement and I can visualize
two possible options.:
Proposed shared component: client agent
---------------------------------------
Both options below rely on a small, optional agent service running on
target Linux hosts. The agent authenticates an incoming request from a
central manager and invokes proxmox-backup-client locally. The existing
CLI remains the execution engine; the agent only dispatches jobs and
reports status and logs back to the manager.
Option A: manager integrated into PBS / PDM
-------------------------------------------
Extend PBS (or PDM) to act as the central manager.
- PBS/PDM stores job objects for standalone clients (target host,
source paths, schedule, retention, namespace, notifications).
- PBS/PDM triggers jobs on remote agents and ingests results.
- Task results and logs surface via the existing PBS/PDM API and UI.
Option B: separate standalone manager
-------------------------------------
Keep the PBS/PDM codebase unchanged and build a separate manager.
- Uses the identical client agent from Option A on target hosts.
- Handles scheduling, central log aggregation (troubleshooting), and
compliance (were the last tasks successful / did every host meet its
SLA window).
- Interacts with PBS strictly via existing public APIs.
The architectural decision is strictly where the manager lives (PBS/PDM
integration vs. a separate product); the client agent is identical in
both.
Questions for the forum
----------------------
1. Is central scheduling for standalone clients desirable inside
PBS/PDM (Option A), or is a separate manager preferred (Option B)?
2. Does an optional lightweight client agent align with Proxmox's
architectural vision for standalone host backups?
3. Are there existing design initiatives or preferred patterns for
remote execution in the ecosystem this should align with?
purely as a passive storage endpoint. For non-PVE / standalone Linux
hosts, backups must be scheduled locally per-host (e.g. cron or systemd
timers). This creates operational gaps:
- No central control or unified view of backup schedules across hosts.
- No central task log visibility for non-PVE client backups.
- No proactive alerting when a host fails to run an expected backup
(a crashed host or a dead timer produces no signal at all).
I was wondering if anybody else runs backups at scale with PBS for regular
Linux machines (non PBS) and how do they solve this.
If I'm not missing anything, there might be space for improvement and I can visualize
two possible options.:
Proposed shared component: client agent
---------------------------------------
Both options below rely on a small, optional agent service running on
target Linux hosts. The agent authenticates an incoming request from a
central manager and invokes proxmox-backup-client locally. The existing
CLI remains the execution engine; the agent only dispatches jobs and
reports status and logs back to the manager.
Option A: manager integrated into PBS / PDM
-------------------------------------------
Extend PBS (or PDM) to act as the central manager.
- PBS/PDM stores job objects for standalone clients (target host,
source paths, schedule, retention, namespace, notifications).
- PBS/PDM triggers jobs on remote agents and ingests results.
- Task results and logs surface via the existing PBS/PDM API and UI.
Option B: separate standalone manager
-------------------------------------
Keep the PBS/PDM codebase unchanged and build a separate manager.
- Uses the identical client agent from Option A on target hosts.
- Handles scheduling, central log aggregation (troubleshooting), and
compliance (were the last tasks successful / did every host meet its
SLA window).
- Interacts with PBS strictly via existing public APIs.
The architectural decision is strictly where the manager lives (PBS/PDM
integration vs. a separate product); the client agent is identical in
both.
Questions for the forum
----------------------
1. Is central scheduling for standalone clients desirable inside
PBS/PDM (Option A), or is a separate manager preferred (Option B)?
2. Does an optional lightweight client agent align with Proxmox's
architectural vision for standalone host backups?
3. Are there existing design initiatives or preferred patterns for
remote execution in the ecosystem this should align with?
