After update and fingerprint issue: backups gone

A little step-by-step-safer before backup is to use the Verify files button, just in case you told backup to automatically run repair, which is what I’m saying don’t do, manually, or with an option.

Assuming they look OK (right files, right versions), we now at least know the DB goal.

The files look well so far.

While looking at your files, are they all in your home directory, or are you going other places?

Both: home directory and a mounted drive:

drwx------ 54 dejhost dejhost 4096 Apr  3 08:44 dejhost
drwxr-xr-x   3 root root      4096 Nov  8 09:49 mnt

Alternatively you can just run a backup and see if Duplicati is warning about inaccessible files.
Verification and Backup worked fine now. I bypassed the fingerprint-issue by disabling fingerprint verification in step five of the backup configuration. This is how I ran a successful backup now. I will work on the fingerprint issue.

This is all looking good. What remains is

  1. Move away from canary to latest version
  2. After boot, duplicati is run as root. I need to stop and manually start it at the moment
  3. Resolve fingerprint-issue (WIP).

I will work on issue 2 and 3, but I will need help with issue 1.

Because Duplicati has nothing to do with the AUR packaging, your EndeavourOS choice, or the “yay” AUR helper that you are trying to use, I’m going to request that you ask in the right places.

I see a dejhost on the EndeavourOS forum. Is that you? If so, please ask in the relevant forum.

Why after boot? Your previous report said it was after doing login. You can’t see it earlier, right?

Why root and not you? Is there an access problem to some file? Your databases being in your home directory with you as their owner, suggest that Duplicati has been running as you awhile.

I see a dejhost on the EndeavourOS forum. Is that you?
Yes. I will post my question there. Thanks.

Why after boot? Your previous report said it was after doing login.

Sorry, I was not precise here. When I (re-)start my PC and log into my EOS Desktop session, duplicati starts automatically. There are no backups configured, and these are the system properties:

APIVersion : 1
PasswordPlaceholder : **********
ServerVersion : 2.0.6.104
ServerVersionName : - 2.0.6.104_canary_2022-06-15
ServerVersionType : Canary
StartedBy : Server
BaseVersionName : 2.0.6.104_canary_2022-06-15
DefaultUpdateChannel : Canary
DefaultUsageReportLevel : Information
ServerTime : 2024-04-04T09:57:54.03724+02:00
OSType : Linux
DirectorySeparator : /
PathSeparator : :
CaseSensitiveFilesystem : true
MonoVersion : 6.12.0
MachineName : WorkstationII
UserName : duplicati
NewLine :
CLRVersion : 4.0.30319.42000

In order to see my configured backups, I have to stop duplicati, and start it again using the Tray-Icon:

[dejhost@WorkstationII ~]$ systemctl stop duplicati
[dejhost@WorkstationII ~]$ /usr/bin/mono /opt/duplicati-latest/Duplicati.GUI.TrayIcon.exe --webservice-port=8200

This gives the identical system properties:

APIVersion : 1
PasswordPlaceholder : **********
ServerVersion : 2.0.6.104
ServerVersionName : - 2.0.6.104_canary_2022-06-15
ServerVersionType : Canary
StartedBy : Server
BaseVersionName : 2.0.6.104_canary_2022-06-15
DefaultUpdateChannel : Canary
DefaultUsageReportLevel : Information
ServerTime : 2024-04-04T09:57:54.03724+02:00
OSType : Linux
DirectorySeparator : /
PathSeparator : :
CaseSensitiveFilesystem : true
MonoVersion : 6.12.0
MachineName : WorkstationII
UserName : duplicati
NewLine :
CLRVersion : 4.0.30319.42000
CLROSInfo : {"Platform":"Unix","ServicePack":"","Version":"6.6.22.1","VersionString":"Unix 6.6.22.1"}

Now, I can see my configured backups.

The server starts automatically because systemd does that, and it’s duplicati because the unit file says so because AUR decided to do that. Are you saying something forces your browser open at login time, directly to the Duplicati GUI? Please distinguish between server and GUI. Important…

