<blockquote>
<p>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?</p>
</blockquote>
<p>No. Blocks are downloaded out of order, but are written to disk in the order that they are downloaded. So the block index (which states where each block is located) will be different for every node because every node will likely have the blocks stored in a slightly different order.</p>
<p>Furthermore, if your node has received stale blocks, those stale blocks are also stored on disk and have an entry in the block index. Not all nodes will have the same stale blocks, and they may not be stored in the same order. Newly synced nodes will not have stale blocks from before they were synced, and often times stale blocks become stale due to propagation delays, so a node may not even receive a stale block to store.</p>
<p>You can't just copy individual block files from one node to another. You need to copy the entire blockchain and the block index. Otherwise you will probably corrupt the whole thing and need to redownload the blockchain.</p>

CC BY-SA 4.0
2020-11-26T17:34:44.613Z
2020-11-26T17:34:44.613Z
Ava Chow
<p>I recently moved the first 2000 files of my blockchain from the SSD to a HDD. The HDD gets mounted in <code>/mnt/ext</code>.</p>
<p>A symlink per file is then put into <code>blocks</code> that points to the remote files. So my blocks folder is still on SSD, but the files are on HDD.</p>
<p>I tried a <code>bitcoind -reindex-chainstate</code> to be sure everything still works but now it is giving an error:</p>
<pre><code>2020-11-26T12:52:24Z ERROR: ReadBlockFromDisk(CBlock&amp;, 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
</code></pre>
<p>Now I have several questions. I think <code>nFile=0</code> means that the block is in <code>blk00000.dat</code> and <code>rev00000.dat</code>. Am I right?</p>
<p><strong>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?</strong></p>
<p>But I get the exact same error at the same position - even with a new <code>-reindex-chainstate</code>.</p>
<p>I can see in the log that all blocks up until number <code>254</code> get indexed but each time it fails on block with <code>height 255</code>.</p>
<p>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?</p>
<p>Could this simply be a problem of the mount?</p>
<hr />
<p>EDIT: I am currently <code>-reindex</code>ing. In this case the files I already have linked to from my <code>blocks</code> folder get used like this:</p>
<pre><code>Reindexing block file blk00000.dat...
Loaded 119964 blocks from external file in 133291ms
</code></pre>
<p>Apparently, the first file contains 119,964 blocks. So when I have an error with <code>height=255</code> it should definitely be in the first file.</p>

<blockchain><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?
bomben
# 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?

(Asked by: username_0 on 2020-11-26)

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 `-reindex`ing. 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.

**Tags:** blockchain, block


---

## 1 answers

### Answer by username_1 on 2020-11-26. Score: 3 | Accepted answer

> 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?

No. Blocks are downloaded out of order, but are written to disk in the order that they are downloaded. So the block index (which states where each block is located) will be different for every node because every node will likely have the blocks stored in a slightly different order.

Furthermore, if your node has received stale blocks, those stale blocks are also stored on disk and have an entry in the block index. Not all nodes will have the same stale blocks, and they may not be stored in the same order. Newly synced nodes will not have stale blocks from before they were synced, and often times stale blocks become stale due to propagation delays, so a node may not even receive a stale block to store.

You can't just copy individual block files from one node to another. You need to copy the entire blockchain and the block index. Otherwise you will probably corrupt the whole thing and need to redownload the blockchain.


---

