记录 DRBD quorum 事故复盘与 sandbox 恢复流程

2026-09-25 18:09:49 +00:00
parent a8479178f3
commit 409e350c83
4 changed files with 299 additions and 4 deletions
@@ -0,0 +1,228 @@
+---
+title: 2026-09-25 DRBD quorum 抖动与 sandbox 控制面中断
+last_reviewed: 2026-09-25
+---
+
+# 2026-09-25 DRBD quorum 抖动与 sandbox 控制面中断
+
+状态：服务已恢复；事故机制已确认，资源争用的具体瓶颈与预防性整改仍待验证。
+时间统一使用 UTC。报告依据当日 PVE/VyOS/guest 现场日志、相关操作会话和未提交 IaC；
+不是全量数据完整性审计，也不把短期恢复等同于根因消除。
+
+## 结论
+
+共享 PostgreSQL 的承载准备在 17:12 为 CT150、CT151 新建 16 GiB、32 GiB HDD DRBD
+数据卷，两卷初始同步重叠。随后多个既有 DRBD 资源出现 PingAck 超时和 quorum 丢失。
+sandbox1 根卷在 17:15:49 因 I/O 错误中止 ext4 journal、进入只读，PostgreSQL 主库和
+本机 K3s 退出；sandbox2 K3s 也失去数据库连接。VyOS HAProxy 摘除了不可连接的后端，
+从客户端看起来像 LB 故障。etcd CT150 的 SSD 根卷在 17:16:52 也发生同类故障。
+
+**已确认的直接故障机制**是 DRBD 失去 quorum 后按 `on-no-quorum=io-error` 返回错误，
+引发 ext4 只读和上层服务中断。**最有证据支持的触发因素**是新 HDD 卷并发初始同步期间的
+共享资源压力；尚无故障时段的链路队列、丢包、磁盘延迟和 CPU 调度证据，不能定论为
+某条链路打满、某块磁盘损坏或唯一由 resync 流量造成。
+
+这次更接近故障的操作是“创建数据卷并触发复制”，不是 15:30–15:32 已完成的 etcd
+rootfs 迁移。新 shared PostgreSQL 当时尚未启动，未迁移现有 CNPG 或 sandbox 数据库；
+影响经共享底层存储扩散到原有服务。
+
+## 影响与恢复边界
+
+| 对象 | 已观察到的影响 | 恢复证据 |
+| --- | --- | --- |
+| sandbox PostgreSQL，`10.60.0.1:5432` | 主库 `10.60.0.11` 停止监听，LB 无可用 backend | 原主库 crash recovery 完成；sandbox2 streaming/sync，采样 replay lag=0 |
+| sandbox K3s，`10.60.0.13:6443` | 两个 API 后端拒绝连接，控制面不可用 | 两个直连 API 与 VIP `/readyz=ok`；两节点和全部 Pod Ready |
+| OpenSandbox，`10.60.0.13:8080` | 健康入口仍可返回 200；依赖 K3s 的生命周期操作受控制面中断影响 | `/health` healthy；本轮未实际创建/销毁 sandbox，不能用 health 替代业务验收 |
+| shared etcd CT150 | SSD rootfs `emergency_ro`，成员无法正常服务，触发无 leader/频繁选举告警 | 另一会话完成离线修复，记录三成员 endpoint healthy、Raft term/index 一致 |
+| 其他 DRBD 资源 | pve1 在限定窗口记录 11 个资源共 43 次 quorum 丢失 | 尚未逐项完成 guest/应用层影响审计，不能说其他服务均未受影响 |
+
+API 全后端不可用从 HAProxy 17:16:01 告警可确认；约 17:49 已有可用 API，
+约 17:51 完成双后端、节点与 Pod 验收。控制面中断约 33 分钟，完整恢复约 35 分钟。
+恢复后的复制和服务检查未发现新的异常，但不能据此证明中断期间全部业务请求成功或零数据丢失。
+数据库日志曾记录同步等待取消及“本地已提交、可能尚未复制”，未逐事务审计；未执行 WAL reset、
+standby 提升、数据库重建或恢复旧备份。
+
+## 变更范围与存储映射
+
+| 用途 | PVE/容器 | DRBD resource | 设备 | 存储池/大小 |
+| --- | --- | --- | --- | --- |
+| 既有 sandbox1 根盘，包含 K3s datastore 主库 | pve1 / CT148 | `pm-6d8bee62` | `drbd1007` | `pve-rg-hdd` / 32 GiB |
+| etcd-pve1 根盘 | pve1 / CT150 | `pm-d1d1f3ea` | `drbd1008` | `pve-rg` SSD / 8 GiB |
+| 新 PG standby 数据盘 | pve1 / CT150 mp0 | `pm-af21c43d` | `drbd1011` | `pve-rg-hdd` / 16 GiB |
+| 新 pgBackRest 仓库盘 | pve2 / CT151 mp0 | `pm-de86804d` | `drbd1012` | `pve-rg-hdd` / 32 GiB |
+
+17:12:20，pve1 作为 SyncSource 向 pve3 同步 CT150 新盘；17:12:56，pve1 又作为
+SyncTarget 从 pve2 接收 CT151 新盘。容器操作串行不代表底层复制串行，也不代表不同
+SSD/HDD 池具有独立的网络、宿主调度或 I/O 故障域。
+
+## 时间线
+
+| UTC | 事件与证据 |
+| --- | --- |
+| 15:30:16–15:31:09 | CT150 `move_volume` 完成，PVE 任务 OK；`local-lvm` → `pve-rg` |
+| 15:31:32–15:32:11 | CT151 同类迁移完成；会话随后确认三 etcd 端点健康 |
+| 17:09:14 | PG 会话说明即将创建独立 HDD mp0、增加内存预算，不启动 PG |
+| 17:11:46 | 执行 `ansible-playbook pve-storage.yml` |
+| 17:12:20 / 17:12:56 | 两个新 HDD 资源分别开始 DRBD 初始同步，发生重叠 |
+| 17:14:00 | 本报告 17:10–17:55 pve1 内核窗口内首条 `quorum( yes -> no )`；对象为既有 `pm-59a94edd` |
+| 17:14:09 | PG 会话报告承载准备完成、etcd 健康；未包含 DRBD 同步完成和跨服务检查 |
+| 17:15:47–17:15:48 | sandbox1 根卷先后丢失 pve3、pve2 连接，quorum yes→no |
+| 17:15:49 | `drbd1007` 写入错误、MMP 写失败、journal abort、只读；PG 启动控制命令报 I/O error，K3s SIGBUS |
+| 17:15:54 | HAProxy 报 sandbox1 API 和 PostgreSQL 后端 DOWN |
+| 17:16:01 | sandbox2 API 后端也 DOWN，K3s backend 无可用服务器 |
+| 17:16:52 | CT150 `drbd1008` 失去 quorum，ext4 进入只读 |
+| 17:18:53 | PG 会话发现 CT150 只读，暂停后续部署；另两个 etcd 成员健康 |
+| 17:20:27 | 维护者在 PG 会话提供 `SharedEtcdNoLeader` 实际通知 |
+| 17:20–17:25 | 准备限速；先遇到 playbook 路径错误，随后遇到 YAML 条件表达式类型错误，修正后重跑 |
+| 17:23:39 | 该内核窗口内最后一条 quorum 丢失；之后仍有 PingAck 超时，不能写成“限速后才停止 quorum 丢失” |
+| 17:24:37 | Alertmanager 会话获知 etcd 正在另一路调整，结束该会话对 etcd 的排查 |
+| 17:25:58 | 会话收到限速成功结果，两主机各 changed=1；新卷 `c-max-rate=10240` |
+| 17:25:59–17:28:11 | CT150 停机、离线修复、重新启动；约 17:30 报告三成员健康 |
+| 17:31:21 / 17:33:38 | CT151 / CT150 新数据卷分别完成 DRBD 同步，内核标记 resync-finished |
+| 17:42 起 | 维护者报告 sandbox LB 异常，本会话开始排查 |
+| 17:43–17:46 | 确认 HAProxy 正常、后端故障；定位 sandbox1 根盘 emergency_ro 和原始 quorum/I/O 日志 |
+| 17:46:41–17:46:49 | CT148 正常关机完成 |
+| 17:47–17:48 | `pct fsck 148 --device rootfs --force 1` 恢复 journal、清理 orphan inode；只读 `e2fsck -fn` 五阶段通过、返回 0 |
+| 17:48:40–17:48:44 | CT148 启动；根盘恢复 rw 且无 emergency_ro |
+| 17:49:04 / 17:49:08 | 原 PG 主库恢复接收连接；sandbox2 恢复同步 standby |
+| 17:50:40 左右 | sandbox2 K3s 在重启服务后恢复 API；此前旧进程卡在故障期间的启动/关闭状态 |
+| 约 17:51 | 两个 API 和 VIP readyz 通过、两节点及全部 Pod Ready、复制 lag=0 |
+| 17:53:49 | 两个新卷现场复核均 Established/UpToDate，限速属性和运行配置仍为 10240 |
+
+宿主默认 journal 展示曾为 UTC+9，guest/VyOS 使用 UTC。初次用 UTC 字面时间过滤宿主
+本地日志没有找到错误；后来用 `journalctl --utc` 和明确 UTC 时间窗口纠正。上表不使用
+未经转换的 `Sep 26 02:xx` 作为独立事故时间。
+
+## 故障机制与变更保护缺口
+
+```mermaid
+flowchart TD
+    A[新增两个 HDD 数据卷] --> B[初始同步重叠]
+    B -. 资源压力为待证实触发因素 .-> C[多个 DRBD 对端 PingAck 超时]
+    C --> D[既有卷失去 majority quorum]
+    D --> E[on-no-quorum=io-error]
+    E --> F[ext4 journal abort / emergency_ro]
+    F --> G[sandbox PostgreSQL 与本机 K3s 退出]
+    G --> H[另一 K3s 失去 datastore / API 中断]
+    H --> I[HAProxy 后端均 DOWN]
+    F --> J[shared etcd 单成员异常]
+```
+
+1. **变更验收停在容器/etcd 层。** `serial: 1` 和 endpoint health 只限制 Ansible 的
+   容器操作顺序；未等待前一 DRBD 新卷完全同步，所以后台复制仍重叠。
+2. **未把新卷创建视为共享基础设施变更。** 新数据库尚未运行、卷内没有业务数据，
+   仍会发生全卷复制并影响现有资源。仅检查新服务健康不能限制影响范围。
+3. **恢复检查范围过窄。** 首轮识别并恢复 CT150 后，未沿同批 quorum/I/O 日志
+   核查 CT148 等既有消费者；sandbox 控制面继续故障，直至维护者再次报告。
+4. **监控缺少依赖链覆盖。** Alertmanager 通知当天已打通，etcd 实际告警送达；
+   不能归因于“没有通知”。另一会话的盘点发现告警主要覆盖监控自身及 shared etcd，
+   尚缺可证明有效的跨资源 DRBD、文件系统异常、sandbox API 外部可用性覆盖。
+   `/health=200` 与单节点 Ready 也不足以证明两个 API 后端健康。
+5. **紧急缓解执行有延迟。** 限速 playbook 首次工作目录错误、随后条件被 YAML
+   解析成非字符串，两次均在配置变更前失败；直到 17:25:58 才有成功回执。
+
+限速后短期稳定且最终同步完成支持资源压力假设，但缺少控制变量；本次最后一次 quorum
+丢失早于成功限速，不能把时间相关性写成严格因果证明。现有 `pve-storage.yml` 已补入
+限速任务，但位于 `pct set --mp0` **之后**；初始同步在创建卷时已经开始，仍存在未限速
+窗口，并且仍缺 DRBD 同步完成屏障。此报告没有擅自更改这些并行工作中的实现。
+
+## 已完成处置与验收
+
+- PG/etcd 会话：仅为两个新卷设置资源级 `DrbdOptions/PeerDevice/c-max-rate=10240`
+  （配置的自适应同步上限 10 MiB/s），记录幂等复跑无变更；CT150 离线修复后恢复三端点健康。
+- 本会话：确认 CT148 stopped、卷身份/未挂载、副本 UpToDate/quorum 后，使用 PVE 安全自动
+  fsck；返回 1 表示已修复，随后独立只读完整检查返回 0，再启动原容器。
+- PostgreSQL 自行回放 WAL 并恢复原角色；未切主。sandbox2 K3s 在数据库恢复后仍卡住，
+  仅重启该 K3s 服务，未重启或提升它的 PostgreSQL。
+- 两个直连 API 与 VyOS VIP `/readyz` 均为 ok；全部 Pod Ready；所有相关 HAProxy
+  后端 UP/L4OK；OpenSandbox `/health` healthy；目标根卷恢复正常 rw。
+- 未修改 VyOS LB、全局 DRBD 协议/quorum/超时或集群网络。VyOS 最新提交及生成配置仍为
+  9 月 18 日，最近两次 LB 变更仅新增 OpenSandbox 入口并调整其超时。
+
+## 后续整改与关闭标准
+
+下列项目是待办，不代表已获执行或发布授权；责任人/issue 由维护者分配。
+
+| 优先级 | 项目 | 验收条件 |
+| --- | --- | --- |
+| P0 | 审计同批受影响 DRBD 资源对应 guest/应用 | 11 个资源逐一映射并记录文件系统、服务和数据层状态，不能只看 DRBD UpToDate |
+| P0 | 新卷创建前实施同步预算，新增 DRBD 同步屏障 | 第一字节同步前限额已生效；全部所需副本 UpToDate/Established 才允许下一卷；超时/异常停止推进 |
+| P0 | 扩大存储变更前后健康检查 | 验证已有 sandbox API、datastore、etcd 等消费者；新增 quorum loss、I/O 错误或只读即中止变更 |
+| P1 | 采集并定位实际瓶颈 | 对齐三宿主网络丢包/队列、吞吐、磁盘 await、CPU/PSI、DRBD 状态；无证据不直接扩大 ping timeout |
+| P1 | 补齐可操作告警 | DRBD quorum/peer、ext4 emergency_ro、数据库与 API 外部探测、LB 零后端，并演练真实通知链路 |
+| P1 | 恢复后业务验收与数据检查 | 对现有 sandbox 生命周期操作做受控验收，核对 PG 数据/备份和应用影响，单独报告不能验证的 RPO |
+| P1 | 复核共享故障域与同步总预算 | 同时覆盖多个 resource/peer；区分 SSD/HDD 池和物理网络/宿主故障域；设计限速或隔离方案后再测试 |
+| P2 | 标准化取证与并行变更交接 | 时间统一 UTC；事故期间共享受影响资源表、执行日志和完成边界；先 syntax/check，再执行缓解 playbook |
+
+关闭本次根因整改需完成：跨资源影响审计、同步前预算与屏障验证、消费者健康保护、
+足够覆盖复制全过程的稳定性观察。当前只可宣称 **sandbox 服务恢复**。
+
+## 证据与来源
+
+### 现场关键摘录
+
+```text
+17:12:20 drbd pm-af21c43d/0 drbd1011 pve3: Began resync as SyncSource
+17:12:56 drbd pm-de86804d/0 drbd1012 pve2: Began resync as SyncTarget
+17:15:47 drbd pm-6d8bee62 pve3: PingAck did not arrive in time.
+17:15:48 drbd pm-6d8bee62 pve2: PingAck did not arrive in time.
+17:15:48 drbd pm-6d8bee62/0 drbd1007: quorum( yes -> no )
+17:15:49 EXT4-fs error (device drbd1007): kmmpd:181: Error writing to MMP block
+17:15:49 Aborting journal on device drbd1007-8.
+17:15:49 EXT4-fs (drbd1007): Remounting filesystem read-only
+17:16:52 drbd pm-d1d1f3ea/0 drbd1008: quorum( yes -> no )
+17:16:52 EXT4-fs (drbd1008): Remounting filesystem read-only
+17:31:21 drbd pm-de86804d/0 drbd1012 pve2: repl( SyncTarget -> Established ) [resync-finished]
+17:33:38 drbd pm-af21c43d/0 drbd1011 pve3: pdsk( Inconsistent -> UpToDate ) repl( SyncSource -> Established ) [resync-finished]
+```
+
+上述为 pve1 内核摘录，已省略重复前缀。43 次 quorum 丢失统计范围为 pve1 的
+`2026-09-25 17:10:00 UTC` 至 `17:55:00 UTC`，不是三节点全集群事件数。
+资源为 `pm-1f83b001`、`pm-57eb0cd7`、`pm-59a94edd`、`pm-6d8bee62`、
+`pm-7ad1a714`、`pm-a58b5f08`、`pm-cbba8c9d`、`pm-d1d1f3ea`、
+`pm-d4c12a89`、`pm-f21d1da3`、`vm-101-cloudinit`。
+
+可复核入口：宿主 `journalctl --utc -k --since '2026-09-25 17:10:00 UTC'
+--until '2026-09-25 17:55:00 UTC'`、`pvenode task list`、目标 `drbdsetup status`；
+VyOS `journalctl -u haproxy` 和只读 stats socket；guest PostgreSQL/K3s journal。
+日志有保留期限，后续审计应保存经过秘密审查的所需片段。
+
+### 操作会话
+
+按维护者指向的 spaces1、spaces3 线索，读取了本地以下实际会话；以会话 ID/标题定位，
+不把 UI 的位置编号当作长期标识。不复制完整会话或凭据。
+
+- `01a0d8c1-c4ad-7360-b52e-2a11c34dc13e`，**规划共享 PostgreSQL 数据库**：
+  17:11:46 工具调用 `ansible-playbook pve-storage.yml`；17:20:27 输出显示默认
+  `c-max-rate=102400k`，这只是配置上限，不是已测吞吐；17:25:58 两卷限速成功；
+  17:30–17:31 报告 CT150 恢复；对应 rollout 的关键记录在行 1916、2019、2068 附近。
+- `01a0d972-e6e5-7432-ad4b-4fd7ca7b3956`，**配置 Alertmanager 通知**：
+  17:13 用户确认测试通知送达；17:20 后观察到 etcd 新故障；17:24:37 用户确认
+  另一路正在调整 etcd；约 17:28–17:30 记录监控覆盖缺口。该会话的监控盘点不等于
+  对 sandbox 集群做过完整事故验收。
+- `01a0d9a9-7ef0-7992-a313-54668bb3b4e4`，**检查 VyOS 上的 LB 配置**：
+  本次 sandbox 诊断、CT148 离线恢复和最终链路验收。
+
+本地原记录位于 `/home/panxiao81/.codex/sessions/2026/09/25/`。
+会话说明只能证明当时的判断；时间线中执行结果以工具回执、PVE 任务和内核日志交叉核对。
+
+### 相关源码与运行手册
+
+- etcd rootfs 迁移：`infrastructure/etcd/ansible/move-storage.yml`
+- PG 数据卷准备：`infrastructure/shared-postgresql/ansible/pve-storage.yml`
+- 新卷限速任务：`infrastructure/shared-postgresql/ansible/tasks/limit-resync.yml`
+- etcd 故障恢复记录：`infrastructure/etcd/README.md`
+- shared PostgreSQL 当前部署边界：`infrastructure/shared-postgresql/README.md`
+- sandbox 架构与数据库依赖：`infrastructure/sandbox-cluster/README.md`
+
+上述源码路径相对于 homelab-infra；etcd/shared-postgresql 文件在取证时仍未提交，
+当前文件已包含事故后的限速补丁，不能倒推事故前已经有同样保护。
+本报告以 wiki 为唯一维护位置，长期操作流程见[Proxmox 恢复手册](../services/proxmox.md#sandbox-lb-与根文件系统恢复)。
+源码合并后再补其固定版本链接。
+
+### 取证过程中的敏感输出问题
+
+首次 VyOS 查询误认为 `cli-shell-api showConfig` 尾随 `load-balancing` 会限制子树，
+实际返回完整配置，包含 WireGuard 私钥及登录密码哈希，进入了本会话工具输出。
+后续已改为设备端提取所需段，并在 `CLAUDE.md` 记录陷阱；未把敏感值写入报告或仓库。
+既有会话记录并未因此消除，应限制其分享；相关凭据轮换需另行安排，不能称为已处理完毕。
@@ -59,7 +59,7 @@ SPIFFE/SPIRE 已按维护者授权补读 #34；LAN DNS 与 Authelia 已按维护
 | microvm-runner（历史目录名） | 动态 runner 的 homelab 基础设施记录 | 当前项目接口见 [Dynamic Runner](gitea-dynamic-runner.md) | 独立项目已更名并扩展到 Pod/VM，正在积极开发 | `infrastructure/microvm-runner/README.md`、独立项目文档 | 具体启用范围和实现进度以独立项目文档为准 |
 | [oci](oci.md) | 云主机、网络与站点互联 | `OCI ap-osaka-1` | 有恢复、接管与网络实施记录 | `infrastructure/oci/README.md` | 已有登录、站点网络与维护入口 |
 | [openbao](openbao.md) | 秘密管理与内部 CA | `bao.ad.ddupan.top` | 有部署与接管记录 | `infrastructure/openbao/README.md` | 已有登录、取密与运维入口指南 |
-| [proxmox](proxmox.md) | PVE、虚拟化与主机基础设施 | `PVE 管理入口` | 已有基础设施 | `infrastructure/proxmox/ansible/` 与 `README-ha.md` | 已有管理入口；身份与 runner 设计见独立项目 |
+| [proxmox](proxmox.md) | PVE、虚拟化与主机基础设施 | `PVE 管理入口` | 已有基础设施 | `infrastructure/proxmox/ansible/` 与 `README-ha.md` | 已有管理入口；sandbox LB/根盘恢复流程见服务页；身份与 runner 设计见独立项目 |
 | [samba-ad](samba-ad.md) | AD 身份、域 DNS 与域成员管理 | `dc1 / 192.168.10.5` | 有部署记录；维护者说明 DNS 部分已完成 | `infrastructure/samba-ad/README.md`、[LAN DNS](lan-dns.md) | 已有入域、目录浏览与日常管理入口 |

 ## 集群
@@ -2,15 +2,16 @@
 title: Proxmox 日常管理入口
 lifecycle: active
 evidence: documented
-last_reviewed: 2026-09-16
-last_verified: null
+last_reviewed: 2026-09-25
+last_verified: 2026-09-25
 ---

 # Proxmox

 Proxmox 承载 VM/LXC 与相应主机、网络和存储资源。
 本页依据 homelab-infra 工作区 `infrastructure/proxmox/README.md`、`README-ha.md`
-及已有 DNS 名称整理使用入口，不检查集群成员、VM、HA 或存储现场状态。
+及已有 DNS 名称整理使用入口；初轮未检查集群成员、VM、HA 或存储现场状态。
+2026-09-25 的有限现场验证仅覆盖下文 sandbox 存储恢复与 LB 链路，不代表整套 PVE/HA 验收。
 源码 README 尚未跟踪，HA 文档有工作区修改；配置已进一步核对 `auth.yml`、`site.yml`、
 `ha.yml` 与对应 role defaults，不将文档中的历史阶段备注当作当前配置。

@@ -76,3 +77,57 @@ PVE 主机存储、DRBD 副本和 k3s 的 [OpenEBS](openebs.md) 是不同管理
 长期配置入口为 `infrastructure/proxmox/ansible/`，并按实际变更选择对应 playbook。

 来源文件的固定版本与工作区差异见[来源追溯](../sources.md#proxmox)。
+
+
+## Sandbox LB 与根文件系统恢复
+
+Sandbox 的 VyOS 入口为 PostgreSQL `10.60.0.1:5432`、K3s API
+`10.60.0.13:6443`、OpenSandbox `10.60.0.13:8080`。数据库只转发到
+sandbox1 `10.60.0.11:5432`；K3s 转发到两个节点的 `6443`；OpenSandbox
+转发到两个节点的 `30080`。OpenSandbox `/health` 返回 200 不代表 K3s 控制面可用。
+配置依据为源码 `infrastructure/sandbox-cluster/README.md`、
+`infrastructure/proxmox/ansible/roles/vyos_router/` 及本轮 VyOS 现场检查；
+OpenSandbox 的 LB 条目在现场存在，不能推断旧 Ansible 模板已经管理该条目。
+
+排障先检查 HAProxy 监听和每个 backend 的状态，再直连后端。若后端拒绝连接，
+检查 PostgreSQL、K3s 与根文件系统，而不是仅重启 LB。
+`findmnt -no SOURCE,FSTYPE,OPTIONS /` 即使显示 `rw`，同时出现
+`emergency_ro` 也不能视为正常可写。
+
+DRBD 对端失联导致 quorum 丢失时，`on-no-quorum=io-error` 会向文件系统返回
+I/O 错误；ext4 可能中止 journal 并进入只读。DRBD 后来恢复 UpToDate/quorum
+并不会自动解除文件系统的故障状态。检查宿主日志时用 `journalctl --utc`，
+不要直接把宿主本地时间与 guest 的 UTC 时间比较。
+
+在已获停机恢复授权后，按以下顺序处理：
+
+1. 用 `pct config <VMID>`、`pvesm path <rootfs-volume>` 和 `drbdsetup status <resource> --verbose`
+   核对容器、卷和副本关系。确认链路稳定、quorum 正常、数据副本 UpToDate，且没有其他节点挂载该卷。
+2. 正常关闭故障容器，确认 stopped、卷未挂载且无遗留占用。禁止在运行中的根盘执行 fsck。
+3. 执行 `pct fsck <VMID> --device rootfs --force 1`。本机 PVE 使用 `fsck -a -l -f`；
+   底层返回 1 表示已修复，PVE 仍可能把它显示为命令失败。必须核对完整输出，不能把其他错误码当成功。
+4. 对同一已停机、未挂载卷执行 `e2fsck -fn <verified-device>`；返回 0 后再启动容器。
+   若自动安全修复未通过，暂停并评估数据恢复，不盲目加 `-y`、清空 WAL 或重建数据库。
+5. 等待 PostgreSQL 完成 crash recovery；验证主库 `pg_is_in_recovery()=false`、
+   standby 保持 recovery、`pg_stat_replication` 为 streaming/sync，检查 replay lag。
+   不把普通 TCP check 当成数据库可写性证明，也不自动提升 standby。
+6. 检查两个 K3s 服务、两个直连 API 和 VIP 的 `/readyz`、节点与 Pod Ready。
+   数据库已恢复而某个 K3s 长期停在 activating 时，核对日志与进程；必要时只重启该 K3s 服务。
+7. 从 VyOS 再核对每个 backend 为 UP，并验证 OpenSandbox `/health`。
+
+2026-09-25 现场验证范围：sandbox1 根盘离线修复和只读复检通过，重新挂载不再有
+`emergency_ro`；数据库恢复同步复制，采样 replay lag 为 0；两个 API 与 VIP 的
+`/readyz` 均为 ok，两个节点及全部 Pod Ready。故障证据为目标 DRBD 对端 PingAck
+超时、quorum 丢失及紧随其后的 ext4 写入错误；对端连接超时的上游原因尚未确定。
+本轮未修改 VyOS LB、DRBD quorum 策略或集群网络。此处保存恢复方法及有限验证边界，
+不代表已经消除存储网络复发风险。
+
+
+本次进一步复盘将触发线索收敛为：新 PG HDD 数据卷在 17:12 开始的初始同步发生重叠，
+随后多个既有 DRBD 资源失去 quorum；15:30–15:32 的 etcd rootfs 迁移与后来的新数据卷创建
+应分开记录。资源争用的具体瓶颈尚未实证。容器 `serial: 1` 和 etcd health 不等于 DRBD
+同步完成；新卷维护需在创建前建立同步预算，并在允许下一卷前等待所有必要副本同步。
+目前 PG 创建流程虽已在创建后加限速，仍存在初始未限速窗口，尚未补齐同步完成屏障。
+
+事故报告由 wiki 统一维护：[2026-09-25 DRBD quorum 抖动与 sandbox 控制面中断](../incidents/2026-09-25-drbd-quorum-sandbox.md)。
+其中保存统一 UTC 时间线、跨资源影响边界、相关操作会话和后续验收条件；本页保留可复用恢复方法。
@@ -112,3 +112,15 @@ controller、目标固定、finalizer 保留与生成 RBAC，真实 API server
 由 [PR #12](https://git.ddupan.top/panxiao81/ayatori/pulls/12) 跟踪 CI 与 review。
 全量测试、真实 PostgreSQL/API server/OpenBao 集成测试及两种 lint 本地通过；源码模块文档
 和 wiki 已同步实现边界与正式链接。尚未合并或接入供应流程，不把本地验证等同于远端 CI。
+
+## 2026-09-25 sandbox 存储故障复盘的来源边界
+
+维护者报告 VyOS 到 sandbox 的 LB 故障并授权恢复。现场确认 LB 配置未在故障当天更改，
+故障来自 DRBD quorum 丢失后 sandbox1 根卷进入只读；已离线修复并恢复数据库、双 API 与 Pod。
+后续按维护者给出的 PostgreSQL/Alertmanager 会话核对，发现新 HDD 数据卷初始同步重叠与
+多个既有资源故障的时间关联，尚未证明具体网络或磁盘瓶颈。长期恢复方法见
+[Proxmox](services/proxmox.md#sandbox-lb-与根文件系统恢复)。
+
+事故报告与恢复手册在 wiki 统一维护，见[完整事故报告](incidents/2026-09-25-drbd-quorum-sandbox.md)。
+取证引用的 etcd/shared-postgresql 源码当时尚未提交，固定版本关联待源码合并后补齐；
+服务恢复不等于全部整改完成。