False impression that CLI and GUI are inter-connected

Continuing the discussion from How to restore a single folder via CLI?:

Same exact impression on my side (since I have started using Duplicati two years ago). This illusion was busted during my latest hick-up: Fix corrupted index files and malformed database disk image - #3 by JimboJones

The GUI is good for configuration, but when it comes to restore and repair, I’m more comfortable with direct feedback via CLI.

I’m not sure of this topic’s goal. The manual could highlight this, if someone can create a pull request.

Using Duplicati from the Command Line does say (but only in Backup section, where export fits best)

Instead of composing the complete backup command yourself, including all advanced options, you can create a backup job in the Graphical User Interface, without scheduling it. Once completed, you can export the backup job to the command line, resulting in a Duplicati.CommandLine.exe backup command with all settings that you specified in the wizard. You can paste this generated command in your favorite task scheduler. For more information about creating a backup job in the Graphical User Interface, see Creating a new backup job. For more information about exporting the backup job to the command line, see Exporting a backup job configuration.

Some historical references and possible answers for people who want some type of integration include:

Duplicati 2.0 experimental release (with UI) was the 2014 announcement of GUI and some CLI change.
I can’t say much about the details of what transpired, and that date seems to predate even GitHub use.

Integration between command line and web interface #2693 shows how Duplicati Client project began.

The commandline interface is intentionally separate from the server. The use case is for people who prefer headless commandline tools.

Feature Request - REST API #4100 tells the substory of server API reverse-engineering.by @Pectojin

PowerShell script to run Duplicati GUI jobs by @JimboJones seems to use similar API-based method.
This was discussed at the topic linked in original post here, which also covers –dbpath level integration.

That’s not as complete as the API clients, doesn’t fit all uses, but can do better than not giving a dbpath.
Giving dbpath also runs the risk of a CLI job and a GUI job running at the same time and colliding in DB.
My impression is that one just gets locked out, with complaints but no other damage, but it’s not proven.

Duplicati CLI’s minimal usage has a completely independent database connected to (I think) destination. Mapping is kept in dbconfig.json file, as opposed to more detailed server config in Duplicati-server.sqlite.

Pure CLI usages sound DB-collision-safe and should be able to start multiple backups at the same time.
GUI serializes operations, which means it’s not always possible to start at the exact time that one wants.

My gripe with GUI is that it’s easy to miss messages because there are two logging locations being used. Error popup directs you to the job log, but job that dies early may log to server log in a different GUI spot.

Combine logs in GUI #1152 talks about this. The GUI log also truncates some errors down to single lines which are a nice concise summary but leave one wanting the details that used to be on the lines below…

This message loss sometimes requires a second run watching the live log, or one can set up a log-file at whatever log-file-log-level seems right. I have mine turned way up, and pay the price of gigantic log files. When things go wrong, this gives me a good chance of having some actual history to study that problem. Ordinary usage would not call for such a high level, but Information, Retry, or even Verbose might fit well.

Getting off-topic here, but different people prefer things different ways for their reasons. How to explain?
Some products, e.g. electronic components, publish “application notes”, but our manual isn’t quite there.

Getting back to original post, is there anything besides documentation to reasonably set an impression?

1 Like

I’d classify it as more of a presumption than a false impression. The documentation isn’t bad nor does it directly state or elude to the GUI and CLI being linked in that way.

For myself, I just presumed based all on all the functionality and features that Duplicati has, that surely you would be able to call on existing jobs via the CLI. I’m hard-pressed to give a specific “this program does it” type example but as someone who’s been in IT for way too long, I just expected Duplicati to do it given all of it’s other capabilities.

I get that the CLI can be used alone for the head deficient and such but it also seems like it could be probably be setup to talk to the server as well (if present/enabled).

I’m saying this off the cuff, I don’t know if the CLI has room in it’s design to add a few more methods to in particular retrieve but also parse and choose existing jobs from the server component but if it can I think it would be a good feature to add. Most of my C# experience is from Unity but I’ll see if I can’t mangle something up that would at least work as a proof of concept.

I do think some of the documentation could be improved a bit, mainly with more usable examples, a bit less “This is everything you can possibly do.”, more “Here’s what you need to get started for this scenario.” sort of thing. I guess more guides than documentation but either helps. That being said for something that is still in beta the documentation is pretty darn good.

2 Likes