Bitcoin Core reindex Explained: Rebuilding Node Databases

This guide explains Bitcoin Core reindex in plain English. It focuses on what the subject is, why it matters and what a beginner should remember.

What reindex reconstructs

The node scans blk files, validates their framing and blocks, rebuilds index records and reconstructs active chainstate. It does not recover missing wallet keys and cannot manufacture pruned historical blocks. The process still applies consensus validation, so a completed database is evidence of replay, not trust in an imported index.

Diagnose before rebuilding

A corrupt block index, changed txindex setting, incompatible downgrade or explicit operator test may justify reindex. Network failure, wrong datadir, permissions, disk exhaustion or a damaged wallet require different responses. Preserve logs and exact errors before replacing diagnostic state with hours of rebuild activity.

reindex versus redownload

If complete blk files remain, reindex can reuse them. If pruning removed history or files are missing, the node may need to get blocks again. Download, validation and index construction have different bandwidth and storage profiles. Estimate peak space from the actual retained set rather than final steady-state size.

Pruning and file removal

Core 0.12 included special handling for reindex with pruning and could remove unusable block and undo files. That is materially destructive to local reproducible data. Snapshot or manifest the datadir first, verify the target path and never use an unresolved environment variable or broad filesystem command.

txindex and downgrade changes

Changing txindex required a rebuild. Core 0.12 release notes also warned that a chainstate produced by a 0.12 reindex was not backward compatible with 0.11 without another reindex. Record the binary and format boundary so rollback planning does not assume old software can open newly rebuilt state.

Operational capacity

Replay stresses storage, CPU, memory and shutdown time. Wallet and pool services may appear alive while chain progress is incomplete. Gate dependent services on verified sync and chain identity, not process presence. Leave room for block, undo, index, chainstate, logs and temporary writes.

Interruption and completion

Interrupt a rehearsal once, restart and observe whether work resumes safely. At completion verify best block, chainwork, index mode, pruning state, wallet availability and application RPCs. Compare primary and failover independently; copying rebuilt state while it is live can create a second inconsistent node.

Conclusion

reindex is a deliberate database replay with storage, compatibility and service consequences. Use it only after diagnosis, with wallet protection, exact capacity evidence and a rehearsed recovery path.