From: Ciro Iriarte <cyruspy@gmail.com>
To: pbs-devel@lists.proxmox.com
Subject: [RFC] Centralized management for standalone PBS file clients
Date: Sun, 09 Aug 2026 12:41:48 -0700 (PDT) [thread overview]
Message-ID: <6a78d7fc.4987c784.356268.046f@mx.google.com> (raw)
Hi all,
This is a proposal for discussion (not a patch). 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).
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 list
----------------------
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?
Happy to prototype whichever direction the maintainers consider viable.
Thanks,
Ciro Iriarte
next reply other threads:[~2026-08-09 19:42 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-09 19:41 Ciro Iriarte [this message]
2026-08-10 7:45 ` [RFC] Centralized management for standalone PBS file clients Christian Ebner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6a78d7fc.4987c784.356268.046f@mx.google.com \
--to=cyruspy@gmail.com \
--cc=pbs-devel@lists.proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox