Long running job - scheduled backups build up?

Running 2.0.2.1_beta_2017-08-01

I have noticed this a couple times now. My normal backup schedule is every 4 hours. I notice that when I add a large folder to back up that takes say 24 hours, after it completes several more backups will run in immediate succession, one after another.

It appears that the scheduled backups build up if a job is already in progress. I’d rather see a scheduled backup just be skipped if a job is already in progress. Is there a way to achieve that? Or is this a bug?

As I understand it you should got no more than one “immediate succession” of a particular job. Of course if you have 4 different jobs all of which missed their scheduled start time you’d likely see 4 “immediate succession” runs…

Here’s a description of how the schedule works with the most salient line being "Duplicati will first check if it is already in the queue, and if so, just not put it in there". Please let us know if you’re not seeing this in action.

Nope, that is not what I’m seeing. I have only one backup job scheduled. The attached screen shot shows the email reports I get after jobs complete. I added a large folder after the Monday 3:18pm backup completed. The next backup didn’t complete until Tue 11:12pm but then you can see it immediately ran 3 more jobs in quick succession after that completed before resuming the normal every 4h schedule.

Capture

Thanks for the verification. IIRC there was another person who reported this type of issue but then it went away or something (I forget) - but it sounds to me like there’s an edge case that is allowing this to happen.

Hopefully @kenkendk will have some insight…

Unfortunately not. It should just queue one backup, I don’t know why there are multiple backups being queue…

Is there a way (command line or GUI) to see what’s in the queue? (I think this has been asked before but I couldn’t find it in the forum.)

It should show up on the “About” page and then “system info”, there is a line there that shows the current scheduler queue.

2 Likes

I’ll check that next time I have a long-running job.

Got it, thanks!

So in looking at my About -> System Info I see “proposedSchedule” which looks to be what I’m expecting.

Should I care about “schedulerQueueIds”?

Server state properties

lastEventId : 1768
...
proposedSchedule : [{"Item1":"1","Item2":"2017-12-12T08:22:00Z"}]
schedulerQueueIds : []
...

The proposedSchedule is the “not yet in queue, but expected to be put in queue at …” list. In other words, this is the list of all backups with a schedule attached, and the timestamp is the next time they should run.

The schedulerQueueIds is the list of items currently in the queue.

The should also be one called active or similar that has the ID of the currently running task (if any).

1 Like

I’ve a similar problem with 2.0.2.16_canary_2018-01-18:
My System Info:
activeTask : {“Item1”:35,“Item2”:“4”}
proposedSchedule : [{“Item1”:“3”,“Item2”:“2018-01-27T12:00:00Z”},{“Item1”:“4”,“Item2”:“2018-01-27T12:00:00Z”},{“Item1”:“5”,“Item2”:“2018-01-27T12:00:00Z”},{“Item1”:“1”,“Item2”:“2018-01-29T12:00:00Z”},{“Item1”:“2”,“Item2”:“2018-01-30T12:00:00Z”}]
schedulerQueueIds : [{“Item1”:36,“Item2”:“5”},{“Item1”:37,“Item2”:“1”},{“Item1”:38,“Item2”:“2”},{“Item1”:39,“Item2”:“3”}]

How do I interpret the different fields? Seems to look broken!?

Regards,
Sebastian

I believe it’s showing:

  • job ID 4 is currently running
  • jobs 5, 1, 2, and 3 are directly queued up in that order
  • jobs 3, 4, and 5 are all scheduled to start at noon on the 27th (meaning 3 will start then 4 and 5 directly queued up after it)
  • job 1 is scheduled to start at noon on the 29th
  • job 2 is scheduled to start at noon on the 30th

Thanks for the explanation. I thought Item1 and Item2 are the internal names for the jobs.

I can see that being confusing.

Duplicati has a loot of powerful features, and while the user interface has made huge strides lately it’s still a bit rough around the edges.

In case you care, this particular edge is showing information formatted as JSON (a fairly common thing these days) so those that know it would recognize that the thing on the left side of the “:” colon is the NAME of a piece of data (in this case “Item1”, “Item2”, etc.) and the thing on the right is the actual piece of data.

In the case of the first pair of “{ }” braces that ends up being read as "the thing called “Item1” has a value of “3” and the thing called “Item2” has a value of “2018-01-27T12:00:00Z”.

Unfortunately, I have yet to find a good way to tie job ID numbers (great from programs) to specific job NAMES (great for users). Hopefully that’s something that will get added in the future. :slight_smile: