Yeah, Duplicati.CommandLine.exe is completely independent from the web UI. This is a good or bad thing depending on your situation.
If you want a way to interact with the web UI from the command line, such as kicking off a backup job programmatically, there is a better command line utility not included with Duplicati:
I can trigger backup job 1 to run by simply doing this:
duplicati_client.exe login
duplicati_client.exe run 1
duplicati_client.exe logout
I started with the command line from inside the web interface and got errors about invalid options. It also wasn’t clear what options were all going to be specified. I could have used the export as command-line and then figured out the options I needed.
The part that I found very frustrating is that the command line assumed one database name and the web ui assumed different database name. I say “assume” here because in neither case did I specify the database path. I would expect that both tools would use the same assumption for the database path or the command line would require the database path so it was clear that it wasn’t going to use the same path that the webui uses.
Maybe, I don’t know. The command line interface doesn’t complain about needing that information to execute. If it’s needed to find the backup, I would have expected to get an error that I need to specify the backup to use, but I don’t. If I specify the database path with “–dbpath” it seems to work.
Creating a new backup job touches on this a bit in one use case, but same is true for any new backup job:
When importing a backup job from a configuration file, a new database will be created, using a random filename.
Database management “Local database path” shows generated name, but file isn’t created until a backup. Although I’m not really familiar with this DB code, I think this is the same case of assigned-but-not-created. Server mapping to DB is in Duplicati-server.sqlite. I knew of dbconfig.json but wasn’t sure of how it’s used. Looking further just now, I think this can maintain mappings for CLI use but (as said) server is independent.
This is the expectation of integrated tools, but they’re independent. Rationale is quoted above. Downside is expectations and frustration of those who don’t know the scheme. Once scheme is set, change is difficult:
I would certainly make a new tool (not add server-control to the current CLI). IMO it would be even more confusing if there is a CLI tool that can work with- and without the server, as it will work differently in the two cases (not write logs, not find database etc).
This messaging might be fixable (I’m not sure how much rearranging it would need). Just stop, then insist Feel free to file an issue asking for more friendly handling of the missing-because-it-was-just-invented DB.