A couple of suggestions

[JonMikelV]

Thanks for the details.

Since you’re not seeing duplicates in the system info, it sounds like you’re running into the known scenario where:

1. a job starts (which takes it out of the queue)
2. this puts the next run of the job in the “scheduled” state (all as it should be)
3. the running job goes so long it passes the start time of the “scheduled” one causing the “scheduled” one to be put into the pending queue (causing it to run as soon as the currently running job ends)

There have been some suggestions on how to handle this scenario (including a “cooldown timer” @drakar2007 mentioned) but so far nothing has been implemented.

---

Here’s a summary of some “Server state properties” fields:

Scheduling strategy for backups

The scheduler is fairly simple, but schedulers are always confusing When you create the backup, and set a time to run, Duplicati records the “next time” it should run. Once that time comes, it will send the backup into the queue of tasks to run, and update the “next time” it will run. If the scheduler is restarted (e.g. by a reboot) it will look at all the “next time” values and send items into the queue. When sending an item into the queue, Duplicati will first check if it is…

---

Here’s a summary of how the queue is supposed to work:

Catch up of multiple missed backups

The way the queue works a single job is not supposed to appear more than once, so if you seem to be experiencing that then there’s a bug. One way to check what’s in the queue is to use the main menu “About” item, then click on the “System info” button, then scroll down to the “Server state properties” section and find the following lines: activeTask is the ID of the currently running task (if any) proposedSchedule is the “not yet in queue, but expected to be put in queue at …” list schedul…