public inbox for pve-devel@lists.proxmox.com
 help / color / mirror / Atom feed
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 :)




  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal