Different DBs depending on command

1

I run a backup-job where DB ist set to
c:\ProgramData\Duplicati\FDAQWYRJMD.sqlite

Weirdly when running a list-broken-files command I get this error…

ErrorID: DatabaseDoesNotExist
Database file does not exist: C:\ProgramData\Duplicati\HNQUVBWCJG.sqlite
Return code: 100

…which is true.

Anybody got an idea on how to get rid of the latter and how to see the actual state of broken-files?

2

The full command uses a remote url, like:

Duplicati.CommandLine.exe list-broken-files ftp://server

When done like this, Duplicati takes the remote destination and makes a version of the url without passwords etc. This url is then matched to the file dbconfig.json to find the name of the local database.

It generally works, but you can also get misses if some details change. You can look in dbconfig.json to see what mappings are registered.

To avoid the mapping logic, use --dbpath=<path-to-file.sqlite> to bypass the dbconfig.json lookup and force the database you specify.

3

@kenkendk thx for following up.

Defined in ngclient are six different jobs and I’d assume these should have corresponding entries in dbconfig.json?

But in dbconfig.json are only three entries from which two refer to the same job and storage but with different username and DB, which seems not right to me.

Question: When the json is mapping the DBs with the meta-data of the jobs, how are these running at the moment while not having a valid entry there :thinking:

4

No. With the Server (or TrayIcon) the settings are stored in Duplicati-server.sqlite which will internally make sure to send --dbpath to all operations. Inside the database there is a table called Backup and a column named DBPath that has the path for these.

They are using the Duplicati-server.sqlite to keep track of the paths.

1 Like
5

How do you run it? As a GUI job with “Run now” button?

Looks like the kind of thing GUI “Commandline” run says.
If this is what you’re doing, don’t delete pre-filled dbpath.
That will make Duplicati assign new dbpath for command.

GUI and CLI use different DB assignment. CLI (and sometimes GUI Commandline) uses dbconfig.json. GUI uses Duplicati-server.sqlite. Don’t accidentally switch between those.

Using the CLI

If you specify the --dbpath parameter, it will not use the dbconfig.json file and it will not store anything in the local datafolder.

So GUI Commandline gives the GUI dbpath. Just don’t delete it, or you’ll get a CLI one.

If I’m guessing wrong at how you’re running things, please clarify how you’re running this.

EDIT:

Command Line Interface CLI

Each command also requires the option --dbpath=<path to local database>, but if this is not supplied, Duplicati will use a shared JSON file in the settings folder to keep track of which database belongs to each backup. Since there is no state given, the remote url is used as a key, because it is expected to uniquely identify each backup. If no entry is found, a new entry will be created and subsequent operations will use that database.

but you don’t want a new entry, so if the GUI pre-filled its dbpath, keep on using that DB.

1 Like
6

I’m running GUI only via the windows-service. I guess the json is from some former commandline operations then.

Can’t I just delete it then, 'cause the Duplicati-server.sqlite does the job?

7

I assume that means you ran WindowsService install, use Services app or sc admin, etc.

dbconfig.json can be deleted if all jobs you care about work in GUI non-Commandline.
On the other hand, it’s a tiny file, so there’s not much point. There’s a chance that space waste was bigger if any of the assigned databases got filled, so you can delete those too, probably doing at least a sanity check of an old date as a sign that it’s some old accident.

GUI database paths (in Duplicati-server.sqlite) and CLI database paths (in dbconfig.json) are random and independent, but manual edit in GUI Database screen can connect them.

2 Likes