All backups and settings missing after upodate to 2.2.0.3

I have just updated to the latest version (2.2.0.3_stable_2026-01-06). I am not sure which version I was running before, but it wasn’t too old as I update regularly.

After rebooting and logging in, it looks like a brand new install. None of my settings, backup schedules/settings are there…. I am kind of at a loss. Anything I can try to do to recover those? If not, is there a way to set up the back without it having to start form scratch (avoid doing a full backup). I still have all the files that were created by previous backups.

Welcome to the forum @mrmmm

What operating system is this on?

How do you get access to Duplicati UI? Please see Choosing Duplicati Type.

Basically, TrayIcon can automatically log you in (harder if you use a Service).
Start menu, desktop icon, browser bookmark, and typing a URL are possible, however they’re more likely to want you to type a password since 2.1 release:
Duplicati Access Password

If you use a service, one easy way to have an “empty” look is to connect to a different Duplicati. Configuration is per-user, e.g. Windows databases default:

C:\Users\<user>\AppData\Local\Duplicati

The server database

All configuration data, logs and settings are stored inside the file Duplicati-server.sqlite.

When a Duplicati version update updates database version, a backup is made. Possibly you will see one, however if you changed users, all will look very new.

You can also see Task Manager or similar to see what Duplicati processes are.

The local database is usually straightforward to recover on the Database screen, however you should find your configurations first. I guess you created no Export?

Hi.

I am running Duplicati in a proxmox LXC on Linux (Debian 12). I access Duplicati through the web interface. After updating, I ran the command to get the PW and logged in with that.

And no, I did not create an export, unfortunately.

Thank you.

Is that with someone’s Docker image, or totally DIY?

How does one do update in your system?

For a Docker, one is supposed to just update the image, because configuration is supposed to be on the host not the container. Here are directions for two images:

https://hub.docker.com/r/duplicati/duplicati
See Preserving configuration

https://hub.docker.com/r/linuxserver/duplicati
See /path/to/duplicati/config:/config

Yes, this was installed using ProxMox helper scripts and the update script is here: https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/ct/duplicati.sh

I have used that script to update in the past without a problem…

Mount host directory into LXC container (Proxmox forum) and other search results suggest that it’s possible to do Docker-style storage of config on host – but do you?

Since you’ve got Duplicati up, you can search host for Duplicati-server.sqlite. Presumably (I don’t use Proxmox) you can search in the container. Where is yours?

If you do something like Linux find, being generous might help, because if there’s a backup copy of the database (would be nice if there is), name will be a little more, so use some wildcard like asterisk (or whatever your search uses) before and after.

Looking at mine, *Duplicati-server* probably find either current or backup DBs.

Database location on Linux is another place to start looking, if you know your user.

Regardless, your destination files should be sufficient to recreate the job database, however job may or may not be hard to reconstruct from memory and the file view.

Not helping me much, especially since it calls to other functions that aren’t shown. Maybe this is more like a non-Docker upgrade where it replaces the package and then the package does what it needs to upgrade other things like config database.

This has had problems for unknown reasons on a few systems, but I’m not certain about your upgrade approach, and regardless you should find config files and any backup copies (which will be made before a database upgrade, if one is required).

Thank you for the replies. Really appreciate it. It looks like I do have a backup sqlite file, but it is not from the last time I upgraded (looks like it might be from the previous one).

This is what I have in the Duplicati folder on the LXC (i did search everywhere, and this is the only place I have *Duplicaty-server*):

drwx------ 3 root root 4096 Jan 28 13:23 .
drwxr-xr-x 19 root root 4096 Jan 28 13:32 ..
-rw------- 1 root root 114688 Oct 28 09:25 ‘backup Duplicati-server 20251028092742.sqlite’
-rw------- 1 root root 89731072 Oct 28 09:25 ‘backup UCTKGZOMPE 20251028092749.sqlite’
drwxr-xr-x 2 root root 4096 Jan 28 13:25 control_dir_v2
-rw------- 1 root root 139264 Jan 28 13:23 Duplicati-server.sqlite
-rw-r–r-- 1 root root 283 Apr 2 2025 installation.txt
-rw-r–r-- 1 root root 247 Apr 2 2025 machineid.txt
-rw------- 1 root root 102301696 Jan 28 03:01 UCTKGZOMPE.sqlite

So, looks like the only backup is from Oct 28, but the latest update would have been some time last week. An I am pretty sure I had recreated the full back up since then, since I had some corruption right around that time.

So, given this state of events, what’s my best bet to continue backing up without doing a full backup? (Is there a way?)

Thank you.

I assume that means DB backup (I’ll ask later about backup running).

That looks like the only database update done in the 2.2 series so far.

v2.2.0.0_stable_2025-10-23 (maybe this was your Oct 28 upgrade?):

Database updates

This version updates the format of the local database to version 17.
This version updates the format of the settings database to v9.

2.2.0.3 uses the same DB versions, although it’s not called out in note.

If you’re quick to update, Oct 28 might have been from Oct 23 2.2.0.0.
What seems odd are the Jan 28 files, looking like a server and job DB.
Are those dates newer now? Maybe the scheduled backup is running?

Your script looks like it gets the linux-x64-gui.deb, so the TrayIcon one.

Duplicati Access Password

Note that the password itself cannot be extracted from the database, it can only be verified.

If you found a command that easily shows the password, that may be an issue.

Regardless, you got in to something, but what’s there was looking overly empty,
which seems to conflict with two databases that look like that backup is running.

