[pbs-devel] [PATCH v2 proxmox-backup] fix #2996: client: allow optional match patterns for restore
Fabian Grünbichler
f.gruenbichler at proxmox.com
Fri May 24 12:21:01 CEST 2024
On April 30, 2024 5:58 pm, Christian Ebner wrote:
> When the user is only interested in a subset of the entries stored in
> a file-level backup, it is convenient to be able to provide a list of
> match patterns for the entries intended to be restored.
>
> The required restore logic is already in place. Therefore, expose it
> for the `proxmox-backup-client restore` command by adding the optional
> array of patterns as command line argument and parse these before
> passing them via the pxar restore options to the archive extractor.
>
> Link to bugtracker issue:
> https://bugzilla.proxmox.com/show_bug.cgi?id=2996
>
> Signed-off-by: Christian Ebner <c.ebner at proxmox.com>
> Tested-by: Gabriel Goller <g.goller at proxmox.com>
> ---
> Changes since version 1:
> - bail when `matches` are used in combination with restore to stdout
> - fix typo in commit title
>
> proxmox-backup-client/src/main.rs | 31 +++++++++++++++++++++++++++++--
> 1 file changed, 29 insertions(+), 2 deletions(-)
>
> diff --git a/proxmox-backup-client/src/main.rs b/proxmox-backup-client/src/main.rs
> index 32fe914c4..08582c86d 100644
> --- a/proxmox-backup-client/src/main.rs
> +++ b/proxmox-backup-client/src/main.rs
> @@ -1186,6 +1186,15 @@ We do not extract '.pxar' archives when writing to standard output.
>
> "###
> },
> + "matches": {
> + type: Array,
> + description: "Only restore entries matching given paths or patterns.",
> + optional: true,
> + items: {
> + type: String,
> + description: "Path or match pattern.",
> + },
> + },
in `pxar extract`, we call this "pattern" with the following:
pattern: {
description: "List of paths or pattern matching files to restore",
type: Array,
items: {
type: String,
description: "Path or pattern matching files to restore.",
},
optional: true,
},
do we maybe want to copy that wording/name? do we have other places
where patterns are used for inclusion that we could unify?
would it make sense to create an API type for this, or at least add some
sort of schema-based validation up front (e.g., empty strings are not
valid, but also trailing back slashes, and I don't know what else ;))?
> rate: {
> schema: TRAFFIC_CONTROL_RATE_SCHEMA,
> optional: true,
> @@ -1306,6 +1315,24 @@ async fn restore(
> let target = json::required_string_param(¶m, "target")?;
> let target = if target == "-" { None } else { Some(target) };
>
> + let mut match_list = Vec::new();
> + if let Some(patterns) = param["matches"].as_array() {
> + if target.is_none() {
> + bail!("matches not allowed when restoring to stdout");
> + }
> +
> + for pattern in patterns {
> + if let Some(pattern) = pattern.as_str() {
> + let match_entry = MatchEntry::parse_pattern(
> + pattern,
> + PatternFlag::PATH_NAME,
> + MatchType::Include
> + )?;
> + match_list.push(match_entry);
> + }
> + }
> + };
> +
> let crypto = crypto_parameters(¶m)?;
>
> let crypt_config = match crypto.enc_key {
> @@ -1429,8 +1456,8 @@ async fn restore(
> }
>
> let options = pbs_client::pxar::PxarExtractOptions {
> - match_list: &[],
> - extract_match_default: true,
> + match_list: match_list.as_slice(),
nit: we don't really use as_slice to convert Vecs to slices when passing
them to another fn ;) a simple `&` does the job as well (because &Vec
derefs to &[]).
> + extract_match_default: match_list.is_empty(),
> allow_existing_dirs,
> overwrite_flags,
> on_error,
> --
> 2.39.2
>
>
>
> _______________________________________________
> pbs-devel mailing list
> pbs-devel at lists.proxmox.com
> https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel
>
>
>
More information about the pbs-devel
mailing list