Error accessing database version 9

Hi there !

After an update to 2.0.4.23_beta_2019-07-14 I get the following error message, when trying to recover files:

The database has version 9 but the largest supported version is 8

I couldn’t find any reference to this version nor to the specific error message, only for version 8 not being able to read version 7.

However, I followed the suggested steps to solve the problem,i.e. deinstalling and installing duplicati from scratch, bit I still get the same error.

Has anyone an idea or a suggestion, what to do ?

Thanks a lot in advance!
best regards
Richard

Short answer: Go back to the version you were using.

Long answer (I am sorry for my part in making it a bit too long): Release: 2.0.4.23 (beta) 2019-07-14

You are not the only one tripped up by the versioning scheme. Release 2.0.4.23 is not a successor of the release from which you upgraded. The release channels are separate, and generally, you cannot jump from an experimental or canary back to a beta.

Hi !

Thanks for the quick answer.

I’m not sure, which version was on the machine. My guess would be an experimental. Would that be in line with the symptoms ? Which version DOES support version 9

Is there a way to simply convert the database to the canary version, once I got running again ?

As a suggestion, when running the installation a message could be shown that explains, that a database version is being changed and what consequences (e.g… switching to experimenta) it has.

Thanks and best regards
Richard

I’m thinking v2.0.4.13-2.0.4.13_canary_2019-01-29 through (so far) v2.0.4.22-2.0.4.22_canary_2019-06-30 however if you’re not testing bleeding-edge canary releases, v2.0.4.21-2.0.4.21_experimental_2019-06-28 might be what you had. Typically experimental is pretty stable and leads to beta. This time though, that has not yet happened, and v2.0.4.23-2.0.4.23_beta_2019-07-14 is the previous beta plus a necessary warning. Rushing out a truly updated beta was considered too risky due to the extent of change, however so far the field experience of some (unfortunately not known) number of experimental users seems to be quite good.

Depends on what “got running again” means. If you revert to experimental, or canary if you had that before, then conversion to truly newer database versions is automatic. Downgrades would confuse the old code…

Given the wide variety of installers in existence (consider Linux, for example), I’m not sure whether it would be possible for the new code to warn the user (and if it warns, a “cancel” option would be nice to go with it). You could open a Feature category topic to see if people will discuss it (it might not actually get done soon).

If you mean the installation done entirely by Duplicati to upgrade itself, that’s maybe more workable, and will also avoid accidental downgrade because it’s channel-aware (within channel, things should move forward).

Those who install manually can have issues, and the release note could have had a better warning without assuming people understand the risk of changing channels. Relative to prior beta, it’s exactly correct, but if one is on something else (e.g. a recent canary), it’s downgrade of most everything since the previous beta.

I’m assuming your update was a manual update, or your experience disproves my “stay-in-channel-is-OK”. Using the Duplicati updater, one can find the prior version easily (and read changelog.txt), but not if you run update as an install, which updates the base version. If you have old backup emails, they show the version.

Just to report back, deinstallting and installing, in my case, the experimental build, solved the problem.

Thanks a lot for your support!

best regads
Richard

Thanks for letting us know it worked, and thanks for running experimental. It’s recently the last line of tests before things go beta. Occasionally changes get made, but it’s typically been in special cases not general.

People who run canary are also very valuable. Often new fixes make it better but new bugs make it worse.