[pve-devel] [RFC manager 1/1] vzdump: skip protected backups for dumpdir pruning

Fabian Ebner f.ebner at proxmox.com
Fri Sep 17 15:02:27 CEST 2021

Keeps the behavior consistent with what happens for storages. It also
is required to not get into conflict with the check in archive_remove,
i.e. pruning here marks a backup as 'remove' and then archive_remove
complains that it's protected.

Signed-off-by: Fabian Ebner <f.ebner at proxmox.com>

I'm noticing now that old manager + new storage will still have the
problem with the added protection check in archive_remove. Is that
considered to be breaking? Can only be triggered by making use of
the new feature (or if .protected files were already present...),
but it would potentially affect scenarios where
    vzdump --storage name
    vzdump --dumpdir /path/for/name/dump
are used in parallel.

Dependency bump for pve-storage needed.

 PVE/VZDump.pm | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/PVE/VZDump.pm b/PVE/VZDump.pm
index d00be8b2..a5a956c8 100644
--- a/PVE/VZDump.pm
+++ b/PVE/VZDump.pm
@@ -992,6 +992,13 @@ sub exec_backup_task {
 	    my $pruned = 0;
 	    if (!defined($opts->{storage})) {
 		my $bklist = get_backup_file_list($opts->{dumpdir}, $bkname);
+		for my $prune_entry ($bklist->@*) {
+		    if (-e PVE::Storage::protection_file_path($prune_entry->{path})) {
+			$prune_entry->{mark} = 'protected';
+		    }
+		}
 		PVE::Storage::prune_mark_backup_group($bklist, $prune_options);
 		foreach my $prune_entry (@{$bklist}) {

More information about the pve-devel mailing list