[pve-devel] [PATCH-SERIES storage/manager/guest-common/docs] improvements for protected backups

[Fabian Ebner]

Am 12/22/21 um 08:02 schrieb Dominik Csapak:
> 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...
>>>

Sorry about the lack of information. Of course the "why?" should be 
covered in the cover letter, and in storage 2/2, I should've made 
explicit what the implication of the broken assumption is/why the new 
property helps.

>>
>> 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 :)
>