If neither the 'remove' option of vzdump nor the 'maxfiles' option in
the storage config are set, assume a value of 0, i.e. do not delete
anything and allow unlimited backups.
Restores previous behaviour that was broken in e6946086e3.
Also fixes a warning about using '== 0' on a non-number type.
Signed-off-by: Stefan Reiter <s.reiter@proxmox.com>
fixes commit f354fe47fc, which changed
the logic to the newer storage prune helpers, but those are designed
in the spirits of PBS, with a keep-option not set meaning to keep
none.
This does not respects the storage special handling of maxfiles.
While in the API/CLI that option must be > 0m in can be zero when set
in a storage configuration entry, and then it means keep all. So, set
the internal remove option to false if that special condition is met.
This would have been a clearer, and less prone to changes,
implementation to begin with.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
The assumption that they already are sorted is no longer valid,
because of the IDs for non-existent guests.
Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
Like this, there will be a backup task (within the big worker task)
for such IDs, which will then visibly (i.e. also visible in the
notification mail) fail with, e.g.:
unable to find VM '123'
In get_included_guests, the key '' was chosen for the orphaned IDs,
because it cannot possibly denote a nodename.
Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
Commit 1a87db9e56 introduced
a usage of plugin before the truthiness check for plugin.
At the moment it might not be possible to trigger this anymore,
because of the guest inclusion rework that happened later on.
But to make tasks for inexistent guest IDs visibly fail again,
this check will be necessary. Also, to get the error message in
the mail, it needs to fail inside the eval block.
Thus, keep the check in the eval block and move the block of code
using the plugin to below the check.
Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
this fixes an issue where a rogue running backup would upload the vm
config of a later backup in a backup job
instead now that directory gets deleted and the config is not
available anymore
we cannot really keep those directories around until the end of the
backup job, since we temporarily save ct contents there, which could get
large very fast
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
For the use case with '--dumpdir', it's not possible to call prune_backups
directly, so a little bit of special handling is required there.
Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
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>
At this point, the VMIDs are already numerically sorted by the
PVE::VZDump::check_vmids method. Calling another sort on the array,
especially without `{$a <=> $b}`, resulted in reordering the array
alphabetically.
Signed-off-by: Aaron Lauterer <a.lauterer@proxmox.com>
instead of always using the default hard-coded one.
otherwise, suspend mode container backups might run out of space even though the admin configured a big enough tmpdir.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
The renaming of tarfile to target in 6cba1855d8
can break existing vzdump hook scripts of users.
by setting the TARFILE variable in addition to TARGET the scripts will continue
to work.
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
This will fix the behaviour when calling `vzdump --stop` to cause all
local guests to be backed up.
When refactoring this logic in commit df5875b4, the assumption was that
every call will have one of the following parameters set: pool, list of
VMIDs or all (intentional or when exclude is used).
There is an addtional possibility, that vzdump is called with only
--stop. Thus there are no other parameters that would indicate which
VMIDs to include.
In this case we want to return the empty hash.
Signed-off-by: Aaron Lauterer <a.lauterer@proxmox.com>
Even now we can have plain vma files which, while an archive, are not
a TARfile.
Use the generic (backup) target as key instead. Makes it less
confusing to be reused for PBS in a later patch.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
No functional change is intended.
The preference order is: option, then storage config, then vzdump defaults.
Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
The `guest include` logic handling `all` and `exclude` parameters was in
the `PVE::VZDump->exec_backup()` method. Moving this logic into the
`get_included_guests` method allows us to simplify and generalize it.
This helps to make the overall logic easier to test and develop other
features around vzdump backup jobs.
The method now returns a hash with node names as keys mapped to arrays
of VMIDs on these nodes that are included in the vzdump job.
The VZDump API call to create a new backup is adapted to use the new
method to create the list of local VMIDs and the skiplist.
Permission checks are kept where they are to be able to handle missing
permissions according to the current context. The old behavior to die
on a backup job when the user is missing the permission to a guest and
the job is not an 'all' or 'exclude' job is kept.
Signed-off-by: Aaron Lauterer <a.lauterer@proxmox.com>
As a first step to make the whole guest include logic more testable the
part from the API endpoint has been moved to its own method with as
little changes as possible.
Everything concerning `all` and `exclude` logic is still in the
PVE::VZDump->exec_backup() method.
Signed-off-by: Aaron Lauterer <a.lauterer@proxmox.com>
this unifies the logic into a single place instead of all over this
module and the plugins.
it also fixes tons of 'uninitialized value' warnings when backing up
with --dumpdir but no --storage set, since the existing conditions for
PBS targets are missing a definedness check.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
This patch adds the zstd to the compression selection for backup on the
GUI and add .zst to the backup file filter. Including zstd as package
install dependency.
Signed-off-by: Alwin Antreich <a.antreich@proxmox.com>
When creating a backup the log part can make the mail too big to be
transferred. To ensure delivery, two measures are taken:
1. Always omit the status lines
2. Omit the whole log part if a mail becomes (too) big
Additionally, add a check for missing log files.
Co-developed-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Signed-off-by: Dominic Jäger <d.jaeger@proxmox.com>
This moves the cfs register code for vzdump.cron to the
pve-guest-common package. Therefore, it relies on the corresponding
patches in pve-guest-common and pve-docs as build dependencies.
Signed-off-by: Christian Ebner <c.ebner@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
make the message a bit more informative (with help from thomas), namely
mentioning the ability to change/increase the limit.
Signed-off-by: Oguz Bektas <o.bektas@proxmox.com>
This refactors things a bit to avoid having the same two lines in 3
places and allows the plugin to set the "guest was resumed" time
stamp at the point it really was resumed, not only once the backup
completed (see #503). Further, if a plugin prints it's own
"resumed/running after X seconds" message, it can unset the vmstop
time and thus avoid printing the message twice.
related to a fix for #503
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
