I’m testing duplicati on linux (ubuntu) for ca a week now and have come across 3 oddities:
A) Installing the .deb via dpkg does not enable the systemctl service for duplicati: I consider this tremendously important, otherwise you set up your backups in the webui and trust your machine is backing up, when in fact it is simply doing nothing.
B) After googling why the machine is not backup up I systemctl enable duplicati manually, assuming it will now work and backup without me starting duplicati manually after every reboot. I was mistaking: Duplicati server is running, I see it in the process list and in systemctl status, but when I launch the webui no backup has been made, and then the backup starts catching up the missed backup, and the last shown backup is not e.g. 1pm as configured but 5pm, when I launched the gui
C) I just started duplicati manually again since I know it won’t backup automatically and all my backup sets and configurations are gone. It gives me the first time setup question whether I have a multi user system, the whole this is reset. Was there a silent update in the background that wiped my configuration?
The duplicati command (at least mine – you can read your /usr/bin script) runs Duplicati.GUI.TrayIcon.exe which contains a Duplicati server unless you use the --no-hosted-server option in which case it expects a standalone Duplicati server at http://localhost:8200, and will work with that server to do backup operations.
TrayIcon will relocate its own server to http://localhost:8300 (and on up) if there’s already a server running, however the different server may get different backup configurations. They’re in Duplicati-server.sqlite and you have two of them for different users (possibly the root one is from that automatic launch at boot?) and I’m not sure which one holds what (you could look at dates and guess, or connect to various server ports).
Seeing a server ask initial setup questions may mean that you somehow got a different server than before.
It’s accessible for restores just by pointing to it with direct restore then giving needed passwords, however continued backups would want the configuration. Export and safeguarding of configurations is a good idea.
Easiest way by far is to connect to the server that has them. When in doubt on where a server keeps its files, you can make a new dummy backup and use the Database page to find its path, but in your case it might just turn out that the server that starts up at boot as root store in /root, and you store in /home/user.
There are more laborious ways to dig configurations out of Duplicati-server.sqlite, but let’s first make sure you didn’t launch a second copy of Duplicati server on a different port (probably 8300) and get thrown off.
Thank you very kindly for explaining this, I indeed have my backup set at port 8300 and something else at 8200, cheers!!
Now this is a bit confusing at best, maybe instead of simply connecting at good will to a newly launched server duplicati could show a message, port taken, duplicati already running via a different user, do you want to connect to that server or launch a new server with new configuration?
When I export my configuration from the port 8300 instance and import it to the 8200 server, the files shouldn’t need to be re-uploaded, duplicati should see all the chunks are already there ? thanks !
You can find out what’s there using something like:
sudo netstat -anp | egrep ':8200.*LISTEN'
On the export/import question, the configuration knows where the actual backup is. If remote, it won’t even know anything moved. If local files, and if 8200 is the root server, then accessing will be OK. The important thing, though, is that the same local database (or a copy of it) be used. This tracks what’s in the backup so constant remote queries aren’t needed. It can be recreated from backup files, but it’s slow for big backups. My practice is to rename mine then test-Recreate it periodically to make sure all’s OK… Others back it up.
Easiest thing to do for the configuration is to import the export. Find out where it plans to put the database, using its Database page. It won’t be there until first backup, so copy/rename prior database in before then. First backup will, I think, not be upset (everything matches up) and will pick up as if nothing had happened.
Wow thanks for the fantastic and detailed response! Since a lot of the trouble seems to be the database, would it be a better approach to use duplicacy with it’s non-db approach? Or does that bring with it a whole set of other issues?
I’m still undecided on my final backup tool of choice and appreciate all honest input to make the decision.