Upon further searching, I found the thread Help: Hash mismatch error. It appears that I’m having the same problem. But what is interesting is unlike OP of that thread, this is happening to me on an unencrypted, local backup where I’m using regular *NIX paths for both my source folders and the backup destination.
Following the advice in the linked thread, I set the option --no-backend-verification=true to see if the backup would complete if testing wasn’t done, and indeed, it did complete successfully with this option set. When I unset the option, it went right back to happening. Though it does seem to have chosen a different dblock file to verify, but same result - hashes don’t match.
I also reset --no-backend-verification back to false and tried setting --skip-file-hash-checks=true, and it completed successfully. Resetting --skip-file-hash-checks back to false again reverted my backup state to always completing with the error that the hashes don’t match.
The very last post to the linked thread mentions renaming a file and running the repair on the DB. He doesn’t mention what file he renamed, but if I had to guess, it was the index file. So I will attempt to rename the dindex file that was reported failed in the last test, and see if the repair helps.