Backups started via command line should update (progress and info) in WebUI

Hi,

I am (too) looking for an crashplan replacement. I am trying duplicati and so far it look really good. Awesome job guys :slight_smile: :+1:

I am using win and linux machines.

With some (linux) machines I would like to start backups manually, because my “exclusions” are dependent on what mounts are currently active. Getting the command line string to start the backup is really easy thanks to the “export” function. :+1:

When I start a backup manually, I think it would be great if:

  • the current progress be shown in the WebUI
  • the Information on the “Last successful run” as well the Backup Information (size and no of Version)

would be updated in the Home view.

Could this even be considered a bug? It seems the WebUI does not know of the job started via command line. So if I start an operation there, would that get queued or would things get messed up because two jobs would try to run simultaneously?

Cheers

Stefan

Separation of command line version and Web UI is by design. There are some suggestions for more interaction. See this topic for more info:

ok. I understand. We are looking at two independent applications by design.

Maybe it is not feasible to show the progress of any currently running job in the WebUI, but might it not be a good idea to (optionally) let the command line app update the servers metadata (Duplicati-server.sqlite)?

The commandline tool can read exactly the same information as the WebUI, so it is just a matter of actually implementing it (and making it look nice too).

1 Like

I found this thread because I was wondering if anyone had had the same thoughts.

I’ve got Duplicati set up to remotely initiate backup of my data whenever the destination PC is powered on. Which is handy, but I made it work by calling a script that starts Duplicati by command line. Then I noticed that the webUI doesn’t count the command line backups.

So il support any efforts to tie the two together, or am intrested to know if I could do it myself.

Cheers

When running the Duplicati Commandline locally, you can make it update the Web UI by specifying --dbpath.

Alternatively, this client i wrote can start jobs on your server from any machine that can access your Duplicati server API :slight_smile: GitHub - Pectojin/duplicati_client: A command line client for controlling the Duplicati Server
Since the client uses the same API as the server it’s equivalent to clicking the “Run now” button in the Web UI.

1 Like

That’s a pretty cool way of handling not-always-on destinations. How would you feel about making a #howto post to help others set up such a process up? :wink:

Ok.

I’ve written it up offline and will post it shortly.

I looked into the --dbpath suggestion but its already in there and matches the SQLite db for the backup job. am I missing something ?

If you are then I think I might be missing it too. I thought that should be enough to update the DB. Perhaps it’s just not updating the Duplicati DB as well as the specified DB?

This would prevent some logs from showing up in the web UI and would not update metadata if I remember correctly.

The metadata is updated after running a backup, so just updating the local database does not update the metadata (in the Duplicati-server.sqlite database).
It would perhaps be possible to read the operation results from the local database, and update the metadata, but the data is stored in “human readable” format, not always easy to parse reliably, but it could be done.

Makes sense.

In that case I’d definitely recommend my client if you’d like both databases to be updated :wink:

1 Like

Are we going to have to implement a policy about advertising your own products? :wink:

For example:
“If you advertise your own Duplicati related product, be sure to include a link so it’s easy for people to find it!” :smiley:

I didn’t wanna spam the link since it’s in one of the previous posts and when I try to link it again disqus yell at me :frowning:


D’oh!

OK, you win (regarding the link) but for the record we use Discourse for the forum, not Disqus. :slight_smile:

I couldn’t remember the name :frowning: