Can't access backups after update to 2.1.0.2

Support
1

I have Duplicati installed locally, running as a service on my Windows 11 machine. I went to check on my backups and found that the tray icon led me to a blank user interface (my backup tasks not listed), with a message at the bottom telling me about the new update. I installed the update, but now the try icon still leads to a blank user interface. I’m sure this has to do with running it as a service, but this really should update correctly for both scenarios…

Need layman’s instructions on how to correct this and regain access to my backups. Thanks

2

Checked the backup files; looks like the last one was Dec 5th so I’ve been running without it for much longer than I’d like. I can access the files fine if I need but the tasks are still missing. I think I made backups of the configs for each task so I can import them, but I’m still concerned it might not be running correctly now because of how I had it installed before.

3

Further investigation - the service is registered and running, but I can’t access it. If I try to access it via localhost:8200 it tells me I can’t because I didn’t go through the tray icon. The tray icon was opening a server on port 8300, so I added --no-hosted-server to the startup shortcut target field to correct that. Now if I restart my computer/log out and back in, the tray icon doesn’t even open.

4

How was it installed before? How did you access Duplicati GUI? Did you use TrayIcon at all?

Got the actual message? If you haven’t put a GUI password on yet, this is a new requirement.
If you just browse in, you might not know its password, but TrayIcon has an alternative way in.
This works well with regular TrayIcon (as you first had). Not sure about --no-hosted-server.

“Duplicati.GUI.TrayIcon.exe –no-hosted-server” not working links to some info you might need because I think you’re going to have to have a password, and have TrayIcon pass it to service.

You can certainly set up a server password, and run CLI start with it and --no-hosted-server.
When things don’t start, this is an easy way to see why. Also try Windows Application event log.

5

What happens here is most likely you are running two different instances:

  • The Windows service is on port 8200
  • The TrayIcon is running another instance on port 8300

To get access, you need to set a password for the Windows Service instance. You can get a signin link if you start the service and look in the Windows Eventlog. In here there will be a warning message from “Duplicati” giving you a signin link.

Simply open that link in a browser and you are logged in and can set the password. From then on, you have access to the UI with your chosen password.

To get the TrayIcon working, you need to add both --no-hosted-server and --webservice-password=<your password> as commandline arguments.

There are reports that the TrayIcon will not start in the right order when using a service and rebooting, because the Windows Service starts later than the TrayIcon. There is not yet a fix for this.

6

Thanks for the quick response!

  • I set a password via the mentioned signin link and I am now able to access the GUI when navigating via the browser, but the backup jobs aren’t shown. (Again, I can import the configs for the jobs to set them up “fresh” if needed.)
  • I added the password to the commandline arguments for TrayIcon. TrayIcon now starts (shows in the tray), but clicking on it does nothing. This is also the case if I close TrayIcon (via Task Manager because the tray flyout doesn’t appear) and re-open it using the same commandline arguments (both with and without administrator privileges if that matters). I’m not sure where to look for the logs for that one.
7

Be sure you’re in Windows service. View UserName and StartedBy in About → System info:

  • UserName : NT AUTHORITY\SYSTEM
  • StartedBy : Server

Another clue is your URL. If it’s at port 8300, you may be in Duplicati TrayIcon, as described.

By testing, this seems fixed in 2.1.0.101 (no Beta fix yet), and is probably documented below:

2.1.0.101_canary_2024-12-06

Fixed a case where the TrayIcon would hang in detached mode

If you right-click Open, you can watch the visible icon grow unusually wide as part of the crash.

image
image138×102 2.98 KB

but previously it was

image
image123×109 2.38 KB

8

From one of my first messages, I noted that the second instance is no longer running. That is not the issue. I am in the Windows service. It is at port 8200, as I have already noted. Yet again, I already noted that the tray flyout does not appear, so I cannot witness the behavior you’ve shown there. Please actually read the things I’ve written.

9

There’s an expectation that situations may change, either because you did it, or we suggested.
I’ll proceed under the assumption that you’re certain situation remains the same, and move on.

What you didn’t note is the history before that. Some left-click for an open. That hangs it silently:

So if the first clicking was a left click, that does nothing except hang, and later right-click will fail.

Until I hear otherwise, the TrayIcon crash is fully explained, so let’s work on your jobless Server.

Have you always run the Windows service at defaults, which would be as SYSTEM with DBs at:

C:\Windows\System32\config\systemprofile\AppData\Local\Duplicati

