Problems after Release Upgrade

Support
1

With the update to 2.0.4.16 I had encountered problems with the local DBs of 3 jobs. It shows differences in the file count.

So I tried to repair the local DB, I tried to create new ones, also with different file names but all fail with “File length is invalid”

Or I receive “The database was attempted repaired, but the repair did not complete. This database may be incomplete and the backup process cannot continue. You may delete the local database and attempt to repair it again.”

The repair or recreate does not work. neither with a manual restore of the local DB nor with newly created DBs

A fallback to 2.0.4.15 was stable in the meantime all the time. But I am interested to be up to date with the stable versions.

I have retried the upgrade with 2.0.4.19 again. The issue is the same like it was in April.

My question is: How may I upgrade to the most recent stable version with keeping my existing history (about 20-30 versions)

How should I proceed in order to analyse the root cause?

2

Being on canary, you will enjoy more bug fixes that may add stability, but fixes and new features can give surprises too, and the job of those who choose canary is to help find and report problems at early stages. Basically I’m not sure which version of “stable” you want. Canary is sometimes better, sometimes worse.

One thing that’s sure is that moving backwards is not always possible (database formats change) unless you’re willing to do a Recreate. Storage formats on the remote are stable over long periods, unlike the DB.

If your “differences in the file count” means message “Unexpected difference in fileset …” with two counts, that has a proposed fix stemming from “Unexpected difference in fileset” test case and code clue #3800 but it is not in any canary. Hopefully it will get into the next release whether it’s a canary or an experimental.

If you want stable as canary-stable, you would be notified when upgrades come out. Download and install. Sometimes a Duplicati restart is needed for it to take effect, but any database format change is automatic.

If you want stable as in 2.0.4.5 beta from last November, then uninstall canary, delete any updates that are laying around that would otherwise get detected and run, then install 2.0.4.5 beta and do the DB Recreate.

Downgrading / reverting to a lower version

Based on releases I’m guessing that’s the 2.0.4.16 section which has 4 issues. Which ones do you see? First was maybe explained, “File length is invalid” and “attempted repaired” and “does not work” were not.

It depends on how deep you want to get. Code is at https://github.com/duplicati/duplicati and one starting technique is to use a tool such as Notepad++ to look for messages, then learn the context around them. Finding root causes isn’t easy. If you can find steps to reproduce a problem reliably, it gets much simpler. There’s a quite reasonable set of internal documentation. I just linked to some useful material in this post.

For people who don’t want to root cause at a code level, simple steps to reproduce really help developers who might step in after someone has told them exactly how to recreate the problem and opened an issue.

EDIT: Running a bleeding-edge release like canary seems a poor match for wanting long backup histories. On average, canary should get better over time (then become beta), but the exceptions to that may hurt…

1 Like
3

Thank a lot, ts678!
and sorry for my late reply - just arriving back from a vacation.
I guess what I mean by stable (pardon my poor English skills) that I am not able to perform the DB Recreate as well the downgrade. So I feel to be in a dead lock situation. (Stable would be for me to find a way out and to avoid a new initial backup because of a change in DB structure or for other reasons)

I deleted all config entries I found, based on the description by JonMikeIV https://forum.duplicati.com/t/downgrading-reverting-to-a-lower-version/3393

Windows
a. C:\ProgramData\Duplicati\updates (deleted)
b. C:\Users\<Duplicati user account>\AppData\Local\Duplicati\updates\ (checked for all users)

Anyhow I am not able to manage the downgrade. After re-install it still shows the latest version ( I am very sorry, I appear to be diletantic…)

So now I have installed version 2.0.4.22
I now have change to the english language settings: the error message is “File length invalid”.
The log shows

grafik
grafik.png1161×380 52.2 KB

=> Do you think it is necessary to do a new full initial or can you think of any way to be successful with a DB recreation?

Thank you!

4

Hello ts678
do you have a chance to review my last post and advice?

5

What backup storage are you using, and can you download files or at least look at the lengths of the files?

You need to get some idea of what “File length is invalid” looks like in terms of actual and expected length.

Is this just one file throwing that exception, or lots? It also matters whether it’s a dlist, dindex, or dblock file.

For 2.0.4.22, the backup log in the GUI can probably give you an idea of how many of these are happening.

As a long-shot, be sure you don’t have any connection speed throttling set by options or control at GUI top.

6

If your backend storage is “FTP (Alternative”), you might be seeing this issue which showed up in 2.0.4.16:

Problems after upgrade to 2.0.4.21

and if your ordinary log doesn’t show filenames and sizes, you can use that as an example of how to use a live log. Adding –log-file option is another alternative to see more details, but is perhaps a bit more to set up.

7

@ts678, you have been right. The root cause is the I had used FTP (Alterantive), as the normal one originally made problems while I tried to set it up in Duplicati.

Now I was able to easily switch to FTP and I was already able to repair two of three sets of backup.
The third one is still running.

So thank you a lot for your help!

Holger