Verification errors - what do these mean?

I run Duplicati - 2.0.4.22_canary_2019-06-30 backups to a local NAS using sftp.

I have my installation configured to:

  • backup-test-percentage 100
  • full-block-verification true
  • full-remote-verification true

Previously I suffered a case of corruptions in my backup set that couldn’t be resolved such that I eventually ended up having to delete the backup files and starting over.

I seem to be having a different error message this time, and only a few, but I have no idea what these error messages mean, what their potential impact on my backup integrity is and what I should to do.

The messages are:

Errors 2

2019-08-16 17:46:11 -04 - [Error-Duplicati.Library.Main.Database.LocalBackupDatabase-CheckingErrorsForIssue1400]: Checking errors, related to #1400. Unexpected result count: 0, expected 1, hash: zuUuS/5iihvgQreeNDtyGBvl1g0hl7hdEI2+BtdbcXw=, size: 102400, blocksetid: 26129, ix: 4, fullhash: BPx7kkoBmOwTo9/XRV+oUgG7YttglKT701zd/vHMY20=, fullsize: 1416392
2019-08-16 17:46:11 -04 - [Error-Duplicati.Library.Main.Database.LocalBackupDatabase-FoundIssue1400Error]: Found block with ID 2743731 and hash zuUuS/5iihvgQreeNDtyGBvl1g0hl7hdEI2+BtdbcXw= and size 66976

Any help in understanding what is going on will be greatly appreciated.

And is there any way to find out what caused these errors so that they don’t recur or spread?

Thanks!

I don’t think I’ve seen any good explanation for this, but I’ll look at similar reports. There are several around.

Meanwhile, I’m cooking a theory, but I’ll hold it for the moment. What would help would be either you looking into your backup database with DB Browser for SQLite or similar (I can somewhat try to guide) or making a database bug report and posting a link to it. The DB doesn’t have your file data, but there’s some chance of pathname leakage because sanitization isn’t perfect. You can browse around yourself with the DB browser.

Also look around to see if there are any pathnames on other errors near this one. Some reports had them. Digging a pathname out of the DB might be pretty easy. Find “blocksetid: 26129” in File table. See its Path.
Possibly it’s something you don’t care much about, so possibly purging the file would remove the problem. Possibly also the File table doesn’t have that entry because transaction design backed it out or something.

is where the error is. It’s adding a blockset, which is the term for a file because it’s kept as a set of blocks. Some code seems to expect that all blocks except the last will be full blocks (102400 byte default), but it looks like a short block showed up. Blocks kept showing up until “fullsize: 1416392” was reached, but the short block partway through (it’s on the fifth block, i.e. “ix: 4” here) is raising an error and stopping a save. Probably the result is whatever file that is is short, but that actually might have been an earlier real length. The *Issue1400* is generally suspected of happening when files were changing at the time of the backup. Sometimes exclusions help (if the path can be found), or. –snapshot-policy can be used to keep view still.