so that we can get a 'tar.zst' from proxmox-file-restore by passing
'--format tar --zstd' to the file-restore binary
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
under some conditions, like when calling it in the api where we have
a 30s pveproxy limit, we want to make use of the '--timeout' parameter
of the file-restore binary, but we may want to call it in the future
where we don't want add timeout.
To achieve that, add an extendable 'extra_params' hash parameter to
'file_restore_list' and use the timeout from there.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
Instead, use the one from the initial configuration. The only current
caller is in PMG and the namespace parameter set there agrees with
the one from the initial configuration, so this is not actually a
breaking change.
Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
All existing callers for functions with namespaced parameters just
re-use the one that's passed in via the initial configuration already,
so there is no need for namespaced parameters currently.
If the need for one PBS client to handle multiple namespaces arises, a
set_namespace() function could be added, or the relevant functions
could take an additional parameter, either for just the namespace or
like $cmd_opts in restore_pxar().
Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
For get_snapshots(), also set the default when no namespaced parameter
is present at all.
This would break any callers that have a namespace in the initial
config and explicitly don't set it for a later call, but the only
such caller is restore_pxar() in PMG, which /should/ be using the
namespace!
In other words, this implicitly fixes the restore_pxar() call in PMG
and avoids the need to extract the namespace from the configuration
(which already is present in the client) on the call site for all
functions that currently take a namespaced parameter.
Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
Otherwise, there will be
Result: {
"data": null
}
when calling via a CLI tool for example. This also makes it consistent
with PVE in preparation to switch to using PBSClient there.
Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
It's currently possible to add a remote in PMG without password (via
API), but deletion of such a remote would fail here.
Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
*_prepare creates a fifo for streaming data back to clients directly,
filefile_restore_extract blocks and should be called from a background
worker - while it is running outcoming data can be read from the FIFO.
Signed-off-by: Stefan Reiter <s.reiter@proxmox.com>
More helpful for a user to know what they're missing.
Suggested-by: Dominic Jäger <d.jaeger@proxmox.com>
Signed-off-by: Stefan Reiter <s.reiter@proxmox.com>
PBSClient.pm contains methods for:
* handling (sensitive) config-information (passwords, encryption keys)
* creating/restoring/forgetting/listing backups
code is mostly based on the current PBSPlugin in pve-storage
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
