First, some problem diagnosis is required, but before that, how did “backup fail on PC1”?
I suspect you might just have an extra dindex file, but proving it’s extra is kind of difficult…
If you like, you could rely on the error message plus perhaps at least some sanity checks.
Sanity check:
If you have more files at destination with dindex name than dblock, you might have extra.
If the dindex file listed in the error has a timestamp near end of failed backup. that’s a clue,
however if timestamp is earlier the problem may have been seeded earlier. Got good logs?
Better check:
Creating a bug report from PC1 and posting a link to it so somebody can look at database.
Harder check:
If you are willing to copy the database and look in it, you can install DB Browser for SQLite.
Database browsing is similar to looking at a spreadsheet. I can provide more detailed info.
Basically you would look for the mentioned dindex in Remotevolume table Name column,
then look for that ID in IndexBlockLink table.IndexVolumeID column. It’s probably not there.
If not there, you can just delete it from the destination. If in doubt, you can move it instead.
The purpose of a dindex is to index a dblock (whose name it knows). You seem to have a
dindex that has no dblock, so it’s not doing anything useful, and is generating a complaint.
Remote file referenced … but not found in list, registering a missing remote file #4586
is what you might have hit, or maybe the cause was different but the damage was similar.
The problem I had is latent and backup runs fine until a database recreation notices issue.
This means it could also be rather old. The time on the dindex file might say when it arose.