同步中断后节点不会从零开始重新下载，只要本地数据目录还在，重启客户端就会从已落盘的最高区块继续向邻居节点请求剩余区块。
节点同步中断后为什么可以续传，而不是重新下载
节点同步不是一次性下载完才写入磁盘，以比特币全节点为例，它每收到一批区块，会先把原始区块数据写入 blocks/blk.dat 文件，再更新链状态到 chainstate 目录，以太坊执行客户端（如 Geth）在同步过程中也会持续把区块头和交易数据写入 chaindata 和 ancient 数据目录，同步过程的“进度条”本质上是本地数据库里已持久化的最新高度。
- 只要这些目录没被手动删除或损坏,节点重启后就能读取到上次写到哪一块。
- 节点会向已连接的邻居广播自己的当前高度,并从落后高度继续拉取区块。
- 行业共识认为，节点同步是一个有状态的下载任务，状态存在本地数据库,而不是存在内存里。
所以断网、进程被杀、服务器重启这类中断,多数情况下不会丢失已经同步好的区块。
区块链节点同步中断怎么恢复：不同客户端的具体路径
不同客户端的续传方式大同小异,但启动参数和数据目录位置有差异。
Bitcoin Core 节点中断后怎么续传
Bitcoin Core 的数据目录默认在 ~/.bitcoin，如果同步中断,直接重新运行：
bitcoind -daemon
或者重新打开 Bitcoin Core 图形界面，客户端会自动读取 blocks 目录里的区块文件,从最后高度续传。
- 如果启动日志报
Error opening block database或Corrupted block database detected，说明本地数据库损坏,不能直接续传。 - 此时需要执行
bitcoind -reindex-chainstate重建链状态,区块文件本身仍然可以复用。 - 不要直接用
-reindex来恢复中断，因为-reindex会重新扫描全部区块文件,比续传慢得多。
以太坊 Geth 节点中断后怎么恢复
Geth 的数据目录默认在 ~/.ethereum,中断后同样直接重启：
geth --datadir /data/eth --syncmode snap --http
- 快照同步中断后，Geth 会从已下载的快照块继续下载状态数据。
- 如果在日志中看到
Syncing beacon headers或Syncing: state heal in progress,说明续传已经启动。 - 不要在中断后随意切换
--syncmode，例如从snap改成full可能触发重新同步,浪费已经下载好的快照数据。
联盟链节点
FISCO BCOS、长安链等联盟链节点通常把数据放在节点目录下的 data 文件夹，中断恢复同样以重启进程为主，部分联盟链还支持从内网其他节点做快速同步,比公网拉取快很多。
节点同步断点续传和重新同步对比：哪种方式更省时间
这个问题的答案取决于本地数据目录是否完整。
| 场景 | 断点续传 | 重新同步 |
| 数据目录完整 | 从当前高度继续，时间较短 | 从创世块或信任点开始，耗时长 |
| 数据目录部分损坏 | 多数客户端可跳过坏块或修复后继续 | 删目录重来，需要重新下载所有区块 |
| 切换同步模式 | 一般不触发续传，而是重新同步 | 是 |
| 内网服务器出口带宽有限 | 节省流量 | 重复消耗大量出口带宽 |
| 磁盘空间不足导致中断 | 清理出空间后重启即可续传 | 若删除数据目录，前功尽弃 |
所以在绝大多数场景下，断点续传都更省时间，重新同步只适合数据目录已经无法修复,或者需要切换同步模式的情况。
以太坊节点同步中断后续传剩余区块的操作步骤
以太坊节点同步中断后续传剩余区块时,建议按下面步骤操作。
先查看当前同步状态，进入 Geth 控制台：
geth attach /data/eth/geth.ipc
然后执行：
eth.syncing
如果返回一个对象，里面有 currentBlock 和 highestBlock，说明节点还在同步，如果返回
false，说明同步没有进行，需要用 eth.blockNumber 查看本地最新高度。
查看日志确认中断原因，常见原因是磁盘满、网络断开、内存不足。
tail -f /var/log/geth.log
-
如果是正常中断，直接重启 geth 进程,不需要加任何特殊参数。
-
重启后再次查看
eth.syncing。currentBlock没有增长，执行net.peerCount检查连接节点数量。 -
net.peerCount返回 0，说明没有连接到任何邻居节点,需要手动添加可信节点：
admin.addPeer("enode://...")
也可以把可信节点写入启动参数 --bootnodes。
- 观察日志里是否出现
Imported new chain segment字样，如果持续出现且区块高度在增加,说明续传正常。
内网服务器节点同步区块慢怎么解决
内网服务器同步慢往往不是机器性能差,而是节点发现机制被网络环境限制住了。
- 内网防火墙如果只允许出站到特定端口，节点可能连不上公网的 UDP 发现端口,导致邻居节点数量少。
- 可以在 Bitcoin Core 配置文件中直接指定内网已同步节点的 IP：
connect=192.168.1.10
- Geth 可以使用
--bootnodes指向内网已同步节点，或者把--nat=extip:公网IP配好,方便其他节点找到。 - 多台内网节点需要同步时，先让一台机器通过代理或专线同步完成，再把数据目录 rsync 给其他机器，最后各节点重启续传剩余几个区块,这比每台机器都从公网拉一遍要快得多。
- 不需要急着升级更贵的专线带宽套餐，多数情况下,配好固定节点比提升带宽更有效。
同步续传中容易踩的坑
同步续传不是万能的,有几个坑需要避开。
- 数据库损坏：如果日志出现
leveldb: corrupted
、
bad block或missing data，直接重启无法续传，需要先执行geth removedb或 Bitcoin Core 的-reindex-chainstate。 - 主网和测试网目录混用：主网数据目录和测试网数据目录不同，如果启动时指定了错误网络参数，节点会去找另一个目录,自然无法续传。
- 快照同步长期中断后过期：快照同步中断后如果搁置较久，部分状态数据可能过期，客户端会从新的信任点开始,相当于部分重新同步。
- 数据目录放在网络挂载盘：NFS 或对象存储不适合做节点数据目录，随机写性能差，续传时会频繁卡住，建议使用本地 SSD。
同步中断后是否要重新下载，先看数据目录在不在，只要目录还在，先重启客户端，再看高度是否增长，最后查邻居节点数量,这个排查顺序能解决多数续传问题。
常见问题
同步过程中断后节点如何续传剩余区块？直接重启客户端就可以吗？
多数情况下可以，只要数据目录完整，重启 Bitcoin Core、Geth 或其他客户端后，节点会读取本地已落盘的高度，并从该高度继续向邻居节点请求剩余区块,启动参数不需要额外添加续传选项。
节点同步中断后数据损坏还能续传剩余区块吗？
如果只是进程中断、断网、重启，数据目录通常不会损坏，可以续传，如果日志明确提示数据库损坏或区块文件损坏，则不能直接续传，比特币节点可以使用 -reindex-chainstate 只重建链状态，Geth 可以删除状态目录后重新同步,但区块文件本身多数能复用。
比特币全节点同步中断后如何续传剩余区块？
直接重新启动 bitcoind 或 Bitcoin Core 图形界面即可，客户端会自动从 blocks 目录里已保存的高度开始继续下载，如果日志提示数据库损坏，执行 bitcoind -reindex-chainstate 后仍然能复用已有区块文件，比特币全节点同步需要的时间取决于硬件和网络,中断后续传比从零开始更快。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/646510.html
