"Run Now" available while a backup is running

[sylerner]

While running a backup, on the home page the option to “Run now” for the active backup session is still available.

I’ve been too “chicken” to see what happens if I click it, but shouldn’t it be disabled for active backup sets?

[Pectojin]

It kinda just puts it into the queue. Nothing happens until the other job finishes.

But you’re right, when a job is running it shouldn’t be “Run now”. It should be something like “Run next”.

[JonMikelV]

There have been a few discussions about how to handle the queue, though I don’t know that many touched on the UI side of things.

If we want a “quick and dirty” solution I’d say an Angular update to the UI to disable “run now” when the job is currently running is probably the best way to go.

Otherwise we get into the discussion about what to do if other jobs are already queued/late. For example, should this manually requested “Run next”:

• literally run next (be inserted IN FRONT of any already queued/late items)
• be inserted in the queue AFTER any late (missed start time) items
• just be added to the end of the queue

[sylerner]

I guess the answer to this is dependent on whether it makes sense to queue up a backup if the identical backup is currently running.

I would think that it wouldn’t make much sense to do so, so simply disabling “run now” (or replacing it with a label stating “currently running”) seems the way to go.

If you do decide to have an action possible, which of the three scenarios you listed to implement would depend on what possible use case you envision that would have a user wanting to queue up a duplicate of the currently running backup.

BTW, what happens if a backup is already in queue (for whatever reason) and the user clicks “run now”? Does it move it to the front of the queue? Does it interrupt the current job? In this case, should “run now” be replaced either with a “in queue” label, or should the text dynamically be changed to “move to front of queue”? (And what if it’s already at the front of the queue? Just put a label saying “next in queue”.

For that matter, is the queue currently visible? If not (or maybe even if it is), maybe replace “run now” with a “This backup is number # in queue” label.

[sylerner]

A quick followup: A possible future feature should be the ability to display the queue and move jobs up and down the list as well as delete jobs.

[mikaitech]

This is essentially the graphical front end giving commands, which are then queued in the back end. Someone can click Run Now 5 times, and it will queue the same backup 5 times in a row. I’ve found with any run, backup, or restore command given still takes 1-5 minutes before it actually “fires up” in the backend system.

I do agree there needs to be some kind of communication that says “backup on this job is in process or queued”, where the graphical side greys out the run now, places a little spinning circle next to it, or even additional wording that says “job is running” or “job in queue”.

[JonMikelV]

@mikaitech

Someone can click Run Now 5 times, and it will queue the same backup 5 times in a row.

It’s not supposed to work that way so if that’s what happens for you, please let us know.

Duplicati should not be adding a job ID to the queue (as in waiting to run, NOT what’s currently running or scheduled to run in the future) if that ID already exists in the queue.

So you should be able to cause one back-to-back run of a job (currently running + queue to run next) but more than that shouldn’t be possible unless you wait until the “queue to run next” job moves to running then manually queue another one.

@sylerner

For that matter, is the queue currently visible?

Yes, but it’s very ugly. If you go to the main menu “About” page and select “System Info” then scroll down to the “Server state properties” section there are a set of fields called “proposedSchedule” and “schedulerQueueIds”.

See this post for an explanation of how to read the field contents (but like I said, it’s ugly):

Backup is not "finished" even though Last successful run shows start and elapsed time

If you go to the main menu “About” -> “System info” and scroll down to “Server state properties” you should see many fields including: “activeTask” (What’s currently running) “proposedSchedule” (what should happen eventually but isn’t currently in the queue like manually added jobs or the NEXT scheduled run of a job that might currently be running) “schedulerQueueIds” (what’s currently in the queue to be run) If a job runs long enough that it goes past it’s next scheduled run time, it will be…

@sylerner

A possible future feature should be the ability to display the queue and move jobs up and down the list as well as delete jobs.

Yes, this is something that has been requested before, unfortunately the way the queue has been written makes that extremely difficult. However, I believe there is a queue rewrite in the works which, when done, should make features like that much more viable.