I have a lot of jobs running, and if a source machine is offline, they generate errors in the mount script (this is by design). Then in the morning when I check Duplicati, I have as many as ten “Error” messages in the GUI that I have to manually dismiss. The relatively slow GUI makes this somewhat annoying because the “Dismiss” buttons are a little slow to register (maybe AJAX?):
Would love it if there was a quick way to dismiss all.
I made that for my Duplicati client 
But it’s pretty easy to add to the web UI so I’ll take a look at it
It’s not entirely pretty, but we can start here.
It just dismisses all existing notifications. The neat thing is that the async ajax makes them all disappear at the same time (after that short delay you normally get).
The pull request is here: https://github.com/duplicati/duplicati/pull/3158
It’s perfect! Thank you and I’ll give Duplicati client a look as well. Did not know about it until now - thank you!
I haven’t really been boasting about it too much. I wanted it to be a bit more polished
We talked a bit about including it under Duplicati so that it could be included in the installer. But again, I didn’t feel it was ready
It might be even better if Duplicati was smart enough as to not try to backup a machine which is obviously powered off. At least there should be an option for that.
I believe there is a parameter to ignore missing sources, but honestly I haven’t fiddled with it yet so I’m not sure how it handles the situation.
The allow-missing-source parameter is for continuing a backup even if it cannot find a folder you told it to back up
There’s a bit of explanation here
Backup error: The source folder does not exist, aborting backup · Issue #2760 · duplicati/duplicati · GitHub
My use case is a bit unique. I have Duplicati running on a central server, backing up machines from my LAN to various onsite and cloud destinations. I want to manage the backup from one place. For laptops that are on the LAN, I have a script that mounts the user directory to a local mount point, and if it fails, this means the machine is offline/unavailable/sleeping. My pre-backup script will give an exit code in that case (I chose 3 so I know right away that it was simply a mount failure).
I suppose if there were a parameter that said “gracefully-exit-from-pre-backup-required-script-exit-code” and had a field where I could set the exit code of my choosing, such that if the exit code matched, the backup would silently fail with no errors/warnings, that might help, but at the same time I don’t necessarily mind getting a warning when that machine doesn’t back up. If it happens many days in a row then I make a point to ensure it is online from time to time so it does get backed up at least once a week.
I do wish Duplicati had more of a client/server architecture, but I know that isn’t the mission of the developers so I’m trying to fit something into an arrangement that isn’t what it was designed for. The only reason this particular issue was annoying was that I’d get an error for each destination. I know there has been talk of allowing for multiple destinations for one backup job, but for now this will work nicely.
And I still strongly believe that should be a default, but that’s another discussion (I recall from that github thread that you and I agree on that as well).
It’s my default on all jobs, but we still need to deal with the scope drifting 
I believe it will be officially supported some day, but I don’t expect it to be created before a stable release. Of course anyone is free to begin working on it before
Thanks for the assist with --allow-missing-source. For those that might care how it’s defined on the parameters page:
--allow-missing-source
Use this option to continue even if some source entries are missing.
Default value: “false”
I wonder how defaulting that ON would play out if / when drastic change alerts get implemented. 
Thanks for the consideration on that.
I expect you’ve already seen it, but depending on what “server” functionality you’re expecting there are two or three tools others are developing to centralize reporting and possibly even some centralized control tools.