Or maybe it was a DB (?) recreate you note. Too many things are mixing in now.

I suppose looking at installation files (e.g. with ls -lc`) might find the exact date.

I’m lost, but suspect you recreated the job DB, but how did you do it without job?

If you can access the destination, can you sort by date and see what uploaded?

State of events is not clear. If you see recent destination files, it suggests backups are working (especially if you have a scheduled one – do you?). Manual run would require the GUI showing the job – but so would its database recreate. Inconsistent.

Even though you did a database search, you can also look at Duplicati processes, making sure there aren’t any extra there. Unlike Duplicati 2.0, they aren’t doubled.

About → System info → UserName should (I hope) say you’re root, or the perms I see won’t work, but this wasn’t a 2.2.0.3 change. Perms were tightened in 2.2.0.0.

You can also try a browser refresh (harder is better), or use Settings to see old UI.

For a brute-force opinion on what’s in the Jan 28 Duplicati-server.sqlite, you could look at it in sqlitebrowser, or more crudely in less, or do strings pipe less. Look for something you recall, e.g. a path used, name of the job. Any signs there?

Sorry for muddying the waters with ambiguous usage.

The last update to Duplicati was on Jan 28. That’s when the Job in Duplicati disappeared. No new files have been backed up since then. So, the jobs are not running.

The backup sql file i have (backup Duplicati-server 20251028092742.sqlite) is probably from the time I updated Duplicati before the last time.

I have tried opening in incognito and switching back and forth between the new and old UI. The job does not appear.

Interestingly, I can still see references to the backup job in the current “Duplicati-server.sqlite” file when just looking at it with a plain text editor, which tells me that it wasn’t overwritten…

Thank you.

This suggests that schedule runs were running before. Maybe the 3:01 AM DB on Jan 28 was the last one before an update Jan 28 daytime that also broke the GUI.

DB Browser for SQLite (sometimes sqlitebrowser package) could look closer. Backup definitions start at the Backup table. It’s conceivable that yours emptied, and seeing remnants might just be leftovers that aren’t logically in that table now, somewhat like free space on the computer isn’t normally wiped on a file deletion.

The server database can have sensitive information. You get nagged to secure it, however not everyone does. Do you know if you did? Any 2.2 would have asked, however I’m not sure if your 2.2.0.3 upgrade procedure could have lost its access.

Usually lost access complains, so check your logs with journalctl or whatever.
What’s running anyway? You got a TrayIcon but is it running as systemd service?

Regardless, you can check all Duplicati processes, stop them, then start by hand, as an alternative to systemd logs. It’s also easier to add options, per the --help.

While I would prefer to understand the issue, and developer help is most welcome, trying the 2.2.0.3 version of the Oct 28 2.2.0.0 upgrade might be possible. Stop all Duplicati processes, rename server DB (might still want a look at it later though…), copy the Oct 28 server DB into its place, start Duplicati, and expect another backup of server DB, and updated-to-2.2 Duplicati-server.sqlite to appear. But will all work?

There have also been people who somehow just got bad upgrades. I don’t know if you can force 2.2.0.3 in again with your scripting, but it might be another option…

Another option is to see if the query to list the jobs got stuck as opposed to saying there are no jobs. This can be done in browser developer tools on browser menu (sometimes F12 key, but it varies). Old UI seems easier. Refresh and look for the backups?orderby=id query response (or lack of response, if something is stuck).

Another option is similar, except you can’t see as well. Presumably if it quickly says there are no jobs, then that’s the answer. It uses the same HTTP API browser uses:

Duplicati.CommandLine.ServerUtil --help
Description:
  Server CLI tool for Duplicati

Usage:
  Duplicati.CommandLine.ServerUtil [command] [options]

Options:
  --password <password>                                The password to use for connecting to the server []
  --hosturl <hosturl>                                  The host URL to use [default: http://127.0.0.1:8200/]
  --server-datafolder <server-datafolder>              The server datafolder to use for locating the database and storing configuration [default: C:\Users\Ted\AppData\Local\Duplicati\]
  --portable-mode                                      Use portable mode for locating the database and storing configuration [default: False]
  --settings-file <settings-file>                      The settings file to use []
  --insecure                                           Accepts any TLS/SSL certificate (dangerous) [default: False]
  --settings-encryption-key <settings-encryption-key>  The encryption key to use for the settings file. Can also be supplied with environment variable SETTINGS_ENCRYPTION_KEY []
  --secret-provider <secret-provider>                  The secret provider to use for reading secrets []
  --secret-provider-cache <InMemory|None|Persistent>   The secret provider cache to use for reading secrets [default: None]
  --secret-provider-pattern <secret-provider-pattern>  The pattern to use for the secret provider [default: $]
  --host-cert <host-cert>                              The SHA1 hash of the host certificate to accept. Use * for any certificate, same as --insecure (dangerous) []
  --json                                               Wraps stdout as a json [default: False]
  --version                                            Show version information
  help, usage, -?, -h                                  Show help and usage information

Commands:
  pause <duration>                Pauses the server []
  resume                          Resumes the server
  list-backups                    List all backups
  run <backup>                    Runs a backup
  login                           Logs in to the server
  change-password <new-password>  Changes the server password
  logout                          Logs out of the server
  import <file> <passphrase>      Import a backup configuration
  export <backups>                Export a backup configuration
  health                          Checks the server health endpoint
  issue-forever-token             Issues a long-lived access token
  status                          Gets the server status

I sort of prefer the browser method because one can actually view HTTP activity. Doing that without a browser would mean having to capture and decode packets.