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?