记一次 ZFS 存储池恢复实战

今天下午，我正准备给新起的项目配置数据库，发现本地 NAS 上的 PostgreSQL 数据库突然连接不上了。起初发现是硬盘满了，经过排查，更糟，ZFS 存储池不见了。这台 Nas 是用来备份的，因为 whale 池子不见了，定时备份命令把系统盘存满了。本文记录了这次数据恢复的全过程，希望能给遇到类似问题的朋友一些参考。

问题发现

PostgreSQL 数据库无法连接
系统提示硬盘空间已满
关键的 /whale 存储池完全消失
通过 lsblk 确认物理硬盘仍在线

问题诊断

执行 zpool import 命令后，系统返回了错误信息，看起来很严重：

# zpool import -d /dev/disk/by-id/ata-WDC_WUH721816ALE6L4_2BJNGLGN-part1
pool: whale
id: 6556284763754827846
state: FAULTED
status: The pool metadata is corrupted.
action: The pool cannot be imported due to damaged devices or data.
	The pool may be active on another system, but can be imported using
	the '-f' flag.
see: https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-72
config:

	whale                               FAULTED  corrupted data
	  ata-WDC_WUH721816ALE6L4_2BJNGLGN  ONLINE

存储池处于 FAULTED 状态，元数据遭到损坏。即使使用 -f 参数强制导入也未能解决问题。

解决过程

我把zpool import的回显和提示的网址发给 Cursor ，在 AI 助手的建议下，我们采取了以下步骤：

首先使用 zpool import -Fn whale 进行"dry run"测试，结果令人欣慰：

Would be able to return whale to its state as of 2025 年 01 月 03 日 星期五 20 时 36 分 47 秒.
Would discard approximately 5 seconds of transactions.

确认只会损失 5 秒的数据后，果断执行了实际恢复操作：
- 运行 zpool import -F whale
- 重启系统以确保所有服务正常运行
- 随机查看了一些文件，没有发现损坏的迹象
- 执行 zpool scrub whale 进行数据完整性检查

事后分析

昨天晚上，我回到家发现 Mac mini 关机了，查看 Nas 的 uptime 只有 16min ，说明家里断过电。这很可能是因为断电导致的存储池损坏。

经验总结

ZFS 的自愈能力确实强大，即使遇到元数据损坏也有恢复的可能
在进行重要操作前，使用 -n 参数进行干运行测试是个好习惯
UPS 电源保护对于 NAS 系统来说至关重要
定期备份依然是数据安全的最后防线

虽然这个池子只是备份数据，如果丢失了也很麻烦。还好虚惊一场。AI 确实强大，文档链接直接丢给它就能给出方案。

https://lerry.me/post/2025/01/zfs-storage-pool-recovery

ryd994

255 天前

@riceball 建议你实际看一下 dedup ratio 是多少
zpool get all whale

对于大部分人来说，compression 基本免费（现代 CPU 很强大），dedup 基本不值得。因为 dedup 的性能开销很大而且实际效果不佳。重复一遍：一般人不需要 dedup 。

为什么用 zfs 而不是 mdadm：因为 zfs 有校验，定期 resilver 可以处理冷错误。普通 raid 无法检测不一致的情况，因为 raid 的设计目标就是假设磁盘故障就完全掉线，既不会超时，也不会返回错误数据。这个假设对于短期储存的应用数据是足够的。但是对于长期储存的数据安全是不够的。

raid 卡就更别说了。数据安全和硬件绑定。而且性能非常有限。以前 CPU 羸弱，raid 卡可以分担负载所以有用。现在 CPU 很强，高性能阵列要靠 vroc ，raid 卡纯减速了。

带 bbu cache 的 raid 卡性能会比较好，但仍然受制于 pcie 带宽。企业级 SSD 自带掉电保护，所以 bbu cache 也不会有明显的性能增益。而且价格很贵。