1.1 硬件前提#

• 外置备份盘 sdg 容量 ≥ 原池已用量 × 1.2 先查原池实际占用：

  1
  zpool list ssd
  2
  # NAME   SIZE   ALLOC   FREE    ...
  3
  #                 ↑ 这一列就是已用量

  如果 ALLOC 是 800G，备份盘至少需要 1T（留 20% 余量，避免 ZFS 在 95% 以上性能骤降）。

• 原池所有 VM / LXC 镜像要能一起装下：用同一块备份盘，不要分散到多个盘。

1.2 PVE 架构前提#

本文流程针对的是数据池（比如名为 ssd 的 ZFS 池，挂载在 PVE 之外存放 VM 镜像）。

不要对 PVE 系统根池 rpool 使用本流程

如果你的 PVE 本身就是以 root-on-ZFS 的方式安装（PVE 安装时选了 ZFS 选项），那么 rpool 是系统根池。本文流程不适用于 rpool——重建 rpool 涉及 bootloader、initramfs、UEFI 条目等复杂操作，走本文步骤会让系统无法启动。

先确认一下：

1
zpool list
2
# 看是否有 rpool 以及它是不是本文要操作的池
3
mount | grep 'on / '
4
# 看根文件系统是否来自 ZFS

本文针对的是非根的数据池，比如 ssd 这种专门放 VM 镜像的池。

1.3 关键事实（建池后不可改）#

