Reindex

Reindex is Bitcoin Core's recovery and rebuild operation. Launching the node with -reindex wipes the block index and the chainstate (UTXO) databases, then rebuilds both by re-reading and re-validating the raw blk*.dat block files already sitting on disk. Any optional indexes that are enabled — the transaction index, the block filter index, or the coinstats index — are wiped and rebuilt as well. Crucially, nothing is re-downloaded: reindex trusts the block data you already have and reconstructs every database derived from it. It is the tool of last resort when databases are corrupted, and the tool of necessity when you enable an index that must be backfilled across the whole chain.

reindex versus reindex-chainstate

A lighter variant, -reindex-chainstate, wipes and rebuilds only the chainstate — the UTXO set — from the existing block files, leaving the block index intact. It is meaningfully faster and is the right choice when only the UTXO database is suspect, for example after a crash during a flush. Its limits are logical: it cannot repair a damaged block index, and it cannot run on a pruned node, because rebuilding the UTXO set requires replaying blocks the pruned node has already deleted. On a pruned node, serious corruption generally means re-syncing from the network — one of the quiet costs of pruning worth knowing before you enable it.

What to expect while it runs

A full reindex re-validates the entire chain from the genesis block, so it takes a similar order of time to the original initial block download minus the network transfer — many hours on good hardware, days on modest machines, with the usual slowdown as blocks get bigger and denser in recent years. Two practical notes: first, temporarily raising dbcache dramatically speeds the rebuild by keeping the growing UTXO set in memory instead of thrashing disk; give it whatever RAM you can spare and set it back afterwards. Second, progress is resumable — if the node stops mid-reindex it continues where it left off on next start, so a power blip does not restart the clock. The node stays largely unusable for wallet and RPC work until the rebuild reaches the tip.

When to reach for it — and when not to

Reindex is heavy machinery, not routine maintenance. Reach for it after disk errors or unclean shutdowns that leave the node refusing to start with database corruption messages; when enabling txindex, blockfilterindex, or coinstatsindex on a node that has already synced (Core backfills some indexes automatically, but a reindex is the reliable universal path); or after certain version transitions that change database formats. Do not reach for it to fix network problems, stuck mempools, or wallet confusion — it repairs derived databases, nothing else. And since both variants depend entirely on the block files being present and intact, a damaged blk*.dat file means the node will fetch replacement blocks from peers as needed.

The sovereignty angle

A related but distinct operation is -rescan, which re-reads the chain looking only for wallet transactions without touching the databases — much lighter, and the right tool when the node is healthy but a freshly imported key needs its history discovered. Knowing which of the three tools fits which symptom — rescan for wallet gaps, reindex-chainstate for UTXO doubt, full reindex for structural damage — saves hours of unnecessary rebuilding.

Reindex is self-custody's repair manual in action: your node can reconstruct its entire operational state from raw, locally held block data, trusting nothing and no one — no snapshot server, no checkpoint authority. Every reindex is, in effect, a full independent re-audit of the chain you hold. For the tuning that makes it bearable, see dbcache.