Macs do get used. https://usage-reporter.duplicati.com/ shows about 2000 backups a day (if I read that right). Windows is the biggest use, with Linux use somewhere in between. Here I spot a few Mac users who help out with many things (and I might try to get involved in this debug session because I’m getting a bit past my skills).
I hinted earlier at how one might translate numbers to backup job names via URL substitution, and I think that what you would plug in (based on this) would be Item2 # for activeTask and schedulerQueueIds and Item1 for proposedSchedule. That might lead you to a backup (i.e. you’re stuck in 3 now, and have 1 scheduled to run when/if 3 finishes, and due to be scheduled again at 2018-09-17T07:00:00Z), but the work to run is piling up.
Let me be more specific about how I think you can map backup numbers into human-recognizable job names.
If I run “Show log” on a job I have scheduled, URL is localhost:8200/ngax/index.html#/log/2 (notice “2” at end)
The reason I think “2” is a backup id is because “200” gives “Failed to connect: Invalid or missing backup id”. Plugging in a valid backup id at the end of whatever URL you get (details may vary) should get the job name.
Though you could still try to map backup numbers to names (to see if what I just said makes any sense), you have queued tasks that don’t seem to have an associated backup number, and I’m not sure how to see them.
Before leaving this train for a bit, do you have anything after the backup, e.g. reports by email or something? Earlier logging seemed to show you getting to the end of the backup, and yet the backup seems to be active.
Pushing some automatic scheduling aside can be done by running a web UI job Export --> As Command-line then using that. I think it runs mono for you. If it runs it wrong, peel off the mono and use /usr/bin/duplicati-cli. You can add additional logging options as desired. What I hope happens is when backup is done, you return to your shell prompt without any mysterious hangs or next activities like the web UI is seemingly getting into…
Perhaps what you can do is to have the web UI make the simplest possible backup to an existing local folder, not let the web UI run it, and export it to run manually. If it works, try something more complex. And thank you. Sometimes going through the debug is what it takes to get to the answer. If you have several machines, you could of course pick one for this chase (as long as we’re up for it), and one for testing other backup options.
Having just made a pitch for debug, I’m also suggesting a new job because I don’t want to also be debugging whatever led to the repair. In test mode we have the luxury of trying to pick one issue at a time, e.g. the hang.
Let me see if @JonMikelV has anything to add, at least on OSX (which I don’t run, so can’t say much about).