Substrate basepath备份恢复最佳实践及相关实操问题咨询

问题1：运行时备份basepath导致数据库损坏是否为预期现象？ #

是，该现象完全符合预期。
Substrate底层默认使用RocksDB作为存储引擎，属于LSM树架构的数据库，服务运行过程中会持续执行数据压缩（compaction）操作，动态删除旧的.sst数据文件、更新MANIFEST等元数据文件。热备份过程中，你拿到的是不同时间点的文件快照，存在严重的一致性问题：要么备份过程中旧sst文件已被删除导致备份缺失，要么元数据文件和实际数据文件不匹配，就是你遇到的列族无法打开、MANIFEST文件不存在这类报错，热备份产生的镜像天生无法正常恢复。

问题2：rsync或aws s3 sync是否为正确的备份方式？ #

你当前使用的先停止节点服务、再执行同步+排除network目录的操作是完全正确的备份方案，你所用的同步脚本本身没有问题：

para=calamari
relay=ksmcc3
bucket=${para}-${relay}-${HOSTNAME//./-}
basepath=/var/lib/substrate
sudo systemctl stop ${para}.service
/usr/bin/aws s3 sync ${basepath} s3://${bucket}${basepath} \
  --exclude "chains/${para}/network/*" \
  --exclude "polkadot/chains/${relay}/network/*"

补充说明：

• 停止服务是为了确保所有内存中的数据都落盘，且没有进程再修改basepath下的文件，保证备份数据的一致性
• 排除network目录是合理操作：该目录存储节点独有的P2P身份私钥，不需要备份，避免多节点复用同一密钥导致的网络节点封禁问题
• 如果你想缩短节点停机时间，可以采用两次同步的优化方案：
  1. 节点运行时先执行第一次同步，传输占体积90%以上的静态.sst文件
  2. 停止节点服务，执行第二次同步，仅传输第一次同步后变化的少量元数据和新增数据文件，完成后立即启动节点，可将停机时间压缩到几秒到几十秒级别
• 不管用rsync还是aws s3 sync，只要保证同步时没有进程修改basepath文件，都是可用的备份工具。

问题3：basepath中哪些文件需要备份？ #

除了.sst、.log数据文件外，RocksDB运行依赖的所有元数据文件都需要完整备份，包括你列出的CURRENT、IDENTITY、MANIFEST、OPTIONS、db_version/parachain_db_version文件，以及parachains、pvf-artifacts子目录下的全部内容，缺任意一个元数据文件都会导致数据库无法正常打开。
额外注意：

• LOCK文件是RocksDB运行时的锁文件，备份时是否携带不影响恢复，若恢复后节点因LOCK文件存在启动失败，手动删除即可
• 如果你运行的是验证人节点，chains/[链名]/keystore目录下的验证人密钥需要单独离线加密备份，不要和普通链数据一起存在公共存储中，该目录是验证人身份的唯一凭证，丢失会导致你无法控制验证人节点。

内容的提问来源于stack exchange，提问作者grenade