12. 硬盘损坏全程记录

本文是这次 PVE 折腾里最沉重的一篇。 三块数据相关盘,一块有过 metadata 永久损坏,一块当前 DEGRADED,一块 power retract 计数异常高。一次次"还好没出事"积累成了真实事故。

整体盘点

1
2
3
4
5
6
7
PVE host 4 盘:
┌──────────────────────────────────────────────────────────────┐
│ sda  Kingston SA400 120G      rpool (mirror 一半)            │
│ sdb  Kingston RBUSC 128G      rpool (mirror 另一半)          │
│ sdc  Great Wall GW600 1TB     SSD_1TB 池 (VM/CT 数据)         │
│ sdd  Seagate ST3000NM0053 3TB HHD_3TB 池 (PBS/RustFS/Kopia)  │
└──────────────────────────────────────────────────────────────┘

详细 SMART (2026-09-02 当前)

盘	型号	通电	周期	断电 retract	Wear/Realloc	状态
sda	Kingston SA400 120G	15,550 h	1,305	-	-	✅ 健康
sdb	Kingston RBUSC 128G	13,683 h	62	25	Wearout 12,621	✅ 健康
sdc	Great Wall GW600 1TB	7,064 h	1,655	779	WLC 37,726,810	⚠️ DEGRADED
sdd	Seagate ST3000NM0053 3TB	11,853 h	92	-	Realloc 0	⚠️ 历史 metadata 损坏

事件一: HHD_3TB 池 metadata 永久损坏 (2026-08-30 发现)

现象

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
$ zpool status HHD_3TB
  pool: HHD_3TB
 state: ONLINE
config:
        NAME                         STATE
        HHD_3TB                      ONLINE
          ata-ST3000NM0053_Z1Y0PBQS  ONLINE

errors: 4 data errors
Permanent errors have been detected in:
        <metadata>:<0x0>
        <metadata>:<0x3d>

含义

ZFS metadata 永久损坏 = 文件系统结构本身不可信。

不是某个文件坏了,是文件系统"知道哪些文件在哪"的那张表坏了。

永久 vs 可恢复

类型	能否恢复
Data block checksum 错	✅ scrub 可自动修
Data block 真坏	❌ 不可恢复,但有 mirror 还能从另一盘读
Metadata block 错	✅/❌ 取决于是否有冗余
Metadata 永久损坏 (单盘)	❌ 不可恢复

我这次是单盘池,永久损坏 = 数据本身可能还在,但"谁是谁"无法验证。

影响范围

1
2
3
/HHD_3TB/backup/                 # PBS datastore,498G
/HHD_3TB/subvol-102-disk-0/     # CT102 Kopia 仓库 rootfs,57G
/HHD_3TB/... (其他)              # 数据

PBS 备份 + Kopia 备份两个最关键的数据都在这个坏池上。

触发原因 (推测)

可能性:

断电: 669 次 power retract (HDD 端),PVE 无 UPS
磁盘老化: 11,853 小时 = ~1.35 年连续运行
I/O 错误: 346 次命令超时
先天脆弱: 单盘无冗余,任何小错都会被放大成永久损坏

处置

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
# 1. 抢救 PBS 备份
rsync -a /HHD_3TB/backup/ /SSD_1TB/backup_rescue/

# 2. 抢救 Kopia 仓库
rsync -a /HHD_3TB/subvol-102-disk-0/ /SSD_1TB/kopia_rescue/

# 3. clear errors (虽然不修根本问题)
zpool clear HHD_3TB

# 4. 重新跑 scrub
zpool scrub HHD_3TB
# 5:17:29, repaired 0B with 0 errors

scrub 报告正常,但这是因为 metadata 损坏已经在 errors 表里"消化",并不是真的修了。

后续

Kopia 仓库抢救后,完整性无法保证,详见 10-Kopia数据丢失与复盘
决定转用 RustFS S3 后端
PBS 备份继续用 HHD_3TB (因为 PVE 备份相对能容忍部分损坏,毕竟还可以从 VM/CT 重做)

事件二: SSD_1TB 池 DEGRADED (2026-09-02 当前)

现象

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
$ zpool status SSD_1TB
  pool: SSD_1TB
 state: DEGRADED
status: One or more devices has experienced an unrecoverable error.  An
	attempt was made to correct the error.  Applications are unaffected.
action: Determine if the device needs to be replaced, and clear the errors
	using 'zpool clear' or replace the device with 'zpool replace'.
config:
        NAME                                       STATE
        SSD_1TB                                    DEGRADED
          ata-Great_Wall_GW600_1TB_AA202502220964  DEGRADED  too many errors

含义

GW600 1TB SSD 出现了 ZFS 无法自动恢复的错误。

