凌晨 3 点，香港葵涌机房的值班工程师把一杯冻柠茶塞到我手里，屏幕上客户的“历史影像库”突然被一波批处理任务误删了 4TB 的素材。幸好，我们在 Debian 11 上的 ZFS 快照和异地复制早就铺好。

我深吸一口气，打了两行命令：

zfs list -t snapshot … zfs clone。

5 分钟后，电话安静了。那一刻，我决定把这套在香港机房里踩过坑、扛过流量、顶过夜的 ZFS 实战，写给还在机房里和我一样打硬仗的人。

目录

• 现场环境与目标（RPO/RTO、容量与吞吐）
• 硬件与网络拓扑（真实机房配置清单）
• Debian 11 上安装与内核适配（DKMS 的那些坑）
• 池（Pool）与 vdev 设计：RAIDZ2、SLOG、L2ARC、Special vdev
• 数据集与参数策略：recordsize、压缩、对齐、加密
• 快照与保留策略：从“好看”到“能救命”
• 跨机房复制与数据恢复剧本：mbuffer、raw send、回滚
• 故障演练：误删恢复、硬盘掉线、SLOG 损坏、池回滚
• 性能与调优：ARC/L2ARC、同步写、NFS/SMB、fio 实测
• 我踩过的坑与解决过程（现场教材）
• 收官：一个夜班工程师的“复盘”

1）现场环境与目标

业务画像：媒体素材与归档（大文件为主，读多写少），同时承载一部分 VM/NFS 的随机 IO。

目标：

• RPO（可接受的数据丢失窗口）：≤ 5 分钟（关键库 ≤ 1 分钟）
• RTO（恢复所需时间）：目录级恢复 ≤ 10 分钟，整库回滚 ≤ 30 分钟
• 容量：≥ 60 TB 可用（可水平扩容）
• 吞吐：顺序读写 ≥ 1.2 GB/s，随机 4K ≥ 80K IOPS（读主导）
• 合规：快照长期保留 + 异地只读副本（防勒索/误删）

2）硬件与网络拓扑（实配清单）

拓扑要点：

• 业务走万兆 LACP，备份复制走专线（限速 + mbuffer 调优）。
• HBA 必须 IT 模式直通，否则 ZFS 感知不到介质信息（后面有血泪坑）。
• SLOG 只给 sync=always 数据集加速（如 NFS/VM），L2ARC 用于热点读。
• 如需加速元数据/小文件，可加 special vdev（务必镜像）。

3）Debian 11 上安装与内核适配

坑 1：内核升级后 ZFS DKMS 没编译就重启 = 现场翻车。

源与依赖（Bullseye）：

# 1) 确保启用 contrib
sudo sed -i 's/main$/main contrib non-free/g' /etc/apt/sources.list
sudo apt update

# 2) 先装编译环境与头文件
sudo apt install -y build-essential linux-headers-$(uname -r) dkms

# 3) 安装 ZFS
sudo apt install -y zfs-dkms zfsutils-linux

# 4) 加载模块并开机自启
sudo modprobe zfs
sudo systemctl enable zfs-import-cache zfs-mount zfs-zed

建议：生产环境里，把内核与 zfs-dkms 绑定住，先编译 再重启。

# 阻止意外升级（可选，现场按变更窗口操作）
sudo apt-mark hold linux-image-amd64 linux-headers-amd64 zfs-dkms

4）池与 vdev 设计

4.1 用 /dev/disk/by-id，确保盘序稳定

ls -l /dev/disk/by-id/ | grep -E 'ATA|NVMe'

4.2 创建主池（RAIDZ2）+ SLOG（镜像）+ L2ARC

# ashift=12 -> 4K 物理扇区对齐（绝大多数 HDD/SSD）
# autotrim=on -> 对 SSD/NVMe 生效；HDD 基本不需要，但开着无害
sudo zpool create -o ashift=12 -o autotrim=on \
  -O compression=lz4 -O atime=off -O xattr=sa -O acltype=posixacl \
  tank \
  raidz2 \
  /dev/disk/by-id/ata-HDD_A ... /dev/disk/by-id/ata-HDD_J \
  log mirror /dev/disk/by-id/nvme-INTEL_P4801X_1 /dev/disk/by-id/nvme-INTEL_P4801X_2 \
  cache /dev/disk/by-id/nvme-SAMSUNG_PM983_1

容量估算：10×8TB RAIDZ2 ≈ (10-2)×8 = 64TB 原始可用（未计元数据/校验/对齐开销，实际挂载大约 58–60TB）。

4.3 可选：special vdev（元数据/小文件上 NVMe）

# special vdev 一旦损坏会导致池不可用 -> **务必镜像**
sudo zpool add tank special mirror \
  /dev/disk/by-id/nvme-SAMSUNG_PM983_1 /dev/disk/by-id/nvme-SAMSUNG_PM983_2

# 小于等于 32K 的块落到 special vdev
sudo zpool set special_small_blocks=32K tank

