From: Thomas Lamprecht <t.lamprecht@proxmox.com>
To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>,
Fabian Ebner <f.ebner@proxmox.com>
Subject: Re: [pve-devel] [PATCH storage 2/2] plugins: allow limiting the number of protected backups per guest
Date: Wed, 16 Mar 2022 17:42:09 +0100 [thread overview]
Message-ID: <0df19ffc-a685-1605-89ea-2f288aba26da@proxmox.com> (raw)
In-Reply-To: <20211216121233.162288-3-f.ebner@proxmox.com>
On 16.12.21 13:12, Fabian Ebner wrote:
> The ability to mark backups as protected broke the implicit assumption
> in vzdump that remove=1 and current number of backups being the limit
> (i.e. sum of all keep options) will result in a backup being removed.
>
> Introduce a new storage property 'max-protected-backups' to limit the
> number of protected backups per guest. Use 5 as a default value, as it
> should cover most use cases, while still not having too big of a
> potential overhead in many scenarios.
>
> For external plugins that do not return the backup subtype in
> list_volumes, all protected backups with the same ID will count
> towards the limit.
>
> An alternative would be to count the protected backups when pruning.
> While that would avoid the need for a new property, it would break the
> current semantics of protected backups being ignored for pruning. It
> also would be less flexible, e.g. for PBS, it can make sense to have
> both keep-all=1 and a limit for the number of protected snapshots on
> the PVE side.
>
> Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
> ---
> PVE/Storage.pm | 24 ++++++++++++++++++++++++
> PVE/Storage/BTRFSPlugin.pm | 3 ++-
> PVE/Storage/CIFSPlugin.pm | 1 +
> PVE/Storage/CephFSPlugin.pm | 1 +
> PVE/Storage/DirPlugin.pm | 1 +
> PVE/Storage/GlusterfsPlugin.pm | 1 +
> PVE/Storage/NFSPlugin.pm | 1 +
> PVE/Storage/PBSPlugin.pm | 1 +
> PVE/Storage/Plugin.pm | 7 +++++++
> 9 files changed, 39 insertions(+), 1 deletion(-)
>
> diff --git a/PVE/Storage.pm b/PVE/Storage.pm
> index d64019f..0643fad 100755
> --- a/PVE/Storage.pm
> +++ b/PVE/Storage.pm
> @@ -232,6 +232,30 @@ sub update_volume_attribute {
> my $scfg = storage_config($cfg, $storeid);
> my $plugin = PVE::Storage::Plugin->lookup($scfg->{type});
>
> + my ($vtype, undef, $vmid) = $plugin->parse_volname($volname);
> + my $max_protected_backups = $scfg->{'max-protected-backups'} // 5;
maybe the default limit should be user privilege dependent? E.g., for root and users
with .Allocate on the storage it wouldn't be a problem to have unlimited (or a higher
count) as default? I mean, it's naturally a bit odd to differ, but one can argue a lot
with auto-magic-convenience ;P
> +
> + if (
> + $vtype eq 'backup'
> + && $vmid
> + && $attribute eq 'protected'
> + && $value
> + && !$plugin->get_volume_attribute($scfg, $storeid, $volname, 'protected')
> + && $max_protected_backups > -1 # -1 is unlimited
> + ) {
> + my $backups = $plugin->list_volumes($storeid, $scfg, $vmid, ['backup']);
> + my ($backup_type) = map { $_->{subtype} } grep { $_->{volid} eq $volid } $backups->@*;
> +
> + my $protected_count = grep {
> + $_->{protected} && (!$backup_type || ($_->{subtype} && $_->{subtype} eq $backup_type))
> + } $backups->@*;
> +
> + if ($max_protected_backups <= $protected_count) {
> + die "The number of protected backups per guest is limited to $max_protected_backups ".
> + "on storage '$storeid'\n";
> + }
> + }
> +
> return $plugin->update_volume_attribute($scfg, $storeid, $volname, $attribute, $value);
> }
next prev parent reply other threads:[~2022-03-16 16:42 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-16 12:12 [pve-devel] [PATCH-SERIES storage/manager/guest-common/docs] improvements for protected backups Fabian Ebner
2021-12-16 12:12 ` [pve-devel] [PATCH storage 1/2] list volumes: also return backup type for backups Fabian Ebner
2022-03-16 16:42 ` [pve-devel] applied: " Thomas Lamprecht
2021-12-16 12:12 ` [pve-devel] [PATCH storage 2/2] plugins: allow limiting the number of protected backups per guest Fabian Ebner
2022-03-16 16:42 ` Thomas Lamprecht [this message]
2022-03-17 8:03 ` Fabian Ebner
2022-03-17 8:11 ` Thomas Lamprecht
2021-12-16 12:12 ` [pve-devel] [PATCH manager 1/6] vzdump: backup file list: drop unused parameter Fabian Ebner
2021-12-16 12:12 ` [pve-devel] [PATCH manager 2/6] vzdump: backup limit: only count unprotected backups Fabian Ebner
2021-12-16 12:12 ` [pve-devel] [RFC manager 3/6] ui: storage edit: retention: add max-protected-backups setting Fabian Ebner
2021-12-16 12:12 ` [pve-devel] [RFC manager 4/6] ui: storage creation: retention: dynamically adapt max-protected-backups Fabian Ebner
2021-12-16 12:12 ` [pve-devel] [PATCH docs 1/2] storage: switch to prune-backups in examples Fabian Ebner
2021-12-16 12:12 ` [pve-devel] [PATCH docs 2/2] vzdump/storage: mention protected backups limit and give an example Fabian Ebner
2021-12-16 12:12 ` [pve-devel] [PATCH guest-common 1/1] vzdump: schema: add 'notes' and 'protected' properties Fabian Ebner
2022-03-16 11:04 ` Fabian Ebner
2022-03-16 18:25 ` Thomas Lamprecht
2022-03-17 7:57 ` Fabian Ebner
2022-03-17 8:07 ` Thomas Lamprecht
2022-03-17 8:18 ` Fabian Ebner
2022-03-17 8:20 ` Thomas Lamprecht
2021-12-16 12:12 ` [pve-devel] [PATCH manager 5/6] vzdump: support setting protected status and notes Fabian Ebner
2021-12-16 12:12 ` [pve-devel] [PATCH manager 6/6] ui: backup: allow setting protected and notes for manual backup Fabian Ebner
2021-12-20 10:31 ` [pve-devel] [PATCH-SERIES storage/manager/guest-common/docs] improvements for protected backups Dominik Csapak
2021-12-21 15:11 ` Thomas Lamprecht
2021-12-22 7:02 ` Dominik Csapak
2022-01-03 9:12 ` Fabian Ebner
2022-03-10 7:46 ` Fabian 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=0df19ffc-a685-1605-89ea-2f288aba26da@proxmox.com \
--to=t.lamprecht@proxmox.com \
--cc=f.ebner@proxmox.com \
--cc=pve-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