Duplicacy-Web preferences bug?

Support
#1

I’m running Duplicacy-Web in a docker container. I have 3 backup tasks.

Browsing through the docker configuration files, I found 3 preferences files each under the following directories…
/docker/duplicacy/cache/localhost/0/.duplicacy/preferences
/docker/duplicacy/cache/localhost/1/.duplicacy/preferences
/docker/duplicacy/cache/localhost/2/.duplicacy/preferences

I expected that each preferences files would correspond to an individual backup task. Instead, each preference file shows 3 backups, only one of which is correct. For example…

{
        "name": "photos",
        "id": "my_library",,
        "repository": "/library",
        "storage": "b2://photos",
        "encrypted": true,
        "no_backup": false,
        "no_restore": true,
        "no_save_password": true,
        "nobackup_file": "",
        "keys": null,
        "exclude_by_attribute": false
    },
    {
        "name": "music",
        "id": "my_library",,
        "repository": "/library",
        "storage": "b2://music",
        "encrypted": true,
        "no_backup": false,
        "no_restore": true,
        "no_save_password": true,
        "nobackup_file": "",
        "keys": null,
        "exclude_by_attribute": false
    },
    {
        "name": "library",
        "id": "my_library",
        "repository": "/library",
        "storage": "b2://library",
        "encrypted": true,
        "no_backup": false,
        "no_restore": true,
        "no_save_password": true,
        "nobackup_file": "",
        "keys": null,
        "exclude_by_attribute": false
    }

In this one, only the 3rd entry is correct. The “library” repo goes to the “library” backup bucket… But the music and photos repos do not (they are connected to buckets for music and photos)… and the other two preferences files include a correct task for each (along with two incorrect tasks).

The other two preferences files are similar, where one of the three backup tasks is correct. Overall. each preferences file shows one correct backup task out of three.

Out of curiosity… I stopped the container and edited each preferences file, so that only the correct task appeared. Then I restarted the container and ran each backup task. When they were complete, I re-examined the three preferences files and saw that again, each contained three tasks, only one of which was correct.

I’m wondering if the integrity of my backups are good.

Before moving to docker, I ran Duplicacy-Web natively. Since those files still exist, I checked and found the same anomaly. Each preference file showed multiple tasks, only one of which was correct.

Why is this?

#2

It has nothing to do with integrity, it’s not an anomaly, and is likely an artifact of how these (temporary, volatile, and discardable) repositories are initialized. Since these extra entries do not cause any issues and are not visible to the user there is no incentive to “fix “ it. It would be superficial change, requiring extra testing, for no real world benefits in return.

Duplicacy-web creates temporary repositories in the designated temporary folder for duplicacy CLI to perform various tasks every time, so editing them manually is pointless, they will be overwritten.

Whatever else is in the files is irrelevant as long as the specific section in the preference file for the specific repository the actual task is intended to operate on is correct. Why does it create extra files specifically — nobody but the author can explain since duplicacy-web is a closed source product. And yet, I would not worry about it. It’s implementation detail and it does not matter.

#3

All backups share the same preferences file. The other 2 entries are actually correct – in each of them the storage key points to the correct bucket.

#4

But two of them refer to the wrong repo and wrong ID. Each backup uses a unique repo and ID.

#5

It does not matter - it’s by design, the ‘wrong’ ones won’t be used; they’re superfluous but their being there won’t harm anything. Only one entry is used at a time, and the Web UI only uses the correct ones for the particular repository to the particular storage.

I suspect it’s done this way to straightforwardly support backing up to multiple storages. When, or if, you add a job for an existing repository, to an existing storage, the entry is already there.

In the GUI, the preferences files pre-populate the necessary settings from the duplicacy.json (don’t go tinkering in there; you’ll only break it and you’ll not make it work how you think it should), and so you also shouldn’t be editing these files directly as they’ll just get overwritten.

#6

The point of this “discovery” began with the desire to migrate one (or more) of the Duplicacy-Web backup tasks to Duplicacy CLI… I thought if I could copy the preference file from Duplicacy-Web, I could use that (in part) to continue the existing backup chain via CLI.

Thanks!

#7

That’s fine… just copy the preference and optionally remove the entries you don’t need. Or just init them as normal. You can even use the existing GUI configuration as-is, with the CLI, by just using the -storage <name> as an index into the correct repository-storage combo.