public inbox for pbs-devel@lists.proxmox.com
 help / color / mirror / Atom feed
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



             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
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal