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.
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.
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.
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 profilinglevel) 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.