一台全节点的仓库地图
运行几年的比特币核心会在数据目录里攒下几十至上百 GB 内容，多数人被“占空间”劝退前根本没看过目录结构。仓库分四区。第一区是历史原账：blocks 目录按高度分段存放原始区块文件，只追加不修改，是重放一切历史的能力所在；第二区是现账：chainstate 数据库记录链上最新的 UTXO 集合与区块索引，节点验证新区块靠它而不是翻旧账，集合规模与膨胀来源见 UTXO 集合为什么越来越大：膨胀来源、粉尘与普通人的责任。第三区是社交记录：peers.dat 存已知对等节点地址、banlist.dat 记封禁名单，连接健康影响首因见 getnetworkinfo如何看节点连接？。第四区是钱包目录：每个钱包一个文件（描述符钱包时代之前是钱包文件本体的时代遗产），密钥全部加密在文件内部，自托管边界见 托管钱包 vs 自托管：私钥到底在哪里，风险怎么判断。
哪些能瘦身、怎么瘦
区块原账是体积大头，也是唯一允许官方瘦身的区域：剪枝模式在同步完成后按段丢弃最老的区块文件，把磁盘占用压到配置的最低量级附近，代价是无法给对端供给远古区块、历史查询依赖别人，剪枝决策要点见 比特币节点剪枝模式是什么？与 pruneblockchain裁剪前要查什么？。chainstate 是必选项，瘦不掉；txindex 若开启则额外复制一份交易索引，体积与区块原账同量级，不需要全历史按交易哈希查询就关掉它。运行参数层面的省内存选项（缓存上限、数据库层参数）与省磁盘是两套思路，别混用同一篇文章里的数字。
损坏长什么样，先别慌
节点数据损坏的典型表现分三档。轻档：单文件读报错但链正常，日志点名某个区块文件校验失败——多数场景重启触发重下即可；中档：启动时报状态数据库不一致、要求“需要回滚或重建索引”——chainstate 与区块历史出现错位，软件版本异常升降级或异常断电后偶发；重档：反复卡在同一个高度循环报错，可能是介质本身坏道。第一步永远是备份整个目录再动手；第二步用 verifychain 做一致性体检，它抽样校验链结构与数据库，读法见 verifychain怎么检查链数据库？。
修复阶梯：从最便宜到最贵
三档方案按破坏性递增。第一档重扫：钱包余额对不上但链正常，多半是索引窗口没覆盖，rescanblockchain 限定高度重扫即可，见 rescanblockchain怎样限定高度？。第二档重建索引：加 reindex 参数从头重放全部区块文件，历史区块不丢、chainstate 与 txindex 重算，耗时以小时到天计，是“数据库说胡话”时的标准解法。第三档重同步：区块文件也保不住或校验大面积失败，只能清空重下，快照同步可以把前几个月的区块头验证换成状态快照起点，但快照本身信任发行方，能力边界见 assumeUTXO同步安全吗？ 与 getchainstates如何看快照进度？。
目录管理的三条纪律
第一，版本升降级前后目录兼容性要读发行说明，见 Bitcoin Core版本说明怎么读？——对等表格式这类不兼容变更会让旧版本把已知节点当空白。第二，磁盘健康比容量更重要：SMART 告警出现当天就把数据目录冷备份列为最高优先级，节点历史可以重下，你的钱包文件丢了才是不可再生事件，备份流程见 Bitcoin Core备份怎么做？。第三，多实例分目录运行（主网加测试网）时用 datadir 参数硬隔离，见 比特币测试网络怎么选：signet、testnet4 与 regtest。
小结与风险提示
数据目录是节点的分层信任结构：原账可重下、现账可重算、社交可重建、钱包不可再生。把这四层背下来，任何“节点炸了”的恐慌都会变成一条清晰的处置流水线。介质故障与误删存在真实数据风险，任何重同步都要花时间与带宽预算，本文不构成投资建议。
一次典型故障的完整处置演练
场景：断电后节点反复报错退出。标准流程七步。一，整机检查电源与散热，排除硬件诱因。二，整机备份数据目录——哪怕盘已经报警，先镜像再折腾。三，查日志尾部的具体报错文件名与错误码，区分是区块文件、状态数据库还是钱包目录喊疼。四，轻处理：删去可疑区块文件让节点重下该段，或用 verifychain 分级参数做深检，见 verifychain怎么检查链数据库？。五，中处理：reindex 重建，预留充足磁盘与时间预算，重建期间节点完全离线属正常现象。六，重档：区块目录重下，快照同步可提速但注意快照信任边界，见 assumeUTXO同步安全吗？。七，复盘：把故障当天的系统日志、磁盘 SMART 数据与版本变更记录归档，下次升级前它就是你的风险清单。整个过程唯一不可逆的资产是钱包文件，只要它在，链上的账就永远是可重算的。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。