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. _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