“An attempt was made to correct the error” = ZFS 试图修,但没修好
“Applications are unaffected” = 当前没在影响 VM/CT,但风险在积累
“too many errors” = 错误数超过阈值,ZFS 把这个设备标记为可疑

触发原因 (推测)

断电:

1
2
3
Power_Off_Retract_Count: 779   ← 779 次突然断电
Power_Cycle_Count: 1655        ← 1655 次开机
Wear_Leveling_Count: 37,726,810  ← 大量写入

这个盘:

1,655 次开机 / 7,064 小时 = 平均每 4.3 小时 1 次开机 (一天 ~5 次)
779 次 power retract = 47% 的开机伴随突然断电

这意味着家用电网频繁波动(可能没 UPS),或者 PVE 经常被强制重启。

GW600 SSD 历史

这块盘是 2025-02-22 生产的"长城 GW600 1TB",便宜消费级 SSD,无 DRAM cache。

写入寿命: TLC,标称 ~300 TBW,目前估算 25-30 TB (~10% 寿命)
价格: 当时 ¥300 左右
设计: 不适合服务器场景

结论: 便宜 SSD 在家庭 PVE 用 1.5 年就 DEGRADED,完全符合预期。

处置

短期: 不动,等迁移方案落地。

已经在 pve-host-linux 存储重构与迁移方案里计划
阶段 2: 重装 PVE,新 2×512G SSD mirror

中期 (本周内):

监控 SSD_1TB pool errors 是否继续涨
准备好换盘方案

事件三: GW600 power retract 异常 (2026-09-02 发现)

现象

1
2
3
sdc GW600 1TB:
  Power_Cycle_Count: 1655
  Power_Off_Retract_Count: 779

47% 的开机伴随突然断电,这是非常糟糕的电源环境。

含义

家用 PVE 没有 UPS,或者有 UPS 但没起作用。

每次突然断电:

SSD: 增加写入放大、可能 metadata 错
HDD: head retract,可能 platter 损坏
ZFS: txg 可能丢失(如果正在写)

累计效应

7,064 小时 = ~295 天,期间 1,655 次开机。

即使每天开机一次,295 天也只有 295 次。这里 1,655 次说明平均每天 5+ 次。

可能是:

路由器/交换机重启
PVE 自动更新触发 reboot
调试时频繁重启
电网波动

处置

买 UPS (APC BK650 ~¥400)
配置 PVE 优雅关机 (apcupsd / nut)
监控 smartd,突然断电立即告警

电源质量数据汇总

设备	Power_Cycle	Power_Off_Retract
sda (Kingston 120G)	1,305	-
sdb (Kingston 128G)	62	25
sdc (GW600 1TB)	1,655	779
sdd (ST3000NM0053 3TB)	92	-

sdc 是异常值。可能:

跟同一电源线但单独重启了(VM/CT 强制 stop?)
跟它接的 SATA 控制器有问题
用了便宜电源,频繁掉电保护

散热数据

设备	当前温度	历史最高
sda	33°C	64°C
sdb	33°C	42°C
sdc	-	-
sdd	49°C (略高)	-

sdd (HDD) 49°C 偏热。HDD 长期 > 45°C 会加速老化。

处置:

检查机箱内风道
考虑给 HDD 加风扇

ZFS 当前状态

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
HHD_3TB: ONLINE, 单盘 (Seagate ST3000NM0053 3TB)
         历史上 metadata 永久损坏 (zpool clear 过了)
         现在 errors: No known data errors
         风险: 高 (单盘 + 老盘 + 频繁断电)

SSD_1TB: DEGRADED, 单盘 (Great Wall GW600 1TB)
         当前 ZFS 标记 GW600 为 too many errors
         VM/CT 数据跑这里 → 风险很高
         (详见 pve-host-linux 存储重构与迁移方案 阶段 1-2 重构)

rpool:   ONLINE, mirror (Kingston 120G + Kingston 128G)
         健康,系统盘

3 个池,1 个 ONLINE 健康,2 个有不同程度的问题。

教训

教训 1: 单盘无冗余是最危险的配置 ⭐

HHD_3TB 单盘运行了一年多,直到 metadata 永久损坏我才意识到。

任何 metadata 损坏 / 坏块 / 写入错 → 直接影响数据本身。

原则: 任何存重要数据的 ZFS pool 必须 mirror。

教训 2: 频繁断电对硬件和数据都是致命

sdc 的 779 次 power retract 是惊人数字。

家用环境:

没 UPS → 频繁断电 → 磁盘损坏 → 数据丢失
这是最便宜也最致命的硬件投资:UPS ~¥400

原则: PVE 必须配 UPS。

教训 3: 便宜消费级 SSD 不适合服务器

GW600 1TB ~¥300 用了 1.5 年就 DEGRADED。

便宜 SSD:

