灾难恢复
数据损坏、SV 重新入驻与 CometBFT 层丢失的恢复步骤。
数据损坏、SV 重新启动和 CometBFT 层丢失的恢复程序
从灾难中恢复的方法有以下三种：
- 在仅单个节点受到影响但整个网络仍然正常的简单情况下，从备份恢复通常就足够了。
- 如果完整备份不可用，但已创建身份备份，则可以在专用验证者上恢复 SV 的余额，但 SV 必须作为单独的节点加载。
从数据损坏中恢复
虽然系统中的所有组件都设计为具有崩溃容错能力，但总有可能发生系统无法立即恢复的故障，例如由于配置错误或错误。在这种情况下，我们需要从仍可运行的组件的备份或转储中恢复组件、完整的 SV 节点，甚至整个网络。
从备份中恢复单个组件
如果 SV 节点中的单个组件损坏，应该可以从备份中恢复，而无需恢复整个节点。此方案尚未经过足够的测试，不适合生产。此外，组件之间还存在某些尚未在此处记录的依赖关系。
从备份中恢复完整的 SV 节点
假设按照sv_backups中的说明对所有组件的存储和数据库进行了备份，则可以从备份中恢复整个节点。回想一下，为了使一组备份快照保持一致，从应用程序数据库实例获取的备份必须在严格早于参与者的时间进行。
假设有这样一组一致的备份可用，可以采取以下步骤来恢复节点：
将 SV 节点中的所有组件缩减至 0 个副本（如果已执行逻辑同步器升级，则将 -0 替换为正确的序列 ID）：
kubectl scale deployment --replicas=0 -n sv \
global-domain-0-cometbft \
global-domain-0-mediator \
global-domain-0-sequencer \
participant \
scan-app \
sv-app \
验证者-app从备份中恢复所有组件的存储和数据库。其具体过程取决于组件使用的存储和数据库，此处未记录。
恢复所有存储后，将 SV 节点中的所有组件扩展回 1 个副本（如果已执行逻辑同步器升级，请将 -0 替换为正确的序列 ID）：
kubectl scale deployment --replicas=1 -n sv \
global-domain-0-cometbft \
global-domain-0-mediator \
global-domain-0-sequencer \
participant \
scan-app \
sv-app \
验证者-app一旦所有组件再次恢复健康，它们应该开始追赶同级 SV 的状态，并最终再次恢复正常运行。
重新装载 SV 并使用验证者恢复 Amulets
在 SV 节点发生灾难性故障的情况下，可以通过部署控制 SV 参与者密钥的独立验证者节点来恢复 SV 拥有的护身符。 SV 节点可以使用新身份重新登录，并且护身符可以从验证者转移到新的 SV 节点。
为了能够恢复护身符，需要备份您的 SV 节点的身份。节点身份备份部分提供了获取身份的详细信息。
从节点标识的备份中，复制字段 identities.participant 的内容并将其保存为单独的 JSON 文件。该文件将用作验证者 Runbook 的身份引导转储。
jq '.identities.participant' backup.json > dump.json一旦发生故障的 SV 节点被大多数 SV 下线（通过对OffboardMember 操作进行治理投票），我们就可以部署一个独立的验证者节点来恢复 SV 的护身符。
重复helm-验证者-install中描述的步骤来安装验证者应用程序和参与者，
执行此操作时，请注意以下事项：* 修改文件splice-node/examples/sv-helm/standalone-验证者-values.yaml，将验证者PartyHint设置为您在创建SV身份时选择的名称。
- 按照从参与者身份转储恢复中的说明，使用备份中的身份恢复验证者。使用之前准备的单独的 JSON 文件。
验证者启动并运行后，使用helm-验证者-auth0中设置的验证者用户帐户登录验证者https://钱包.验证者.YOUR_HOSTNAME的钱包。确认钱包余额符合预期。它应该与原始 SV 拥有的数量相同。
您现在可以按照 helm-sv-install 中的步骤部署并加入新的 SV 节点（重复使用您的 SV 身份，但从头开始）。
登录新SV节点的钱包，复制新的party ID。切换到验证者的钱包，创建一个新的转账报价，将护身符发送到具有复制的参与方 ID 的新 SV 节点。
切换到新SV节点的钱包，接受新SV节点钱包的转账报价，并验证护身符是否已按预期到达。
本文由 CC Privacy Club 根据 Canton Network 官方文档（CC-BY-4.0）整理翻译，仅供学习；实现细节以官方最新版本为准。