---
title: "记一次惊心动魄的 ZFS 存储池恢复实战"
url: "https://lerry.me/post/2025/01/zfs-storage-pool-recovery"
date: 2025-01-04T10:18:57.990Z
updated: 2026-08-30T20:58:20.326Z
tags:
  - "Linux"
  - "Debian"
  - "ZFS"
language: zh-CN
---

# 记一次惊心动魄的 ZFS 存储池恢复实战

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

## 问题发现

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

## 问题诊断

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

```bash
# 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 助手的建议下，我们采取了以下步骤：

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

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

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

## 事后分析

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

## 经验总结

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

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