*broken* Release: 2.0.4.13 (canary) 2019-01-29

Releases
21

That sounds like a plan.

I’ve still got my backup databases so I can verify the change when it’s out.

22

The entire (updated) script is here:

If you run this on a pre-upgrade database, and replace the broken database, then it should work afterwards with 2.0.4.13.

It is a bit subtle in that if you have never removed a file from a backup, the old script will still work as the IDs are sequential anyway. In my database, the first File entry has ID=18036, but if your first has ID=1 it works correctly until the first skipped ID (from a previous delete).

I will test the updated script on my databases now.

23

My databases update correctly now.

Edit: new version uploaded: https://forum.duplicati.com/t/release-2-0-4-14-canary-2019-01-30/

24

Thanks everyone for sorting this out - as I fell back to the previous version and database I will try going from .12 to .14 on a couple of systems and see how it goes.

25

Thanks for the new release!
I did the 3 Steps and everything is working again.

Step 2: i compared the last finishing-date + time (gui duplicati) with the timestamp of the sqlite database files and could then rename the files to the matching database-name.

Thanks for the quick help!

26

Unfortunately it’s kind of a weird scenario.

Even if our tests upgrades the previous backup DB to the new one that test could easily have succeeded. This error only happens if you’ve had retention delete files from your backup (causing ID’s to not be sequential)