]> git.proxmox.com Git - pve-manager.git/commit
Allow prune-backups as an alternative to maxfiles
authorFabian Ebner <f.ebner@proxmox.com>
Tue, 29 Sep 2020 08:37:04 +0000 (10:37 +0200)
committerThomas Lamprecht <t.lamprecht@proxmox.com>
Wed, 30 Sep 2020 08:56:30 +0000 (10:56 +0200)
commite6946086e3588b9c33bf7a0c572ae8f5d7b4e101
treeea1e01327ffd8a5c945ba1ce3b948b81d1c0ac8c
parent5c51bb267c42bb77e48f91a95d4d588aa2757d74
Allow prune-backups as an alternative to maxfiles

and make the two options mutally exclusive as long
as they are specified on the same level (e.g. both
from the storage configuration). Otherwise prefer
option > storage config > default (only maxfiles has a default currently).

Defines the backup limit for prune-backups as the sum of all
keep-values.

There is no perfect way to determine whether a
new backup would trigger a removal with prune later:
1. we would need a way to include the not yet existing backup
   in a 'prune --dry-run' check.
2. even if we had that check, if it's executed right before
   a full hour, and the actual backup happens after the full
   hour, the information from the check is not correct.

So in some cases, we allow backup jobs with remove=0, that
will lead to a removal when the next prune is executed.
Still, the job with remove=0 does not execute a prune, so:
1. There is a well-defined limit.
2. A job with remove=0 never removes an old backup.

Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
PVE/API2/VZDump.pm
PVE/VZDump.pm