If I log out of duplicati while it is running a backup or restore operation (or any other operation, for that matter), does the activity run to completion in the background on the server? Or will doing so abort (hopefully cleanly) any ongoing activity?
Thanks!
Operations will continue running on the server as long as the server process is running 
There are a couple of operations that make no sense to run if you’re going to log out right after, though.
For example command line operations may not be very useful since you can’t “get back” to the result and see if it worked. But all the operations runs to completion.
For completeness I should add that it is actually SAFE to log out even if running command line stuff - they will keep running being run by the server just like a backup job would.
I’ve done this a few times when I knew I had a long command line task running AND had set up either a log file or email notification on completion so seeing the “real time” results in the web GUI wasn’t important.
The question is whether the sever has protected itself from being shut down (on Linux - KDE desktop) when I log out.
I’m hesitant to just experiment, because I’m afraid of what might happen if the server is aborted mid-operation by Linux.
Any ideas if it detaches itself (goes “daemon mode”) from the user session?
Well, if your Duplicati process is started by KDE it may end it when you log out of KDE.
The good news is that Duplicati works in an atomic way that means that it will either completely finish it’s current volume or will start over on the volume next time it runs.
It will detect completed volumes from a previous backup attempt and use them for the new backup and won’t have to upload those again.
It may have to clean up some old files but it will do that automatically.
But I would recommend running it as a service rather than a user session process just because then you’re certain it’s running.
Well, I experimented logging out while doing a restore (again, this is on Linux running KDE). Even if I invoked duplicati with nohup or used disown after invoking it, logging out brings the server to a screeching halt.
It’s hard to be certain, but it looks like it might be leaving incompletely restored files behind.
Also, duplicati does not resume the restore when next invoked.
I guess that running as a service is my only solution (or being careful not to log out when duplicati is active!).
I don’t want to run duplicati as a root service - too much power to wreck havoc, plus I’d prefer it if each user took care of their own configuration of what they backed up and what they didn’t. Hence I’ll need a separate daemon for each user.
(Should I be starting a new topic for the following?)
This raises my next question: I’ll be invoking duplicati-server for each user, so there will be multiple instances listening on different ports. How does a user know what port to connect to in order to manage their duplicati instance? Is there a way to invoke the tray icon connected to the proper server for the current user?
Or is there a way to invoke duplicati (tray icon version) such that the server component daemonizes itself, thereby making itself immune to being killed?
Also, is there a sample service file for invoking duplicati as a daemon?
Thanks!
The restore operation isn’t atomic, sadly. Only backup. If you’re restoring you definitely want to stay logged in or run as a service.
If I had to do that I would solve the problem with Apache or nginx and reverse proxy route DNS names to the appropriate port. But all this is kind of advanced for a casual setup 
You can start the tray icon with options defining which port to use to connect to an existing server. I can’t quite remember the option but then you could have each KDE user start their own tray icon this way with the port preconfigured. Still gets kind of complicated for my tastes, though.
I can post mine when I get to my machine.
This is what ships in the .deb package (and I’m using on my system)
[Unit]
Description=Duplicati web-server
After=network.target
[Service]
Nice=19
IOSchedulingClass=idle
EnvironmentFile=-/etc/default/duplicati
ExecStart=/usr/bin/duplicati-server $DAEMON_OPTS
Restart=always
[Install]
WantedBy=multi-user.target
You may need to specify User= and Group= for your use case. You also want to either make an EnvironmentFile for each unit, or just inline the $DAEMON_OPTS variable into your systemd file.
I would specify --webservice-port as a daemon option so you know which service gets which port.
When launching the tray icon on login I think you need these options:
--hosturl: Supply the url that the TrayIcon will connect to and show status for
--no-hosted-server: Set this option to not spawn a local service, use if the TrayIcon should connect to a running service
Last minute thought: I assume that I should user a template service file (e.g.: duplicati@.service) and enable multiple instances via systemctl enable duplicati@username. I can then use User=%i to instantiate a per user instance.
I’ll have to give a bit of thought how to control port numbers per user, but I’m on the right track now.