I was referring to the duplicati server. The GUI is not forced to open.

Here is a link to my thread in the EOS forum. Should I uninstall my current duplicati-version, and then try to one of the mentioned installation methods?

Sometimes uninstall isn’t required, but it probably depends on tools and packager. Might be best. Unless they did something really weird, program uninstall shouldn’t be messing with backup data.

Interesting: I manually removed all obvious duplicati-folders (except for the one containing my backup-configs). duplicato could not be started afterwards anymore. I then installed duplicati beta:
yay -Syu duplicati-beta-bin,
which is now started by systemd when i loginto my EOS session. Here are the details of the system properties:

APIVersion : 1
PasswordPlaceholder : **********
ServerVersion : 2.0.7.1
ServerVersionName : - 2.0.7.1_beta_2023-05-25
ServerVersionType : Beta
StartedBy : Server
BaseVersionName : 2.0.7.1_beta_2023-05-25
DefaultUpdateChannel : Beta
DefaultUsageReportLevel : Information
ServerTime : 2024-04-05T12:30:08.75671+02:00
OSType : Linux
DirectorySeparator : /
PathSeparator : :
CaseSensitiveFilesystem : true
MonoVersion : 6.12.0
MachineName : WorkstationII
UserName : duplicati

No backups configured. When I stop duplicati, and start again using the Tray-Icon, /usr/bin/mono /opt/duplicati/Duplicati.GUI.TrayIcon.exe --webservice-port=8200, I see my backups in the duplicati GUI. Version is “Canary”:

APIVersion : 1
PasswordPlaceholder : **********
ServerVersion : 2.0.7.101
ServerVersionName : - 2.0.7.101_canary_2024-03-08
ServerVersionType : Canary
StartedBy : Tray icon
BaseVersionName : 2.0.7.1_beta_2023-05-25
DefaultUpdateChannel : Canary
DefaultUsageReportLevel : Information
ServerTime : 2024-04-05T12:38:37.425852+02:00
OSType : Linux
DirectorySeparator : /
PathSeparator : :
CaseSensitiveFilesystem : true
MonoVersion : 6.12.0
MachineName : WorkstationII
UserName : dejhost

The files on /opt/duplicati date 04.04.24.

So what I need is to start the beta-version at login, make it use the files of the canary version, and remove the canary version. I’ve the feeling, we’re going in circles here…

Yes we are, and I’m reluctant to keep explaining it, so please review the previous explanations which explain how AUR makes systemd service come up as a powerless user, with databases located where it wants, and not where your databases actually had been. The latter raises the question of whether you were ever actually on systemd service, or got in TrayIcon another way.

UserName is easily explainable. Manual launch as you is you. Systemd launch is duplicati, as AUR unit file makes it so. Usually people just edit the unit file to not do that, so run as root and have good access but more security risk. I’m not sure if they insist on having Tray Icon as well, because that takes special care to launch with --no-hosted-server to get to systemd server.

Alternatively you just let AUR do its thing on systemd and you do yours as you just by TrayIcon launch. Launch at login should be available in Arch or EOS docs, or EOS forum can likely help.

One subtle point on your manual launch is that the jump from BaseVersion to ServerVersion is from an autoupdate that you installed that’s still hanging around. You can just find and delete it.

Downgrading / reverting to a lower version

gives some possible locations where you can look, maybe you remember user that updated, or you can just search in root shell with something like find / -mount -name '*2.0.7.101*' which will help find the subfolder called updates where Duplicati puts its installed autoupdates.

Downgrade sometimes hits database version snags, but this one just needs an update deletion.

This is getting long enough that history is hard to find, but if you can ls -l all the other spots that might have databases (I’m pretty sure we went through them), file owner likely tells you what user created the file. You can also estimate from size of any databases around if they were really used.

If the only meaningful databases are owned by you, in your home directory, you were probably not using the systemd service at all. If that’s the way you liked it, then the goal might be a start at login.