<p>From: <a href="https://bitcoin.stackexchange.com/questions/60709/when-should-i-use-reindex-chainstate-and-when-reindex">When should I use -reindex-chainstate and when -reindex</a></p>
<blockquote>
<p><strong>-reindex</strong>:</p>
<p>wipes the chainstate (the UTXO set) wipes the block index (the
database with information about which block is where on disk) rebuilds
the block index (by going over all blk*.dat files, and finding things
in it that look like blocks) rebuilds the chainstate (redoing all
validation for blocks) based on the blocks now in the index</p>
<p><strong>-reindex-chainstate:</strong></p>
<p>wipes the chainstate rebuilds the chainstate using the blocks in the
index you had before The latter should be strictly faster, as it does
not need to rebuild the block index first. Perhaps the progress bar
during reindex confuses you: that progress is only for the rebuilding
of the index. The recreation of the chainstate happens after that
rebuild is completed.</p>
<p>You should use <strong>-reindex</strong> only when you were running in pruning mode, or
if you suspect the blocks on disk are actually corrupted. Otherwise,
when you only suspect corruption of the chainstate (which is far more
likely), use <strong>-reindex-chainstate</strong>.</p>
</blockquote>
<p>With <code>-reindex</code> I was able to restore my corrupted data</p>

CC BY-SA 4.0
2024-05-27T02:06:59.107Z
Did it recovered without redownloading all, when in prunned mode?
cavila
CC BY-SA 4.0
2023-05-03T12:08:05.110Z
2023-05-03T14:10:07.263Z
2023-05-03T14:10:07.263Z
nico
<p>I recently experienced a I/O error resulting in data block corruption or index corruption cause bitcoin-qt wasn't quitting so I forced bitcoin core to shutdown without killin it properly. I checked the harddisk..
when I restarted Bitcoin-qt it asked me a question:</p>

<blockquote>
  <p>Error opening block database. Do you want to rebuild the block
  database now?</p>
</blockquote>

<p>Answered <strong>yes</strong> but when Bitcoin core came up I realized that I was 4 years back to synchronize with the blockchain. So I immediately stopped it again to look for more information before proceeding for safety</p>

<p>I found the relevant command in bitcoin-core options to rebuild chain state: </p>

<pre><code>bitcoin-qt -reindex
bitcoin-qt -reindex-chainstate
</code></pre>

<p>Edit : This useful answer from user Pieter Wuille here:<br> <a href="https://bitcoin.stackexchange.com/a/60711/11928">When should I use -reindex-chainstate and when -reindex</a> answers my second question.
 <br></p>

<blockquote>
  <p>-reindex:</p>
</blockquote>

<pre><code>wipes the chainstate (the UTXO set)
wipes the block index (the database with information about which block is where on disk)
rebuilds the block index (by going over all blk*.dat files, and finding things in it that look like blocks)
rebuilds the chainstate (redoing all validation for blocks) based on the blocks now in the index
</code></pre>

<blockquote>
  <p>-reindex-chainstate:</p>
</blockquote>

<pre><code>wipes the chainstate
rebuilds the chainstate using the blocks in the index you had before
</code></pre>

<p><br>
Found this bitcoin.se answer <a href="https://bitcoin.stackexchange.com/questions/63067/bitcoind-reindex-vs-starting-allover-again">Bitcoind --reindex vs starting allover again</a> but made me a bit uncertain on what to do next in order to retrieve my database <strong>without</strong> downloading the whole blockchain from the start<br>
<br>
<em>What would be the proper and fastest possible ways to rebuild/recheck my blockchain from Bitcoin-qt?</em> 
<br></p>

<p><em>What is the difference of use between of <code>bitcoin-qt -reindex</code> vs <code>bitcoin-qt -reindex-chainstate</code>?</em></p>

<bitcoin-core><block><synchronization><reindex>
How to recover corrupted Bitcoin-Core blockchain?
Denja
# How to recover corrupted Bitcoin-Core blockchain?

(Asked by: username_0 on 2017-12-18)

I recently experienced a I/O error resulting in data block corruption or index corruption cause bitcoin-qt wasn't quitting so I forced bitcoin core to shutdown without killin it properly. I checked the harddisk..
when I restarted Bitcoin-qt it asked me a question:

Error opening block database. Do you want to rebuild the block
  database now?

Answered yes but when Bitcoin core came up I realized that I was 4 years back to synchronize with the blockchain. So I immediately stopped it again to look for more information before proceeding for safety
I found the relevant command in bitcoin-core options to rebuild chain state: 
bitcoin-qt -reindex
bitcoin-qt -reindex-chainstate

Edit : This useful answer from user Pieter Wuille here: When should I use -reindex-chainstate and when -reindex answers my second question.
 

-reindex:

wipes the chainstate (the UTXO set)
wipes the block index (the database with information about which block is where on disk)
rebuilds the block index (by going over all blk*.dat files, and finding things in it that look like blocks)
rebuilds the chainstate (redoing all validation for blocks) based on the blocks now in the index


-reindex-chainstate:

wipes the chainstate
rebuilds the chainstate using the blocks in the index you had before


Found this bitcoin.se answer Bitcoind --reindex vs starting allover again but made me a bit uncertain on what to do next in order to retrieve my database without downloading the whole blockchain from the start

What would be the proper and fastest possible ways to rebuild/recheck my blockchain from Bitcoin-qt?

What is the difference of use between of bitcoin-qt -reindex vs bitcoin-qt -reindex-chainstate?

**Tags:** bitcoin-core, block, synchronization, reindex


---

## 1 answers

### Answer by username_1 on 2023-05-03. Score: 4

From: [When should I use -reindex-chainstate and when -reindex](https://bitcoin.stackexchange.com/questions/60709/when-should-i-use-reindex-chainstate-and-when-reindex)

> **-reindex**:
>
> wipes the chainstate (the UTXO set) wipes the block index (the
> database with information about which block is where on disk) rebuilds
> the block index (by going over all blk\*.dat files, and finding things
> in it that look like blocks) rebuilds the chainstate (redoing all
> validation for blocks) based on the blocks now in the index
>
> **-reindex-chainstate:**
>
> wipes the chainstate rebuilds the chainstate using the blocks in the
> index you had before The latter should be strictly faster, as it does
> not need to rebuild the block index first. Perhaps the progress bar
> during reindex confuses you: that progress is only for the rebuilding
> of the index. The recreation of the chainstate happens after that
> rebuild is completed.
>
> You should use **-reindex** only when you were running in pruning mode, or
> if you suspect the blocks on disk are actually corrupted. Otherwise,
> when you only suspect corruption of the chainstate (which is far more
> likely), use **-reindex-chainstate**.

With `-reindex` I was able to restore my corrupted data

> **Comments:**
> **username_2**: Did it recovered without redownloading all, when in prunned mode?  

---

