Unfortunately that suspicion was moot.
It seems the final decision is made in backup-manager-purge and one
difference seems to be that the md5 file doesn't have a "master":
# we can outdate a master only if a younger master exists
if ($data->{master}) {
foreach my $master_date (
keys %{$g_rh_archives->{$data->{name}}{pathByDateMasters}}) {
if ($master_date > $data->{date}) {
#> This is where none of the other files get pushed since master_date ==
$date->{date}
push @{$ra_outdated}, $archive;
last;
}
}
}
# here the archive is deprecated, its date is < to $purge_date
else {
# if BM_ARCHIVE_STRICTPURGE is true, we can only purge
# an archive prefixed with BM_ARCHIVE_PREFIX
next if (($ENV{BM_ARCHIVE_STRICTPURGE} eq "true") and
($data->{prefix} ne $ENV{BM_ARCHIVE_PREFIX}));
# now, we're sure we can outdate the archive
push @{$ra_outdated}, $archive;
#> This is where the md5 file gets pushed
}
So currently I'm still wondering on whether some analog date check
should be added when no master exists, or whether the date check against
the master could possibly be bogus.
But I'm also starting to believe that the issue really only manifests
since the weekly backup (which requires these master checks) is paired
with a TTL of merely 2 days. The intent is to insure that the backup is
done automatically at least once a week, but only 2 sets of archives
should be retained due to space constraints. But I guess that cannot be
be expressed correctly.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1257262
Title:
backup-manager is not removing the correct files
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/backup-manager/+bug/1257262/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
