Backup job finished - or not?

[JonMikelV]

@T-6

Where does Duplicati store the configuration? How do I remove the configuration for backup jobs and PWD?

I’m not familiar with OMV myself but if it uses standard deb installs then that might apply to your install:

Deb installs configuration and app data in non-standard location

Written based on duplicati_2.0.2.1-1_all.deb. This is only concerning running duplicati in headless server mode. If you install the afore mentioned deb file, the application configuration and data (indexes) are being stored in the /usr/lib/duplicati directory. This flies in the face of standard *nix app data / config / binary filesystem isolation. Personally, I not worried about the app data (var) /configuration (etc) isolation. I’m more worried the fact that the data is in /usr/lib/duplicati.…

For specifics beyond that you’d have to check with somebody more familiar with the Linux side of things.

As for the jobs, I don’t know if an uninstall will delete the job files or not - again, it may be an OS specific “standard” of which in not aware.

As for the GUI password, could that have been cached/stored in your browser?

Note that @Watson’s question is valid, did you reinstall the same version or switch to a newer one than you had?

[hydrian]

The way it looks now if you uninstall the DEB, it WILL delete the job configuration and the backup job indexes. I’m not sure about upgrades. So I’d be very careful. This is why I’m looking for splitting file locations. I’m waiting for Server needs --parameters-file argument · Issue #2928 · duplicati/duplicati · GitHub before I start the package fixes because it is key to only have to do the package refactoring once.

[T-6]

I did a fresh install of the Canary Version. Same result.

Then I created a new backup job which finished with a warning:
remote file duplicati-20171230T143742Z.dlist.zip.aes is listed as Uploaded with size 0 but should be 148765, please verify the sha256 hash

I did then a “verify files” which ended with no errors or warnings, so I assume everything is fine.

Seems for some reason the previous job was messed up. No idea why and how.

[JonMikelV]

Odd, but I’m glad you found a way to resolve it.

Note that the “uploaded vs should be” file size errors are often related to a delay in how quickly the destination can report on just-uploaded files (or less often a failed upload).

If you get an error at the start of a job it’s likely a failed upload, but if it only happens at the end - and only for recently uploaded content - then it’s likely the destination delay.

[T-6]

Thanks for the explanation.

One more question: what is the meaning of this line?
activeTask : {"Item1":2,"Item2":"6"}

[JonMikelV]

@T-6

One more question: what is the meaning of this line?
activeTask : {"Item1":2,"Item2":"6"}

Oh, right - you asked about that and I forgot to answer.

I believe in your case “item1” is the ID of the currently running task, and “item2” is the ID of the next task that will run as soon as “item1” is done.

While not showing in your case, I think it can also be a set of an ID and a time that it’s scheduled to start.