On Tue, Jul 22, 2025 at 10:06 PM Adam Goryachev via BackupPC-users < backuppc-users@lists.sourceforge.net> wrote:
> > This is not what I saw. I let the problem host get up to 8 days without > a backup before I realized we had a problem and I had to start manually > queueing a backup every couple days. Backuppc appeared to be grabbing > whatever was at the top of the queue, not whatever had the least-recent > last backup. > > Now that I'm no longer on MaxBackups=1, most backups are > completed early in the day so by the time I get to my desk the Current > Queue is mostly empty, and harder to observe what its behaviour is. > > I think you can validate the behavior easily by viewing the queue page. At > each wakeup time, all hosts are added to the queue, seemingly in > alphabetical order. > > If there is a spare "backup slot" ie, MaxBackups is > currently in > progress, then a host is taken from the top of the queue, and evaluated > whether a backup should start or not (blackout period, last backup time, > etc) > > Repeat the above, until backups in progress == MaxBackups, then pause and > do not continue to process the queue until a backup completes > Yes, this is pretty much what I saw. > So, if your host is sorted later in the list, and you are unable to > complete all backups during the backup window, then the host will indeed > never be backed up. > I'd like to reiterate that the "backup window" for most hosts is 24 hours long. There was just the one host with a narrow window., > There is a valid reason to sort the queue for "oldest" backup, however, > this may simply break someone else's workflow, for example, schedule the > important host to have a backup every hour, and some other host to backup > once a week, so the "oldest" is the once a week, even though it isn't > really due. > Yeah, this is why I suggested the other option, which is to skip but not remove hosts from the queue that are due for backup but blocked by their blackout period. They'd filter to the top of the list by the time their blackout period ends, and then immediately get backed up. In your case, the suggestions would be: > 1) Make sure all backups can be completed within the backup window allowed. > They can be. > 2) Consider adding more wake up times, including at or close to midnight > I'm using the default: 23 wakeups per day. > 3) Consider adding blackout windows to your other hosts to allow this one > to complete at the 1am window first, and other hosts can only start at the > next window after 1am. > That's not a bad workaround, actually... make it so that nothing else can be backed up during the first two wakeups. > 4) Enable monitoring so that hosts with backups that are too old are > notified so that you can resolve the issue, instead of finding out later > after some potential failure > Yeah... if I thought I'd have this problem regularly that'd be near the top of my list. As it is, it's already on my list, just waaay down there below all the actual fires. :) That said, it would help if BackupPC_serverMesg was documented a little more completely. There are some basics in the docs, but it takes reading the code to know what it's actually able to do. Thanks for the reply.
_______________________________________________ BackupPC-users mailing list BackupPC-users@lists.sourceforge.net List: https://lists.sourceforge.net/lists/listinfo/backuppc-users Wiki: https://github.com/backuppc/backuppc/wiki Project: https://backuppc.github.io/backuppc/