无 DRAM cache → 写入慢 + 寿命短
无 PLP (Power Loss Protection) → 断电数据丢失
控制器质量差 → 高 TBW 反而是隐患

原则: 服务器用企业级 SSD (Samsung PM893 / Intel D3-S4520),贵的 1.5 倍但寿命 5 倍以上。

教训 4: 没监控等于没数据

我从来没装 smartmontools,从来没定期看 zpool status。

metadata 错误是悄悄积累的,直到 errors: 4 才发现。

原则: PVE 装机第一天就装 smartmontools + zed (ZFS Event Daemon) + 自动告警。

教训 5: 数据要有 3 份

这次事故中:

PBS 备份 (单盘 HHD_3TB,部分损坏)
Kopia 仓库 (单盘 HHD_3TB,部分损坏)
抢救到 SSD_1TB (单盘 SSD,本身已经 DEGRADED)

没有任何数据真正有备份。

3-2-1 原则:

3 份副本
2 种介质
1 份异地

我之前一份都没有。

行动计划

立即 (本周)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
# 1. 监控 SSD_1TB pool errors
zpool status SSD_1TB
# 看 errors 是否继续涨

# 2. 备份 SSD_1TB 上的 VM/CT 到别处
vzdump 100 105 --storage HHD_3TB
pct dump 104 110 111 --storage HHD_3TB

# 3. 验证 PBS 备份可读
proxmox-backup-client snapshot list --repository ... 

短期 (本月)

买 UPS (APC BK650)
装 nut + apcupsd
配置 smartd 告警
配置 zed 告警
给 HDD 加风扇(降到 40°C 以下)

中期 (1-3 个月)

买 2× 512G SSD 企业级
重装 PVE + 建新数据池 mirror
把 VM/CT 全迁到新池
销毁 SSD_1TB 池(老的 GW600)

长期

Backblaze B2 异地备份(~¥10/月 500GB)
每月一次恢复演练
每年一次硬盘健康检查报告归档

心态

这次硬盘事故让我对家庭 PVE 的态度有了变化:

之前: “反正家里东西不重要,坏了就坏了” 现在: “家庭数字资产跟公司数据一样重要”

家庭数字资产可能比公司还多:

照片 / 视频(多年累积)
工作文档
学习笔记
项目代码
各种账号凭证

坏了就坏了 这种心态会让人失去很多东西而不自知。

资源链接

pve-host-linux 存储重构与迁移方案: 计划换盘、重装方案
02-硬件体检-SMART与温度: SMART 体检命令
10-Kopia数据丢失与复盘: Kopia 数据丢失事件
11-RustFS部署与Kopia切换: RustFS 部署
03-PBS数据备份迁移: PBS 备份架构

回索引页 →

12. 硬盘损坏全程记录#

整体盘点#

详细 SMART (2026-09-02 当前)#

事件一: HHD_3TB 池 metadata 永久损坏 (2026-08-30 发现)#

现象#

含义#

永久 vs 可恢复#

影响范围#

触发原因 (推测)#

处置#

后续#

事件二: SSD_1TB 池 DEGRADED (2026-09-02 当前)#

现象#

含义#

触发原因 (推测)#

GW600 SSD 历史#

处置#

事件三: GW600 power retract 异常 (2026-09-02 发现)#

现象#

含义#

累计效应#

处置#

电源质量数据汇总#

散热数据#

ZFS 当前状态#

教训#

教训 1: 单盘无冗余是最危险的配置 ⭐#

教训 2: 频繁断电对硬件和数据都是致命#

教训 3: 便宜消费级 SSD 不适合服务器#

教训 4: 没监控等于没数据#

教训 5: 数据要有 3 份#

行动计划#

立即 (本周)#

短期 (本月)#

中期 (1-3 个月)#

长期#

心态#

资源链接#

下一篇#

12. 硬盘损坏全程记录

整体盘点

详细 SMART (2026-09-02 当前)

事件一: HHD_3TB 池 metadata 永久损坏 (2026-08-30 发现)

现象

含义

永久 vs 可恢复

影响范围

触发原因 (推测)

处置

后续

事件二: SSD_1TB 池 DEGRADED (2026-09-02 当前)

现象

含义

触发原因 (推测)

GW600 SSD 历史

处置

事件三: GW600 power retract 异常 (2026-09-02 发现)

现象

含义

累计效应

处置

电源质量数据汇总

散热数据

ZFS 当前状态

教训

教训 1: 单盘无冗余是最危险的配置 ⭐

教训 2: 频繁断电对硬件和数据都是致命

教训 3: 便宜消费级 SSD 不适合服务器

教训 4: 没监控等于没数据

教训 5: 数据要有 3 份

行动计划

立即 (本周)

短期 (本月)

中期 (1-3 个月)

长期

心态

资源链接

下一篇