坑 2：把单块 NVMe 当 special vdev 用，掉一盘 = 全池跪。一定镜像。

5）数据集与参数策略

数据集分层（不同工作负载不同参数）：

创建与设置：

# 大文件素材
sudo zfs create -o recordsize=1M -o compression=lz4 -o atime=off tank/media

# 虚机镜像（KVM/ESXi NFS 后端）
sudo zfs create -o recordsize=16K -o sync=standard -o logbias=latency tank/vm

# 数据库（示例）
sudo zfs create -o recordsize=16K -o compression=lz4 tank/db

# 备份仓（接收 zfs send）
sudo zfs create -o recordsize=1M -o sync=disabled tank/backup

# 共享
sudo zfs create -o snapdir=visible tank/share

原生加密（可选）：

需要“异地只读 + 本地丢失也不可读”的场景，创建时启用：

sudo zfs create -o encryption=aes-256-gcm -o keyformat=passphrase tank/secure
# 导入/开机后加载密钥
sudo zfs load-key tank/secure

6）快照与保留策略（真正能救命的那种）

策略范式：

方案 A：使用发行版包 zfs-auto-snapshot（省心）

sudo apt install -y zfs-auto-snapshot
# 安装后会在 cron.* 下生成分钟/小时/天/周/月的任务
# 可通过环境变量调整保留数量：/etc/cron.d/zfs-auto-snapshot*

方案 B：自定义 cron（我在现场用的精简脚本）

# /usr/local/sbin/snap.sh
#!/usr/bin/env bash
set -euo pipefail
TS=$(date +%Y%m%d-%H%M)

for ds in tank/db tank/vm tank/media tank/share; do
  /usr/sbin/zfs snapshot -r ${ds}@${TS}
done

# 保留策略：只保留最近 N 个同前缀快照（示意）
/sbin/zfs list -H -t snapshot -o name | grep '@' | grep -E '^[^@]+@[0-9]{8}-[0-9]{4}$' \
  | awk -F@ '{print $1}' | sort | uniq | while read ds; do
    /sbin/zfs list -H -t snapshot -o name -S creation | grep "^${ds}@" \
     | tail -n +121 | xargs -r -n1 /usr/sbin/zfs destroy
  done

# 每分钟
* * * * * root /usr/local/sbin/snap.sh >/var/log/snap.log 2>&1

7）跨机房复制与数据恢复剧本

场景：主库在葵涌，DR 在将军澳；需要“近实时”增量副本、异地只读、防勒索。

首次全量 + 增量复制（加速用 mbuffer）：

# 目标端预建空数据集
ssh backup@dr-host "sudo zfs create -o readonly=on tankdr/backup"

# 首次全量（raw 可保留压缩/加密）
sudo zfs snapshot -r tank/media@seed
sudo zfs send -R tank/media@seed | mbuffer -q -m 1G -s 128k | \
  ssh backup@dr-host "mbuffer -q -m 1G -s 128k | sudo zfs receive -F tankdr/backup/media"

# 增量（-I 支持跨多个中间快照）
LAST=20240820-0200
CURR=20240820-0300
sudo zfs snapshot -r tank/media@${CURR}
sudo zfs send -RI ${LAST} tank/media@${CURR} | mbuffer -q -m 1G -s 128k | \
  ssh backup@dr-host "mbuffer -q -m 1G -s 128k | sudo zfs receive -F tankdr/backup/media"

只读副本：目标端设置 readonly=on，对勒索/误操作更友好。

带加密的 raw send：源端启用原生加密时，用 zfs send --raw 保留密文形态。

8）故障与恢复：我真的在夜里这样救过

8.1 误删目录/文件（最常见）

# 方式 1：直接从只读快照路径拷回（snapdir=visible 时）
cp -a /tank/share/.zfs/snapshot/20240820-0300/mydir /tank/share/

# 方式 2：克隆到临时挂载点对比
zfs clone tank/share@20240820-0300 tank/share_recover
rsync -aH --info=progress2 /tank/share_recover/mydir/ /tank/share/mydir/
zfs destroy tank/share_recover

8.2 全数据集回滚（确保窗口内业务停写）

# 先让应用停写 -> 快照回滚
zfs rollback -r tank/db@20240820-0300

8.3 单盘故障置换与重建

zpool status -xv
# 标记故障盘（by-id 最稳）
zpool offline tank /dev/disk/by-id/ata-HDD_D
# 物理更换 -> 新盘上线
zpool replace tank /dev/disk/by-id/ata-HDD_D /dev/disk/by-id/ata-HDD_NEW
# 自动开始 resilver
watch -n 5 zpool status

8.4 SLOG 损坏的影响与处理

有镜像：自动切换，性能下降但业务无中断。

无镜像：池仍可用，但可能丢失最近几秒的同步写事务；立刻更换并重建。

8.5 池导入“后悔药”（ZIL 回放失败/元数据损坏）

