From: Dominik Csapak <d.csapak@proxmox.com>
To: Thomas Lamprecht <t.lamprecht@proxmox.com>,
Proxmox VE development discussion <pve-devel@lists.proxmox.com>,
Fabian Ebner <f.ebner@proxmox.com>
Subject: Re: [pve-devel] [PATCH-SERIES storage/manager/guest-common/docs] improvements for protected backups
Date: Wed, 22 Dec 2021 08:02:35 +0100 [thread overview]
Message-ID: <3b71e3e3-0a21-2ec1-eff2-08ab59966a25@proxmox.com> (raw)
In-Reply-To: <c4276c52-cb7d-d83e-a8e7-bab7646460de@proxmox.com>
On 12/21/21 16:11, Thomas Lamprecht wrote:
> On 20/12/2021 11:31, Dominik Csapak wrote:
>> what do we gain by having a limit on the number of protected backups?
>
> We avoid allowing users to create an infinite number of backups.
>
> Remember that unprotected backups do not count towards the keep-X retention
> parameters as they are considered a specially marked snapshot outside the
> regular schedule, and doing so could lead to situations where no new backup
> can be made (if sum of keep-X == sum of protected backups), which can be
> pretty bad.
>
> Now, if a admin wants to limit the amount of backups a user can make of the
> VMs those users own, the admin sets now keep-X (which superseded max-backups)
> The sum of all keep-X is always the maximal, total amount of backups that can
> be made, but if the user marks every new backup immediately as protected they
> can overstep that limit arbitrarily, this series addresses that while not
> breaking backward comparability.
>
>>
>> storage 2/2 mentions that protection broke some assumption of vzdump
>> which is (somehow? not really explained imho) fixing it?
>>
>> if it's not fixing it, what is the relation between those things?
>>
>> also, why have a 'magic' -1 value that means indefinite, we could
>> simply always have that behavior?
>>
>> in my opinion, it makes no sense to limit the number of protected
>> backups..
>
> see above, having the whole picture should bring sense to this..
>
>>
>> if it is necessary for some reason, it would be good to include
>> that reason either in the commit message, or at least in the cover
>> letter...
>>
>
> I mean while the cover letter only hints it, commit message from the storage
> 2/2 patch is pretty clear to me.. FWIW, this was discussed quite extensively
> between Fabian E. and myself, and that result was further discussed with Fabian G.
> off-list.
OK, i get it now (also talked with fabian g. off-list).
i did not conclude from the storage 2/2 patch that
it implements an upper limit of backups, so i was confused.
Thanks :)
next prev parent reply other threads:[~2021-12-22 7:02 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-16 12:12 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
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 [this message]
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=3b71e3e3-0a21-2ec1-eff2-08ab59966a25@proxmox.com \
--to=d.csapak@proxmox.com \
--cc=f.ebner@proxmox.com \
--cc=pve-devel@lists.proxmox.com \
--cc=t.lamprecht@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal