我仍然是个笨蛋，所以，如果我误解了一些基本知识，请原谅我。
我有一个在GKE中运行的HLF 1.4.2集群，其中有3个订购者(raft(和3个组织(每个组织2个对等体(。几天前，订购者的pvc磁盘已满，所有订单都开始失败。由于我无法实时扩展卷，我缩减了订购者的规模，从PVC中收回了数据，并在扩展的卷上恢复。
在恢复卷时，我在恢复卷数据后立即启动每个订购者。因此，当第二个订购者启动时，订购者获得了quorum，同行开始编写。因此，当第三个订购者被提出时，它拒绝加入集群，并出现以下错误
2020-08-25 13:17:33.891 UTC [orderer.consensus.etcdraft] Step -> INFO a2d 2 [term: 2] received a MsgHeartbeat message with higher term from 1 [term: 4] channel=mychannel node=2
2020-08-25 13:17:33.892 UTC [orderer.consensus.etcdraft] becomeFollower -> INFO a2e 2 became follower at term 4 channel=mychannel node=2
2020-08-25 13:17:33.892 UTC [orderer.consensus.etcdraft] commitTo -> PANI a2f tocommit(19) is out of range [lastIndex(17)]. Was the raft log corrupted, truncated, or lost? channel=mychannel node=2
panic: tocommit(19) is out of range [lastIndex(17)]. Was the raft log corrupted, truncated, or lost?
由于我不确定如何恢复，我决定用以前的备份恢复所有3个订购者。恢复后，所有订购方都已成功恢复到定额，但多个对等方开始给出以下错误
2020-08-26 11:03:46.482 UTC [gossip.state] deliverPayloads -> PANI 03f Cannot commit block to the ledger due to unexpected Previous block hash. Expected PreviousHash = [3e39ea03143fdb09a14fb92b6b429236f57dbe52acbeac9c797f6ebdeef1aa79], PreviousHash referred in the latest block= [1823042217af3f7836e7b6d9b933dc9c008fc71f85e5465c62b78217194a6b3a]
- 有可能从这种状态中恢复吗
- 官方的备份和恢复文档没有讨论订购方和对等分类账数据之间的依赖关系。所以，若我正在进行备份，获得一致数据备份的唯一方法就是在进行备份之前停止订购方和对等方，对吗
- 我比较了来自3个订购者的备份，并且所有3个备份的文件看起来都相同，所以，我可以从一个订购者备份中恢复所有3个订购人吗
-
当您恢复订购者时，似乎没有恢复对等方。因此，现在peer比orderer拥有更多的块。您应该始终确保对等方的块高度与订购方相同或更低。如果是一样的，那就太好了，没什么可做的。如果它更低，那么它将从订购者中提取较新的块。
-
是的，建议在进行备份之前停止订购方和对等方
-
我不确定。可能需要其他HF专家参与进来。