• ashift 值一旦建池就锁死，以后不能改。选错了就是永久性的性能问题（见第 4.2 节原理）。
• zpool create -f 一执行，原盘上的 ZFS label 立即被覆盖，原池再也 import 不回来。
• PVE 的 VM 配置文件 /etc/pve/qemu-server/*.conf 不在 ZFS 池上（它们在 pmxcfs 的 SQLite 里），所以销毁 ssd 池不会直接丢配置。但 VM 磁盘镜像（ZVOL）在 ssd 池里，没备份就丢了。

4.1 查外置盘的 by-id 路径#

为什么用 by-id 而不是 sdg：Linux 的设备名（sdb、sdg 等）在重启后可能变动（跟 BIOS 扫盘顺序、热插拔顺序有关）。用 by-id 路径的是磁盘序列号，永久稳定。

1
ls -l /dev/disk/by-id/ | grep sdg
2
# 找到类似：
3
# ata-WDC_WD10EZEX-08WN4A0_WD-WCC6Y5XXXXXX -> ../../sdg

记下完整的 ID 串（本例 ata-WDC_WD10EZEX-08WN4A0_WD-WCC6Y5XXXXXX）。

4.2 ashift=12 是什么，为什么必须加#

ashift 告诉 ZFS 磁盘的物理扇区大小是 2^ashift 字节：

现代硬盘几乎全是 4K 物理扇区（Advanced Format / 512e / 4Kn），如果用 ashift=9（默认），ZFS 以为扇区是 512B，每次写其实要触发磁盘内部的”读-修改-写”一个 4K 扇区，性能直接砍到一半以下。

ashift 一旦建池就锁死，不能改。所以宁可大不可小：现代硬盘建议至少 ashift=12；NVMe SSD 条件允许给 ashift=13。

1
# 建临时备份池（单盘，不做冗余，只用来中转）
2
zpool create -o ashift=12 temp_backup \
3
  /dev/disk/by-id/ata-WDC_WD10EZEX-08WN4A0_WD-WCC6Y5XXXXXX
4

5
# 确认
6
zpool status
7
zfs list

5.1 为什么必须先 snapshot#

zfs send 只能发送 snapshot，不能直接发送活跃的数据集或 ZVOL。原因：活跃数据集一直在变，没有”时间点”概念，接收端不知道该停在哪里。

Snapshot 是某一时刻整个数据集的只读时间切片，ZFS send 基于它才能生成确定性的数据流。

1
# 递归对整个 ssd 池打一个 snapshot，名字统一好识别
2
zfs snapshot -r ssd@migrate-2026-04-22
3

4
# 查看确认所有 dataset/ZVOL 都有这个 snapshot
5
zfs list -t snapshot -r ssd

-r 表示递归——ssd 池下所有 dataset / ZVOL 都打上同名 snapshot（ssd@migrate-2026-04-22、ssd/vm-100-disk-0@migrate-2026-04-22 等）。

5.2 传输到备份池#

1
# 先在备份池里建个容纳目录
2
zfs create temp_backup/ssd_backup
3

4
# 逐个 ZVOL 发送（基于刚才打的 snapshot）
5
zfs send -w -L ssd/vm-100-disk-0@migrate-2026-04-22 | \
6
  zfs receive -F temp_backup/ssd_backup/vm-100-disk-0
7

8
zfs send -w -L ssd/vm-101-disk-0@migrate-2026-04-22 | \
9
  zfs receive -F temp_backup/ssd_backup/vm-101-disk-0
10

11
zfs send -w -L ssd/vm-101-disk-1@migrate-2026-04-22 | \
12
  zfs receive -F temp_backup/ssd_backup/vm-101-disk-1
13

14
zfs send -w -L ssd/vm-102-disk-0@migrate-2026-04-22 | \
15
  zfs receive -F temp_backup/ssd_backup/vm-102-disk-0
16

17
zfs send -w -L ssd/vm-102-disk-1@migrate-2026-04-22 | \
18
  zfs receive -F temp_backup/ssd_backup/vm-102-disk-1

zfs send 参数说明

• -w (--raw)：按磁盘原样发送。如果数据集启用了压缩 / 加密 / 去重，raw 模式不解压不解密，直接发送压缩/加密后的块。传输最快、占用最小
• -L (--large-block)：允许发送 >128K 的 record size。接收端池必须启用 large_blocks feature（OpenZFS 默认已开）
• -R (--replicate)：递归复制整棵树（含子 dataset、snapshot、properties），常用于整池迁移
• -i (--incremental)：只发增量（见 5.3 节）

zfs receive -F 的 -F 是”强制覆盖接收端同名数据集”。接收端名字如果已存在但不是你想要的，-F 会把它抹掉——确认无误再用。

5.3 进阶：用增量 send 降低停机窗口#

上面的流程需要 VM 全程停机 → 全量传输完成才能启动。大数据量时可能停机好几个小时。

增量 send 的思路：VM 继续运行时先做一次全量，停机后只发增量。

1
# 第 1 步：VM 运行中（不停机），先做一次全量快照 + 全量 send
2
zfs snapshot -r ssd@full-before-stop
3
zfs send -R -w -L ssd@full-before-stop | zfs receive -F temp_backup/ssd_backup
4

5
# 第 2 步：这时才停机（见第 3 节）
6

7
# 第 3 步：停机后再打一次快照
8
zfs snapshot -r ssd@final-stopped
9

10
# 第 4 步：只发从 full-before-stop 到 final-stopped 的增量
11
zfs send -R -w -L -i @full-before-stop ssd@final-stopped | \
12
  zfs receive -F temp_backup/ssd_backup

这样 VM 实际停机时间 = 增量传输时间（通常几分钟），远少于全量传输时间（几十分钟到几小时）。

6.1 空间对比#

1
# 源池和备份池并排看 used
2
zfs list -r -o name,used,written ssd
3
zfs list -r -o name,used,written temp_backup

对应 dataset 的 used 应当接近（raw send 下可以精确匹配；非 raw 由于压缩差异可能略有出入，但数量级必须一致）。

6.2 snapshot 完整性#

1
# 备份池里应该能看到全部迁移用的 snapshot
2
zfs list -t snapshot -r temp_backup | grep migrate-2026-04-22

6.3 端到端启动测试（最可靠）#

最硬核的校验是：在备份池上启动一台 VM，确认系统能正常跑。

1
# 举例：把 VM 100 临时指向备份池的 ZVOL
2
# 用 /root/pve-config-backup/100.conf 里的配置修改磁盘指向 temp_backup/ssd_backup/vm-100-disk-0
3
# 启动测试
4
qm start 100
5
# 进 VM 里确认系统、应用正常
6
# 确认无误后关机再改回来
7
qm stop 100

如果不想动配置，至少用 zfs clone 克隆一份出来挂载读取：

1
zfs clone temp_backup/ssd_backup/vm-100-disk-0@migrate-2026-04-22 \
2
  temp_backup/ssd_backup/vm-100-disk-0-clone
3

4
# 映射为块设备（如果是 ZVOL）
5
ls -l /dev/zvol/temp_backup/ssd_backup/vm-100-disk-0-clone
6

7
# 或用 kpartx / parted 进一步挂载 partition

7.1 先人工核对磁盘 ID#

1
# 把所有要参与重建的盘的 by-id 路径打出来
2
ls -l /dev/disk/by-id/ | grep -E 'sd[b-e]$'

把输出复制保存，核对每个 ID 都是原池里的，sdg 的 ID 绝对不在其中。

临时备份池 temp_backup 务必先导出

重建 ssd 池之前，把 temp_backup 先 export 掉（但不销毁），避免手误把 sdg 写进下一步命令：

1
zpool export temp_backup

7.2 导出原池（可回滚的最后一步）#

1
zpool export ssd

如果这一步之后反悔，还能 zpool import ssd 恢复。下一步 zpool create -f 才是真正的不可逆点。

7.3 重建为 RAIDZ1（先不加 -f 试运行）#

1
# 先不加 -f 试探，让 ZFS 自己报盘上有残留 label
2
zpool create -o ashift=12 ssd raidz1 \
3
  /dev/disk/by-id/你的-sdb-设备ID \
4
  /dev/disk/by-id/你的-sdc-设备ID \
5
  /dev/disk/by-id/你的-sdd-设备ID \
6
  /dev/disk/by-id/你的-sde-设备ID

期望输出：会报类似 invalid vdev specification: use '-f' to override 的错，提示磁盘上有旧池 label。这个报错是保护性的——让你确认盘没选错。

确认 4 块盘 ID 没错、没夹带 sdg 之后，加 -f 正式执行：

1
zpool create -f -o ashift=12 ssd raidz1 \
2
  /dev/disk/by-id/你的-sdb-设备ID \
3
  /dev/disk/by-id/你的-sdc-设备ID \
4
  /dev/disk/by-id/你的-sdd-设备ID \
5
  /dev/disk/by-id/你的-sde-设备ID
6

7
zpool status ssd

zpool status 应该显示 state: ONLINE 且 vdev 是 raidz1-0。