Comment 3 for bug 1257262

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.