恢复模式

可以使用 -recovery 参数启动 Vault 以进入恢复模式。恢复模式的主要目的是允许直接访问存储，以防 Vault 由于一些新发现的错误而无法启动。一般在没有 Vault 专家在场提供建议的情况下这不太会有什么用。

恢复模式与常规 Vault 操作有如下差异：

恢复流程

一般来说恢复模式按以下流程运行：

封印或停止集群中所有节点
如果使用了集成存储，在每个节点上运行 vault status 来查找序号最高的那一个节点（这需要这些节点处于运行且封印状态。如果处于解封状态那么一个新的领导者节点可能会被选出并进行写操作，这会混淆问题）
以恢复模式重启目标节点
在那个节点上生成一个恢复令牌
使用恢复令牌通过向 sys/raw 发送操作来修复节点
如果使用了集成存储，按照下面的步骤重新组建 Raft 集群

如果以混合模式（即 ha_storage）使用集成存储，那么恢复模式将不允许更改 Raft 数据，只能修改与 Vault 存储后端关联的底层物理数据。这意味着本文档中有关集成存储的说明不适用。

使用集成存储时，并非所有节点都是一致的。一些节点的状态可能更落后 - 它尚有还未同步到的 Raft 日志。在选择用于恢复的节点时，必须要确定它具有在集群中找到的最高 AppliedIndex。

每个节点的 AppliedIndex 值可以通过在关闭集群后对集群内已封印节点运行 vault status 来获取。

恢复令牌的签发方式与生成根令牌的方式大致相同，只是使用不同的端点，并且必须首先封印 Vault 节点。与根令牌不同，恢复令牌不会持久化，因此如果 Vault 重新启动进入恢复模式，则必须生成一个新的恢复令牌。

只能生成一个恢复令牌。如果丢失，请重新启动 Vault 并生成一个新的。

发往 sys/raw 端点的请求与常规模式下发到 Vault 服务的请求一样，唯一的区别是在恢复模式下，X-Vault-Token 包含的必须是恢复令牌而不是服务令牌或者批量令牌。

恢复模式下 Vault 会自动将集群大小调整为 1。这是必须的，因为 Raft 协议不允许在没有仲裁的情况下进行更改，并且在恢复模式下我们希望使用单个节点进行更改。

这意味着在使用了恢复模式后，要返回正常服务必须包括先重组 Raft 集群。有两种方法可以做到这一点：删除其他节点上的 Vault 数据目录并将它们重新加入恢复完的节点，或者使用 peers.json 文件手动恢复的方法让所有节点就哪些节点是集群的组成部分达成一致。