I wondered if email (or similar) was configured to run because of Duplicati web itnerface hangs on “Finished!”, which is also why I’m suggesting any test backup be as simple as possible initially, before going to complexity.
The backup name only matters if it helps with debug. And I could have done the below analysis earlier. Sorry.
Discovering what’s going on (even without names) was the objective, because I didn’t know what you had set up, yet something seemed like it might have been getting in your way and making you wait. I wanted to know. This was also a chance to see if internal ID #s can successfully be mapped into job names using URL editing. The desire arises from time to time, but the current “Server State properties” web output isn’t human-friendly.
proposedSchedule : [{“Item1”:“1”,“Item2”:“2018-09-17T07:00:00Z”}] would be a scheduled job.
schedulerQueueIds : [{“Item1”:4,“Item2”:“1”} says the job is already in the queue to run (backlog).
activeTask : {“Item1”:3,“Item2”:null} seems to say it’s stuck on an internal task that’s not a backup. Unfortunately I haven’t yet found a way to turn task numbers into anything that would actually help debugging.
–dblock-size advice can be found at Choosing sizes in Duplicati although I doubt it’s related to current hangs.