Invisible Backup Job

I used to have a backup job called UserData on a W10 machine. Then I needed to change the SFTP server fingerprint and did also change the job name to UserDataDavid.
This job is running good. I do get success emails.

Unfortunately I do also get error mails from the same machine for job UserData which I do not see anymore. How can I get rid of that job?

Hi @Manuel_Glojek, welcome to the forum!

Are you running Duplicati as tray-icon only or maybe also as a service? If so, the jobs are likely specific to the logged in (or service) users.

Try checking some additional ports in the web browser - for example 8200 is the normal port so see if maybe there’s a Duplicati server running on port 8300, 8400, or 8500.

Only Tray is installed. No service.
Only port 8200 is reachable and there is only the correct working job configured.

Only one Windows user is configured on the computer.

Thanks for checking.

Just to confirm, you aren’t using third party reporting tool (like dupReport) are you?

If not, check your Duplicati folder for .sqlite files. You can find it out by going to the job Database menu and using the path shown there in Windows Explorer.

There should be one duplicati-server.sqlite file, one xxxxxxxxx.sqlite file, and 0 or more “backup yyyymmddhhss.sqlite” files.

If you see more than 1 of the xxxxxxxxx.sqlite files the one NOT in your visible job should be associated with the “hidden” one.

Note that the is no “hide job” seeing in Duplicati, so whatever is happening isn’t by design.

No reporting tool in charge.
Also no luck with the sqlite files. There is only one in the folder. Did search for .sqlite on the complete disk, but nothing relevant found.

Nevertheless I do now ignore the error reports and let it as it is.


Sorry we didn’t get this one figured out for you, but I’m glad it’s easily “ignorable”.

Does the invisible job give any clue in the web UI showing any activity (for example at the top of the screen) when the job runs? I assume it’s on a schedule, so you can also see About --> System info --> Server state properties --> proposedSchedule to see if the proposed schedule makes sense. Here’s a sample of output:

proposedSchedule : [{“Item1”:“55”,“Item2”:“2019-01-15T18:00:00Z”}]

shows only one job lined up, due for next run at the shown UTC time. The 55 is an ID, visible on web browser URL for job edit options. You could find it on your visible job. If what’s scheduled differs, somehow scheduling data in your server database got left behind. I couldn’t cause this when I tested rename, but maybe you got it.

There are other approaches such as About --> Show log --> Live --> Profiling to see email is sent (or not), or even opening up the server database in an SQLite browser where a fix could be attempted if cause lies there.