Web GUI lost all backup configurations on Linux, even though db is present

[johnemb]

@ts678

it was configured to back up $HOME/bin

How do you enter that? It’s not in the tree of checkboxes, and Add path field won’t take it when I try.

It shows as “User data” in the web GUI. See screenshot below.

Something feels odd to me here. It does not feel right presenting root’s homedir as “User data” just because the service runs as root. I assume this is a scenario seen in Linux context before, though I am not too familiar with it.

In the future I will avoid “User data” and instead use “Computer” only.

@ts678

If it was running as you for weeks, then perhaps you ran /usr/bin/duplicati which starts the Tray Icon. Reboot lets systemd get there before you, and often start as root, depending on the systemd config, which would let you set another user (some distros do it – I forget exact how to do), if that helps any.

Yeah, that probably explains it, thank you!
I don’t remember exactly how the install process was, but on Linux it should probably recommend an immediate reboot if the Duplicati service is installed. I don’t think it did.

@ts678

Another difference visible in systemd status post is that it starts /usr/lib/duplicati/Duplicati.Server.exe, whereas /usr/bin/duplicati runs Duplicati.GUI.TrayIcon.exe, which is Server plus Tray Icon combined.

I hope I can get the tray icon to become visible. I don’t know how to edit the command-line used by the service, and I am not sure I want to do that either, because it will make upgrades, reinstalls and maintenance more complicated. Instead, I am hoping that a newer version will fix it. The mentioned Duplicati Tray Icon When Running as Linux Service indicates some bugfix in the area.

@ts678

There was (and maybe still is) some confusion about what database was being used. It should be what the Database screen shows.as Local database path field, and whatever user Duplicati is running as needs access. After you delete and Repair, does it come back or does any file change in the directory?

Recreate did bring back an .sqlite file as far as I can tell, the error still showed. But no need to dwelve more on that, see below.

I had several backups configured, and I am in the process of getting them up and running or starting fresh, mostly done now I think. All backups now have database path in /root/.config/Duplicati. Some smaller ones work fine, but the largest still has issues.

It is no longer the issue seen earlier, I can only repeat that with a backup that has files selected, but nothing remote yet. That one is going from error “Repair did not complete” on backup, to error “No files were found at the remote location” upon recreate. No worries, I’ll replace the backup configuration with a new one. For now all scheduling is disabled.

The issue with the largest backup at the moment is as follows:

Checking errors, related to #1400. Unexpected result count: 0, expected 1, hash: Ze3lQbMsZNbYzpMJpjYQBi9tXVuqotle9MZFcgdcmnk=, size: 102400, blocksetid: 365279, ix: 18, fullhash: Iii82/Tzh5Uob8WW46qGnOlV8ozs6M3Ir0+Tv0jR77g=, fullsize: 2036840
2020-01-17 08:23:08 +01 - [Error-Duplicati.Library.Main.Database.LocalBackupDatabase-FoundIssue1400Error]: Found block with ID 2554155 and hash Ze3lQbMsZNbYzpMJpjYQBi9tXVuqotle9MZFcgdcmnk= and size 25376
2020-01-17 08:23:08 +01 - [Warning-Duplicati.Library.Main.Operation.Backup.FileBlockProcessor.FileEntry-PathProcessingFailed]: Failed to process path: /root/.config/Duplicati/86757982797878868475.sqlite-journal

When I moved the database file from $HOME to /root via Database → “Move existing database” it automatically started repair or recreate (not sure which), and this ran for a couple of days (the backup source is 47 GB). Then I tried a backup, and got the above error. I have alternative backup for the moment for those files, so I can replace that one as well.

I’ll try out newer versions (experimental) when I get time.
Thanks for all the useful information! I did get the configurations in the web GUI back after all