Windows used to (maybe still does, but there are no new reports) move that to C:\Windows.old during Windows version upgrades. This is impolite, and surprises people who have to undo that.

What files are in the above SYSTEM profile location? Job DBs are random letters. Server DB is Duplicati-server.sqlite and you should see at least a new one. Are there others, e.g. DB backup?

If there are no other databases or backup copies of databases, the old databases are elsewhere. Searching for Duplicati-server.sqlite (with enough privilege) is one way to get the old location, but Migrating from User to Service install on Windows was using C:\ProgramData\Duplicati\Data

You can see how --server-datafolder specifies this, and maybe your old service install had it.
It would be worth peeking at ProgramData. If you need a fast search, the Everything app is good.

10

Sorry, forgive my frustration. I’ll keep in mind that the situation may change as I try things. I also misunderstood your description of the TrayIcon behavior - I was able to replicate the right-click behavior.

As far as I’m aware, I’ve always run the service at defaults. I didn’t find a C:\Windows.old or C:\ProgramData\Duplicati\Data so I’d guess that isn’t the cause. At the SYSTEM profile location, I have

Screenshot 2025-01-02 193748
Screenshot 2025-01-02 193748647×197 8.57 KB

so there does appear to be a backup. Are there two different types of backups there? The .sqlite file looks like it was created when I updated Duplicati.

11

After running a search, the only other location with a Duplicati-server.sqlite is the user appdata folder, which I assume is the database for the TrayIcon server.

12

Are there backup job files anywhere? They’re usually near the server DB.
Names are random-letters.sqlite so they’re a little hard to do a search for.

It appears so. This is new code, so maybe the author can help at some point, but I’m seeing

which looks like it might be doing the .bak suffix, and the backup prefixed one might be from

The old Windows database was RC4 encrypted in its entirety by default. New one uses optional field-level encryption of sensitive data. There’s also a DB version update. That’s in second code.

It’s possible to look in the non-RC4 databases with an SQLite browser such as DB Browser for SQLite, but Duplicati is already looking in Duplicati-server.sqlite and not seeing jobs. Maybe the backup Duplicati-server… DB has them (see Backup table), but I wouldn’t count on it. The RC4 encrypted database (probably the .bak one, if I read comment right) may require old Duplicati.

As for the job database, the names appear to match regular expression ^[A-Z]{10}\.sqlite$ which you can use with Everything if you turn on Search → Enable Regex. This narrows results.

Finding the job database is not essential as they can be recreated, but they shouldn’t disappear, and their location might help solve the mystery of what server database was most recently used.

Default setup ought to be at SYSTEM profile location, but where’s the job database, and why is server database looking jobless as well? If you want, we can downgrade to 2.0.8.1 per article at
Downgrade from 2.1.0.2 to 2.0.8.1 but I’m not convinced that will fix, e.g. missing job databases.

13

No luck finding the job DBs. Checked my Windows update history and I did install the 24H2 preview on Dec 5th, which is the last day of backups I have and when it appears that DB backup was created. So perhaps the Windows version update wiped that folder instead of moving it, which would mean the .bak backup probably doesn’t contain anything.

14

You could look with something like installing 2.0.8.1 .zip into some convenient folder, stop other Duplicati to avoid interference, copy .bak file to some convenient folder, rename it, then run like:

Duplicati.GUI.TrayIcon --server-datafolder=<folder-with-the-old-server-database>

15

The TrayIcon itself does not have a Duplicati-server.sqlite file, it is more likely an issue with running the TrayIcon without --no-hosted-server, which will then run the server and create/use the database.

What are the sizes of these files?

Since there is an upgrade, there was clearly a Duplicati-server.sqlite file before the updated version started, but it seems peculiar that this could cause the backup jobs to disappear. I am thinking that maybe the size of those files could reveal if they were indeed empty prior to the updated version running.

Sadly, I think this likely the explanation. The Windows update wiped the folder, the Duplicati service created a new (empty) database, and the updated Duplicati upgraded an empty database.

What folder path is it exactly?

If Windows wipes the storage folder on updates, we need to change the code to detect this and use another folder.

16

I ran 2.0.8.1 to check the contents of the .bak file - empty as suspected (the files are 140kb).

The folder path is C:\Windows\System32\config\systemprofile\AppData\Local\Duplicati. I confirmed that the other folders in C:\Windows\System32\config\systemprofile\AppData were created fresh when I updated Windows so definitely a wipe there.

I’ll move forward with setting up the jobs again from the configs I had saved. Let me know if there’s any other info you need.

17

Thanks, I have registered an issue for this: