Hi,
my backups are started manually via a batch file under Windows 11.
Looking at the home screen of the Web GUI the date of the “Last successfull Backup” is some old one.
I would expect to see the date and time of the manual started backup.
The --dbpath parameter of the GUI-Setting and the batch file are identical.
I backup to a local storage (USB-HDD)
Please clarify. If you use Duplicati.CommandLine, they intentionally run separately from server.
duplicati-client was a 2017 effort for a CLI interface to server, but needs update for current one.
You can probably view the job logs from GUI, because those are in the database your CLI uses.
The server does not poll the job logs for changes, though possibly the devs would consider that.
I was not aware, that the Client is an independent code part which behaves different to backups started via the GUI.
At least “Duplicati.CommandLine.exe” --help reports also version 2.1.0.2. This suggested to me, that it does matter how to start the job.
This is confusing, because the GUI offers a way to build the CLI Command from a job built interacitve in the GUI. So I think it is equal how to start the job.
I assumed, that the GUI could take the date/time the last job ran from the DB.
I don’t understand the significance of the version suggesting anything. Can you clarify that?
It should start the same way. That doesn’t mean progress and results happen the same way.
While I’m answering, I’ll note that there are some new developments in the area, such as the
Using remote management
Monitoring with Duplicati Console
Agent
ServerUtil
so the future might have yet more ways to connect the parts together. I’m describing historical.
Roadmap has rough sketch of some futures, and I don’t know if the devs will wish to say more.
EDIT:
The commandline interface gives access to run all Duplicati operations without needing a server instance running. This is beneficial if your setup does not benefit from a UI and you want to use an external scheduler to perform the operations.
When the server runs any operation, such as a backup or restore, it will configure an environment from various settings, primarily the backup configuration. The actual implementation is the same code that is executed by the command line interface, but runs within the server process.
But when you run Duplicati.CommandLine, all the settings are on command line, e.g. Export.
I mean only the same Version number means the same code base.
Yes this are interesting points!
Anyway, back to the original issue. I assumed, that the GUI could take the date/time the last job ran from the DB. But this seems not to happen.
Previous remark:
and it would have to be done carefully as there’s no telling what shape the DB is in at the time. Common case is it not being there, which is how it is before first GUI backup. Might also be in middle of a backup or maybe even a recreate. The server doesn’t know yet must not interfere.
There’s also a design question of how far to integrate things intended to be run independently. Simply sharing a database may let you get the logs, but there’s no coordination between them.
Yes, that is a bit confusing. The logic is that the CLI is like a regular commandline tool (similar to cp, scp or copy). Following this logic, it starts, does its function, then exits. You need to supply all arguments to each invocation, and no state is persisted locally (except the local database).
The server, on the other hand, is intended to run as a “background” process, and for that reason it keeps the configuration in a database, and records some metadata.
If you want to both use the server, and trigger it manually, the tool Duplicati.ServerUtil can start the backup:
This will trigger the backup inside the server and update the metadata + show progress etc, in the UI. You should define the backup without a schedule in the UI, so your external process will decide when it starts.
That was what I looked for indeed, thank you very much!
This way starting a backup job is the perfect solution.