> For the complete documentation index, see [llms.txt](https://docs.verge.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.verge.io/knowledge-base/zh/system-administration/cluster-recovery-after-power-outage.md).

# 完全断电后的集群恢复

## 概述

{% hint style="info" %}
**要点**

* 应尽可能避免非正常关机，尤其是在生产系统上。
* 本指南提供最佳实践——用于在发生意外关机后重新启动集群时降低潜在问题。
* 开启 **Node1** 先等待 30 秒到 1 分钟，然后再给其余集群节点上电。
* 非零的 **修复** 恢复后的计数是正常的；随着 Journal Walk 完成，它应会减少。
* 如果在 Journal Walk 完成后“修复”计数没有归零，或者其他异常持续存在，请联系 VergeIO 支持。
  {% endhint %}

## 范围

本指南涵盖在发生 **非正常关机** 后将 VergeOS 集群重新上电——例如，集群因停电、UPS 电量耗尽、机房故障或类似事件而突然失电。有关计划内、受控的关机和上电流程，请参见 [VergeOS 系统正确关机流程](/knowledge-base/zh/system-administration/proper-vergeos-system-shutdown-procedure.md) 以及 [正确的上电顺序](/knowledge-base/zh/system-administration/proper-power-sequence-for-vergeos.md).

{% hint style="warning" %}
**尽可能避免非正常关机**

* 尽管 VergeOS 内置了多种保护措施来维护数据完整性，但任何分布式存储系统都无法在节点突然且同时失电时，完全保证不会发生数据损坏。
* 在失电瞬间正在进行的写入可能在各个对等节点之间不完整或不一致，在某些情况下，恢复完整性的唯一途径是将卷回滚到最近的快照。
* 此外，非正常关机后，硬件、来宾操作系统和应用程序问题也很常见。
* 合适的供电基础设施——用于平滑关机的 UPS 覆盖范围、冗余 PSU，以及在低电量时自动关机——是最有效的保护；请参见 [预防](#preventionmitigation) 部分获取指导。
* 即使采取了这些预防措施，如果仍然发生非正常关机，后续流程旨在安全地让集群重新上线，并暴露需要处理的任何完整性问题。
  {% endhint %}

## 前提条件

* 对每个节点的物理访问或 IPMI/BMC 访问
* 知道哪个节点是 **Node1** （Node1 需要先启动。）
* 确认上游供电、网络（核心 Fabric 交换机）和 IPMI 已恢复并稳定
* 如发现完整性问题，可使用最近的本地或远程复制快照
* 熟悉 [vSAN Tier 仪表板 / Journal Walks](/knowledge-base/zh/storage-vsan/understanding-journal-walks-and-vsan-tier-status.md)

## 步骤

### 预期情况

* VergeFS 包含多种内置保护机制，以帮助在电源事件期间维护数据完整性——包括写入日志、对等复制、修复服务器（ioGuardian）以及启动时验证。控制器启动后，VergeFS 会触发 **完整 Journal Walk** ，以验证每个块并与对等节点进行协调。这些保护在大多数情况下都很有效，但任何分布式存储系统都无法完全保证不会因突然失电而损坏数据；启动后的验证非常重要，尤其是在非正常关机之后。
* vSAN 需要 **最少节点数** 在线后才会挂载（例如，在具有 N+1 保护的 4 节点集群中，只要有 3 个节点在线，vSAN 就会挂载）在达到该阈值之前，存储会保持离线，虚拟机也不会启动。
* Node1 会启动，但会在挂载 vSAN 之前暂停，直到足够的对等节点加入。
* 非零的 **修复** 恢复后的计数是正常的，并且应随着 Walk 的进行而减少。

### 上电前检查

{% hint style="warning" %}
**先确认基础设施已就绪**

在给任何集群节点上电之前，请确认满足两个关键条件。这些内容在前置条件中已有说明，但这里仍需重申——跳过它们可能造成比最初关机更严重的损害：

1. **机房供电已完全恢复且稳定。** 在电力仍不稳定——闪断、电压暂降或第二次停电——时启动集群，会增加原有问题并可能导致进一步的数据完整性问题。

2. **核心网络交换机已上电并完全启动。** 企业级交换机可能需要几分钟才能完成启动过程，就像服务器一样。如果集群节点在网络就绪之前上线，它们将无法发现彼此，这会导致协调问题。
   {% endhint %}

3. 确认 **上游供电** 稳定。在不稳定的电源上启动节点，可能会在恢复过程中再次停电。

4. 确认 **核心网络交换机** 已在线， **已完全启动**，且节点间 fabric 已经联通。没有它，vSAN 无法重新组建，而高级交换机可能需要几分钟才能完成启动。

5. 确认 **IPMI/BMC** 已在每个节点上可访问，以便在需要时远程监控启动过程。

6. 记录任何存在可见硬件故障的节点（故障 PSU、驱动器 LED、风扇告警）——这些节点在重新加入之前可能需要处理。

### 上电顺序

在确认供电和网络基础设施已准备就绪后：

1. **给 Node1 上电。**
   * 观察控制台/IPMI。Node1 会启动操作系统，但 **会在挂载 vSAN 之前暂停** ，直到足够的对等节点加入。
2. **等待 30 秒到 1 分钟。**
   * 这个短暂停顿让 Node1 在集群其余部分到位之前先开始初始化。无需等到 Node1 完全进入暂停状态再继续。
3. **给其余节点上电。**
   * 其余节点可以一起上电（或紧接着依次上电）；无需逐个错开启动。
   * 一旦达到最少在线节点数，vSAN 会自动挂载（例如，在默认 N+1 配置中，只需除一个节点外其余全部上线）。
4. **多集群环境：** 在开启其他集群之前，先让控制器集群完全上线。

{% hint style="success" %}
**专业提示**

Node1 会先启动并等待，而你给集群其余节点上电——这是预期行为，不是卡住了。只要足够的对等节点上线，vSAN 就会自行挂载，VergeOS 会自动处理协调；无需手动执行修复命令。
{% endhint %}

### 恢复后验证

一旦所有节点都在线且集群已稳定，请验证一切已恢复到健康状态。由于集群经历过非正常关机，请以更高的严谨程度执行这些检查——突然失电可能遗留集群无法自行完全解决的问题。重点查看持续存在的 vSAN 错误、失败或崩溃循环的工作负载，以及任何来宾级文件系统错误。如果检测到无法修复的数据损坏，可能需要将卷回滚到最近的快照。

1. **确认整体系统健康状况**

   突然失电会增加硬件问题的风险。务必检查是否存在以下问题：

   * 查看 [告警](/run-the-platform/operations/alarms.md) 仪表板。确认没有触发新的告警。
   * 查看 **系统日志（主仪表板）** 中是否有启动或初始挂载期间的错误。
2. **验证 vSAN 健康状况**
   * 打开 **主仪表板** ——所有状态指示灯都应为 **绿色**.
   * 导航到 **系统 → vSAN → 层** ，然后双击每个层。
   * 查看 **状态** 磁贴。KB 文章 [了解 vSAN 层状态/日志遍历](/run-the-platform/storage/vsan-diagnostics.md) 提供了读取 vSAN 层状态字段的指南。
3. **验证驱动器健康状况**
   * 前往 **系统 → vSAN → 驱动器**.
   * 查找任何显示错误、警告或 SMART 告警的驱动器——当驱动器在突然失电后没有正常恢复时，可能会出现这些情况。
   * **及时更换故障驱动器** ，以维护 vSAN 数据保护。
4. **验证工作负载**

   <div data-gb-custom-block data-tag="hint" data-style="success" class="hint hint-success"><p><strong>虚拟机自动启动行为</strong></p><p>默认情况下，虚拟机配置为在集群恢复供电时自动启动。采用其他 <strong>断电后</strong> 设置的虚拟机需要手动上电。</p></div>

   * 验证关键虚拟机：控制台是否响应、来宾操作系统是否健康、应用服务是否已启动。非正常关机可能会给来宾操作系统和已安装应用程序带来问题——注意文件系统错误、无法启动的服务以及启动即崩溃的应用。
   * 尽早识别潜在的回滚候选对象——理想情况下应在应用恢复重度使用之前完成。

{% hint style="warning" %}
**快照回滚决策具有时间敏感性**

如果整个系统或单个虚拟机显示出因非正常关机造成且无法就地修复的损坏迹象，那么从停电前的快照恢复可能是返回健康状态的唯一途径。 **应尽快作出这一判断**，原因有二：

* **快照保留是有限的。** 如果在做出决定前经过太长时间，一个可用的停电前快照可能会过期并变为不可用。
* **回滚会丢失较新的数据。** 受影响的虚拟机在停电后继续生产使用的时间越长，执行回滚时被丢弃的恢复后有效工作就越多。
  {% endhint %}

## 故障排除

{% hint style="warning" %}
**常见问题**

* **问题：** 某个节点未能重新加入集群。
  * **解决方案：** 检查 IPMI/控制台输出是否有启动错误。确认该节点的核心网络接口已启动，并且可被对等节点访问。查看 **系统 → 节点 → \[节点]** 中的状态和最后出现时间戳。如果节点已启动但未加入，请 **未** 不要强制移除它——请联系支持。
* **问题：** vSAN 无法挂载 / 存储离线。
  * **解决方案：** 确认 **最少 vSAN 节点已在线** 在 **系统 → 节点** 下（例如，在默认配置中：4 节点集群中为 3/4，6 节点集群中为 5/6）。确认节点间连通性（核心 fabric 交换机、链路状态、MTU）。如果已达到阈值但存储仍无法挂载，请生成 sysdiag 并联系支持。
* **问题：** 修复计数卡住或增加。
  * **解决方案：** 恢复后，少量且持续减少的 **修复** 计数是正常的。 **停止减少** 或 **增加** 的计数表示 vSAN 无法从对等节点重建的块。 **不要重启任何节点。** 在采取修复措施之前先联系支持。
* **问题：** 怀疑脑裂或集群状态不一致。
  * **解决方案：** 在恢复过程中，网络问题可能导致两组节点启动后彼此不可见。如果你看到形成两个独立集群的迹象（这种情况罕见，但在部分网络恢复后可能发生）， **不要自行尝试将它们合并**。请从每个节点抓取 sysdiag，并立即联系支持。
    {% endhint %}

## 预防/缓解

* **UPS 容量和覆盖范围** ——为每个节点按平滑关机时长加上余量来配置 UPS。将核心网络交换机也纳入同一供电覆盖范围。每年测试一次 UPS 运行时间——电池会老化。
* **自动平滑关机** ——使用 UPS 管理软件（NUT、IPMI 脚本，或在管理主机上使用 UPS 厂商代理）检测低电量事件，并触发集群平滑关机——可通过 Cluster Dashboard 的 **关闭电源** 操作、VergeOS API（`POST /v4/cluster_actions` ，请求体为 `{"cluster": <cluster_id>, "action": "shutdown", "params": "{}"}`），或者通过我们的 [**VRG CLI**](https://github.com/verge-io/vrg) 封装器从 Linux/macOS/Windows 主机脚本化执行同样的关机调用。在依赖它之前，请先在维护窗口中验证自动化流程。
* **“断电时”虚拟机设置** ——有意配置每个虚拟机的行为，以便恢复后的状态可预测。有三种选项：
  * ***上次状态*** ——只有在失电时处于开启状态的虚拟机才会启动
  * ***保持关闭*** ——恢复供电时虚拟机保持关闭，无论之前状态如何
  * ***开机*** ——恢复供电时虚拟机会启动，无论之前状态如何
* **修复服务器（ioGuardian）** ——一个已配置的 [修复服务器](/automate-protect-and-extend/backup-and-dr/repair-server.md) 在对等节点在故障后无法提供缺失块时，为 VergeFS 提供备用来源。它基于现有的外发站点同步配置构建，并从已同步的远程 VergeOS 系统中拉取所需块。强烈建议在任何生产部署中使用修复服务器。
* **足够的快照轮换** ——维护一个快照保留计划，以便在需要时保留最近的、事件发生前的快照用于回滚。作为全面数据保护策略的一部分，也建议将快照复制到远程站点。

## 何时联系支持

请提交支持工单 **在** 重启节点或进行任何其他重大更改之前，如果满足以下任何一种情况：

* 在 N 个节点上线后 vSAN 仍无法挂载（例如，在默认 N+1 冗余下，节点总数减一仍不行）
* 某个层显示 **Redundant: false** 在 Full Walk 完成后的较长时间内
* 该 **修复** 计数卡住或增加
* 存在“修复卡住”告警（VergeOS v26+）
* 恢复后多块驱动器报告错误
* 你怀疑脑裂或集群状态不一致
* 任何节点都无法重新加入，且原因并非明显的硬件问题

## 为支持生成系统诊断

在打开工单之前，请抓取 sysdiag 并附上（或直接发送给支持）：

参见 [生成系统诊断信息](/knowledge-base/zh/troubleshooting/generating-system-diagnostics.md) 以及完整的 [系统诊断](/run-the-platform/system-administration/diagnostics.md) 参考。

## 其他资源

* [正确的上电顺序](/knowledge-base/zh/system-administration/proper-power-sequence-for-vergeos.md)
* [VergeOS 系统正确关机流程](/knowledge-base/zh/system-administration/proper-vergeos-system-shutdown-procedure.md)
* [理解 Journal Walks 和 vSAN 层状态](/knowledge-base/zh/storage-vsan/understanding-journal-walks-and-vsan-tier-status.md)
* [生成系统诊断信息](/knowledge-base/zh/troubleshooting/generating-system-diagnostics.md)
* [修复服务器（ioGuardian）](/automate-protect-and-extend/backup-and-dr/repair-server.md)
* [vSAN 诊断指南](/run-the-platform/storage/vsan-diagnostics.md)

## 反馈

{% hint style="info" %}
**需要帮助吗？**

如果您需要进一步帮助，或对本文有任何疑问，请随时联系我们的支持团队。
{% endhint %}

***

{% hint style="info" %}
**文档信息**

* 最后更新：2026-05-08
* vergeOS 版本：26.0+
  {% endhint %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.verge.io/knowledge-base/zh/system-administration/cluster-recovery-after-power-outage.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.