# 只在万不得已时使用，先 -n 模拟
zpool import -F -n -X tank
# 可回滚到最近一个事务组（TXG），减少损坏范围，然后实际导入
zpool import -F -X tank

9）性能与调优（含 fio 现场样本）

9.1 ARC/L2ARC 调整

# 限制 ARC 最大（比如 96GB），避免挤压应用
echo "options zfs zfs_arc_max=$((96*1024*1024*1024))" | sudo tee /etc/modprobe.d/zfs.conf
sudo update-initramfs -u
# 重启后生效；OpenZFS 支持持久 L2ARC，命中率逐步上升

9.2 NFS 服务（举例）

# 导出
echo "/tank/share 10.0.0.0/24(rw,sync,no_root_squash,no_subtree_check,fsid=0)" | sudo tee -a /etc/exports
sudo exportfs -ra

# 客户端挂载（建议开大 rsize/wsize，万兆链路）
mount -t nfs -o vers=3,rsize=1048576,wsize=1048576 10.0.0.10:/ /mnt/share

9.3 fio 样本（实际一线测试值，供参考）

经验：大块顺序 IO 吃 recordsize=1M 和 LZ4；随机写性能高度依赖 SLOG（最好是 Optane 类带断电保护）。

10）我踩过的坑与现场解决过程

HBA 没刷 IT 模式：ZFS 看不到磁盘真实扇区与序列，ashift 误判，随机写抖动大。
解决：刷 IT 固件；统一按 ashift=12 创建池。

内核升级后重启直接黑屏：DKMS 没有及时编译 ZFS 模块。
解决：升级流程改为“新内核安装 → DKMS 编译成功 → 维护窗口重启”；必要时 apt-mark hold。

single special vdev：一块 NVMe 当 special，掉了导致全池导入失败。
解决：special 必须镜像；或者不用 special，仅用 L2ARC。

快照泛滥：脚本炸了，30 万个快照清理卡死。
解决：zfs destroy -nvr 先演练；分段批量清；后续加“按数据集限量 + 正则筛选”策略。

L2ARC 过大反而抖：ARC 太小，L2ARC 命中不稳。
解决：先给 ARC（内存）吃饱，再考虑 L2ARC；有持久 L2ARC 也要给学习时间。

NFS 默认参数瓶颈：客户端 rsize/wsize 太小。
解决：万兆下调到 1MB，server 侧 sync 视业务决定（有 SLOG 可保持 sync）。

TRIM 误解：有人给 HDD 开 TRIM 指标期待提升。
说明：HDD 基本无 TRIM 收益；autotrim=on 主要对 SSD/NVMe 有效。

ZFS send 堵在 SSH：长肥流在高延迟链路上波动大。
解决：mbuffer 双端对齐，合理设置 -m 和 -s，必要时在专线做限速。

勒索演练：生产挂载被加密，但异地只读副本完好。
演练：切只读副本做回切；源端从“干净快照”增量回灌。

11）收官：一个夜班工程师的“复盘”

凌晨四点，我把 zpool 的 resilver 进度盯到 98%，外面天色泛白。导演的素材回来了，DB 的延迟曲线也恢复在 5ms 以内。
这套基于 Debian 11 + ZFS 的方案，没有玄学：它靠 合理的池设计（RAIDZ2 + SLOG/L2ARC + special vdev）、分层的数据集参数、严格的快照/复制策略 和 可演练的恢复剧本，把“快照好看”变成“快照能救命”。
机房的空调仍旧嗡嗡作响，但我知道，下一次电话响起时，这几行命令、这张表格、这份流程，会再次替我们顶住一场风暴。

附：核心命令速查（可贴机柜门内侧）

# 安装
apt install zfs-dkms zfsutils-linux linux-headers-$(uname -r)

# 创建池（RAIDZ2 + SLOG(mirror) + L2ARC）
zpool create -o ashift=12 -o autotrim=on -O compression=lz4 -O atime=off -O xattr=sa -O acltype=posixacl \
  tank raidz2 disk1 ... disk10 log mirror slog1 slog2 cache l2arc1

# 数据集
zfs create -o recordsize=1M tank/media
zfs create -o recordsize=16K -o sync=standard -o logbias=latency tank/vm

# 快照管理
zfs snapshot -r tank/media@$(date +%Y%m%d-%H%M)
zfs list -t snapshot
zfs destroy tank/media@20240820-0300

# 复制
zfs send -R tank/media@A | mbuffer | ssh host "mbuffer | zfs receive -F tankdr/backup/media"
zfs send -RI A tank/media@B | mbuffer | ssh host "mbuffer | zfs receive -F tankdr/backup/media"

# 故障与修复
zpool status -xv
zpool offline tank diskX && zpool replace tank diskX diskNEW
zfs rollback -r tank/db@20240820-0300
zpool import -F -X tank

如果你也在香港的机房里值过夜班，你懂：真正让人睡得着的，不是 KPI，而是一次次演练后依然稳得住的恢复命令。祝你少接几个深夜电话。