"Detected blocks that are not reachable in the block table": What does it mean exactly?

SamSirry · April 20, 2019, 1:45am

I started receiving this message at the start of one of the back up sets.
Repairing didn’t help, and list-broken-files is not generating any output, so I assume nothing is to be purged.
However the error message is not clear where the problem may have originated. The message is mentioned here in the source code, but I couldn’t understand the condition that leads to it:

var tc = cmd.ExecuteScalarInt64(@"SELECT COUNT(*) FROM ""Remotevolume"" WHERE ""ID"" IN (SELECT DISTINCT ""VolumeID"" FROM ""Block"") AND ""State"" NOT IN (?, ?, ?, ?);", 0, RemoteVolumeState.Temporary.ToString(), RemoteVolumeState.Uploading.ToString(), RemoteVolumeState.Uploaded.ToString(), RemoteVolumeState.Verified.ToString());

if (tc > 0) throw new InvalidDataException("Detected blocks that are not reachable in the block table");

I’ve seen two other old posts about this, and they both resorted to recreating the database to fix it. I really would prefer to avoid recreation at this point.

Any idea that you can provide would be appreciated.

Thanks

Edit: I resorted to restoring an earlier backup of the database timed just before the error started appearing, and it worked. However, I’m still interested in understanding what that unreachable message means.

ts678 · April 20, 2019, 6:36pm

I think that’s typical of computer error messages that are reporting unexpected situations such as this.
Presumably this is more to stop damage from spreading and to alert developers about the problem so debugging can look for where the problem may have originated. That’s often extremely difficult, unless problems have a known test case to reproduce them. Rare and random without any clues is real hard.

How does Duplicati Resume After Interruption? speaks a bit about the states. Source code has others:

github.com

duplicati/duplicati/blob/d071d1b4da0b5dc176de7d61900e7ee9f9153633/Duplicati/Library/Main/Enums.cs#L54-L90


      
          /// <summary>

          /// Describes all states a remote volume can have

          /// </summary>

          public enum RemoteVolumeState

          {

              /// <summary>

              /// Indicates that the remote volume is being created

              /// </summary>

              Temporary,

          

              /// <summary>

              /// Indicates that the remote volume is being uploaded

              /// </summary>

              Uploading,

          

              /// <summary>

              /// Indicates that the remote volume has been uploaded

              /// </summary>

              Uploaded,

This file has been truncated. show original

My interpretation of the message is that blocks that the backup process would have put in block volumes somehow have no volume in a good state currently. Four are OK. Deleting and deleted are not accepted.

You could try looking in the database with a viewer, to see if it looks like volumes are there, in a bad state. Maybe instead, the problem was on the original backup work as opposed to a confused delete. Unknown. You can also run that SQL in the typical viewer (e.g. DB Browser for SQLite), remove the COUNT to see specifics, then see what you can make of all that in terms of characterizing the issue to chase the cause.

These are the sorts of things where a database bug report and logs (preferably at profiling level) help. Getting the bug report earlier would have been easier, but if you have the old DB it might still be possible. Even looking in the ordinary automatic job logs can sometimes find clues about what led up to that issue.

SamSirry · April 22, 2019, 10:09am

Thank you for the fat answer You have offered very useful tips, and I’ll work my way from there.

Regards