Went into UI configuration today, my backup jobs have disappeared

Support
1

On my laptop I went to 127.0.0.1:8200 to update my backup configurations to backup more files. Upon going in, the entire backup configuration for my two backups are gone. I’m hoping to get them back.

Fortunately I have saved the backup configurations elsewhere. I started by restoring one configuation from a .json config file I had stored elsewhere. It took. Then I tried to run backup. It said about 1700 files were missing, to run repair, which I did, now I have only 1 restore version available.

I’m trying to hunt down how or why this happened and get all my versions back. My best clue: when I entered the UI interface initially today, it said to update to the latest Duplicati release (which I wasn’t thinking, I already was on the latest release). But it went ahead and went through the install process anyway. That’s the only thing I can think that went different. Then I went to the configs, and my configs were missing.

When I go to this folder:

C:\Users\[my account]\AppData\Local\Duplicati

I see these:

Duplicati-server.sqlite - a few minutes old - 200 KB
89657290657268816978.sqlite - 4 hours old - 250,788 KB
70867474828982687370.sqlite - 4 hours and 2 minutes old - 524,812KB

Could I just use that prior sqlite files? If so, how do I do it?

2

More info. I went ahead and rebooted.

When I did so, suddenly both backup configurations were back (I had only manually restored one configuration). Of the one I manually restored, it said its last backup matched the time of the file: 70867474828982687370.sqlite - 4 hours and 2 minutes old. But it only had 1 version.

Of the one I didn’t touch, its normal. It has many versions and backups just fine.

Of the one I did manually restore the configuation, I got some errors requiring a repair , then 3 errors about “Failed to accept new index file: . . . zip.aes, message: Unknown remote file” Now it’s working with 1 version only.

My best guess is that when Dupliacti thought it had to update itself and ran the installer, something went wrong backend side and the UI frontend couldn’t obtain a list of the configuration that were in the sqlite database. When I forcefully reset one of my configs by reloading the config from a .json backup file, then it overwrote what really was still there in the database.

3

One possibility is that you’re actually running more than one instance of Duplicati. Depending on the order they start up, one will bind to port 8200, the next 8300, and so on. Different instances will have different configurations.

Out of curiosity try going to http://localhost:8300 and see if you see another Duplicati web UI without any jobs listed.

4

Nothing on localhost:8300. I’ll try that in the future if I see that happen again.

In the meantime, what’s the best way to “backup” the backup database? I want to save file versions. I find I overwrite important documents more than I accidentally delete them, and I don’t discover the overwriting problem until months later. I didn’t realize “repair” loses versions.

Do I just need to backup the Duplicati-server.sqllite and each .sqllite database corresponding to each configuration?

Is there a document for this? Or is it just easily explained?

5

It doesn’t. Can you clarify where you read this?
Versions are retained per your retention policy settings. What do you have it set to?

Some opt to back up the Duplicati-server.sqlite file to make it easier to recover from a disaster. It contains all your job configurations. Alternatively you can simply export your job configurations to a json file and store in a safe place. (I personally do the latter.)

Backing up the large job-specific sqlite files is not necessary as they can be regenerated from the back end data.

6

Hmm, seems I was wrong. In my two backups, the one that has all my prior versions has this:

      {
        "Filter": "",
        "Name": "--keep-versions",
        "Value": "0",
        "Argument": null
      },

But the one that I thought also had many versions instead had this:

      {
        "Filter": "",
        "Name": "--keep-versions",
        "Value": "1",
        "Argument": null
      }

That does answer the version issue. It wasn’t repair that lost the versions, my config was accidentally wrong from the beginning.

7

appears inconsistent (assuming you actually did restores of some documents) with this recent finding:

How often do you export the configuration? I wonder if it was wrong at last export, but better recently?

If it matters enough, you can look at your destination for dlist files with the UTC date of their backup.
You can also go into the Restore option to see how many versions your database thinks backup has.
If both show only one version, then that’s probably what you had before things went weird - somehow.

The least reliable statistic is on the Home screen right after doing config import. If you used the option
“Import metadata”, you get statistics from the time of the Export To File, which would now be stale.
Next backup will update home page statistics though. I’m not sure if you did that, or are moving slower.

If you truly have only one backup version, you might consider just starting again, because your Repair complained about a number of things. To be careful, you can clone the old job, and give it a new folder.

Add backup always makes a new (therefore empty) database, but doesn’t force a destination change.
Because database is empty, an attempt to just run that backup without using Database page to install
good database will error “Found # remote files that are not recorded in local storage, please run repair”.

By “good database” I mean one matching the backup destination. An old one can get severe problems.