4.2归档文件的冗余
归档数据对于需要历史查询的应用程序至关重要。在协议方面，归档数据对于灾难恢复非常重要，因为需要它来重建某个状态。为此，只有一个归档节点设置可能是不够的。如果向归档进程发送区块的守护进程，或者归档进程本身由于某种原因失败，那么数据库中可能会丢失区块。为了使归档数据丢失的风险最小化，可以使用一些冗余技术。
单个归档节点的设置中有一个将区块发送给归档进程的守护进程，该进程将区块写入数据库。
通过在多个守护进程中指定一个归档进程的地址，便可以将多个守护进程连接到归档进程中，从而减少对单个守护进程的依赖，并为归档进程提供区块。
例如，归档进程的服务器端口是3086，那么守护进程可以使用archive-address参数连接到它。
mina daemon \
.....
-archive-address <Ip-address>:3086\
同样，也可以让多个归档进程向同一个数据库中写入数据。在这种情况下，传递给归档进程的postgres uri在多个归档进程之间是相同的。
然而，多个归档进程同时写入一个数据库可能会导致数据不一致(参见解释)。为了避免这种情况，请使用以下请求将归档数据库的交易隔离级别设置为Serializable的:
ALTER DATABASE <DATABASE NAME> SET DEFAULT_TRANSACTION_ISOLATION TO SERIALIZABLE ;
这应该在创建数据库之后进行操作，并在归档进程连接到数据库之前完成。
备份区块数据
为了进一步确保可以使归档数据恢复，您可以使用以下特性去备份区块数据并在必要时恢复它们。
我们有这样的机制去代替使用JSON记录的高保真、机器可读化的区块展示。其中包括内部的一些不透明信息。我们在内部使用这些日志来快速重新执行区块，从而获得某些链状态以进行调试。这些信息足以重建网络的确切状态。
一些内部数据是这样的:
{"data":["Signed_command",{"payload":{"common":{"fee":"100","fee_token":"1","fee_payer_pk":"B62qixbmBBmCmv1xH5SeF1hw6EqwSNVPi9B28epa3phqVMSyuZk9EoH","nonce":"340","valid_until":"4294967295","memo":"E4YM2vTHhWEg66xpj5 （省略）
尽管我们不希望主网之前有太多的变动，然而这种JSON将随着网络中区块和交易有效负载的格式变化而变化。这些数据区块可以上传到谷歌存储桶中，也可以写入mina.log文件，也可以单独备份。
将区块数据上传到谷歌云存储
为了标记出一个将区块数据上传到谷歌云存储的守护进程，请传递--upload-blocks-to-gcloud。为了成功上传文件，守护进程需要设置以下的环境变量: 1. GCLOUD_KEYFILE认证密钥文件。2.NETWORK_NAME:文件名中使用的网络名，便于区分不同网络(主网和测试网)中的区块。3. GCLOUD_BLOCK_UPLOAD_BUCKET：谷歌云存储桶上载文件。
守护进程为每个区块生成一个名为<network-name>-<protocol-state-hash>.json的文件，这些被称为预计算区块，并且将拥有一个区块的所有字段。
从日志中保存区块数据
如果-log-precomputed-blocks参数被传递，那么守护进程也会记录区块数据。要查找的日志是Saw block with state hash $state_hash，该区块包含元数据中的precomputed_block并具有区块信息。这是上传到谷歌云存储的相同信息(预计算区块)。
从另一个归档数据库生成区块数据
从完全同步的归档数据库中，您可以使用mina-extract-blocks工具为每个区块生成区块数据。
该工具接受一个--archive-uri、一个--end-state-hash和一个可选的--start-state-hash，并且写入从start-state-hash开始到end-state-hash结束的链中的所有区块(包括开始和结束)。
如果只提供了结束哈希，那么该工具将生成以最接近结束区块的无父区块开始的区块。如果在两者之间没有遗漏的区块，那这就是创世区块。该工具将为每个区块生成一个名为<protocol-state-hash>.json的文件。这些文件中的区块数据称为扩展区块。因为这些是从数据库生成的,它们只会在归档数据库中存储，并且不包含预先计算出的其它区块信息(例如,snark区块链),因此只能用于在归档数据库去恢复区块。
或者，不指定状态散列，您可以提供--all-blocks标志，该工具将写出数据库中包含的所有区块，而不是去指定具体的哈希状态。
识别丢失区块
mina-missing-block-auditor工具可用于确定在归档数据库中丢失的区块。该工具输出在数据库中缺少父类所有区块的哈希状态列表。这可以用来监视归档数据库中任何丢失的区块。postgres数据库的URI可以使用--archive-uri参数。
恢复区块
如果使用mina-archive-blocks工具可以从上面列出的选项中获得区块数据(预先计算的或扩展的)，则可以恢复归档数据库中缺失的区块。
1.恢复预先计算的区块(参看上面的选项1和2)
mina-archive-blocks --precomputed --archive-uri <postgres uri> FILES
1.对于扩展区块:(从选项3生成)
mina-archive-blocks --extensional --archive-uri <postgres uri> FILES
质押帐本
质押账本用于确定一个epoch中每个slot赢家。Mina守护进程为当前和下一个epoch(在它最终完成后)存储质押账本。当过渡到一个新epoch时，使用来自前一个epoch的“下一个”质押分类帐来确定新epoch的slot赢家，并选择一个新的“下一个”质押分类帐。虽然旧时epoch的加密账本不可再访问，但用户可能仍然希望保留它们以供报告或其他用途。
目前，这些账本可以使用cli命令-导出
coda ledger export [current-staged-ledger|staking-epoch-ledger|next-epoch-ledger]
Epoch账本每14天发生一次(给定slot= 3分钟，每个Epoch的slot= 7140)转换。考虑到“下一个”质押账本在当前纪元的k(目前290)区块之后完成，并且备份质押账本的窗口是~27天，因此该窗口可用于当前epoch的其余部分和下个完整epoch。
