[pbs-devel] [PATCH proxmox-backup 1/4] api2: make remote for sync-jobs optional

Thomas Lamprecht t.lamprecht at proxmox.com
Wed Feb 15 12:40:31 CET 2023

Am 14/02/2023 um 15:33 schrieb Fabian Grünbichler:
> On February 13, 2023 4:45 pm, Hannes Laimer wrote:
>> ... and update places where it is used.
>> A SyncJob not having a remote means it is pulling
>> from a local datastore.
> high level: I wonder whether we really need this for sync jobs, or whether just
> having it for pull (or as a new API/CLI endpoint copy/move?) would be enough as
> a start? is there a use case for scheduled local syncing?

Yes, e.g. existing ones could be: having a small and fast "incoming" datastore,
which avoids blocking guests on backups and has the "hot" set of snapshots (most
recent) available while using a slower, but huge second one for long term archival.

Future ones would be sync to a S3 backed object storage, which we probably only
want to have done from existing data (similar to tape), but still avoid the media
catalogue and labelling overhead tape must have to be really useful.

Another future one is removable datastores, which this is upfront work for. While
we might not always have time trigged event there, its still useful to have use a
sync job for, e.g., hot-plug triggered events.

Besides that, I'm a bit reserved against adding a move that can cross datastore
boundaries, as doing that manually seems not that useful for any but the smallest
PBS instances (especially on the snapshot level) and for others a sync + prune
is normally better anyway. Moving groups and namespaces around in the same datastore
OTOH would be useful for organizing purpose, and without crossing into another CAS
also simple to implement.

More information about the pbs-devel mailing list