block – Is every copy of the blockchain the same? If I have an error within file should I be able to copy this file from a backup and reindex chainstate?

I recently moved the first 2000 files of my blockchain from the SSD to a HDD. The HDD gets mounted in /mnt/ext.

A symlink per file is then put into blocks that points to the remote files. So my blocks folder is still on SSD, but the files are on HDD.

I tried a bitcoind -reindex-chainstate to be sure everything still works but now it is giving an error:

2020-11-26T12:52:24Z ERROR: ReadBlockFromDisk(CBlock&, CBlockIndex*): GetHash() doesn't match index for CBlockIndex(pprev=0x44288c0, nHeight=255, merkle=4309bfeed77a70f309da08bcf8948906b9cc26120c0b0ef86e0ac67284bbd79e, hashBlock=00000000d0a75c861fabf9ff7b92022f60e4afeed9331fe5aa073d8e4706fe3c) at FlatFilePos(nFile=0, nPos=58808)
2020-11-26T12:52:24Z *** Failed to read block

Now I have several questions. I think nFile=0 means that the block is in blk00000.dat and rev00000.dat. Am I right?

So I copied this file again from a backup of the blockchain. This is from a second node. But I would suspect the files are the same, right?

But I get the exact same error at the same position – even with a new -reindex-chainstate.

I can see in the log that all blocks up until number 254 get indexed but each time it fails on block with height 255.

I think those old files contain always the same blocks. How can it be 254 blocks are correct but it fails on the next one?

Could this simply be a problem of the mount?

EDIT: I am currently -reindexing. In this case the files I already have linked to from my blocks folder get used like this:

Reindexing block file blk00000.dat...
Loaded 119964 blocks from external file in 133291ms

Apparently, the first file contains 119,964 blocks. So when I have an error with height=255 it should definitely be in the first file.