在一次大规模 Proxmox VE → Proxmox Backup Server → 新节点恢复的过程中，多个虚拟机磁盘被从 PBS 还原为 qcow2 格式。通过分析 restore 日志，可以清楚地看到：影响恢复时间的关键并不是虚拟磁盘标称容量，而是其中“实际非零数据量”。
本文基于多台 VM（102 / 104 / 106 / 101）的真实恢复日志，分析了 restore 性能、零块跳过比例以及对 6TB 级虚拟机恢复时间的准确估计方式。
一、PBS restore 的关键机制：--skip-zero
所有恢复命令都使用了：
pbs-restore ... --format qcow2 --skip-zero
这意味着：
PBS 会识别磁盘中的“全零块”，直接跳过，不向目标磁盘写入。
因此：
- qcow2 显示的 6TB 只是虚拟容量
- 实际需要写入的是：
虚拟容量 − zeroes（零块）
这也是为什么 PBS restore 日志中会显示：
read xxxx bytes, zeroes = yy% (zzzz bytes)
zeroes 百分比越高，真正要写的数据越少，速度越快。
二、不同 VM 的真实恢复速度
从几台 VM 的 restore 完成日志可直接看到最终速度：
| VM | 容量 | 耗时 | 平均速度 |
|---|---|---|---|
| VM102 | 12 GB | 55.6 s | 221 MB/s |
| VM106 | 32 GB | 363 s | 90 MB/s |
| VM104 (scsi0) | 100 GB | 780 s | 131 MB/s |
| VM104 (scsi1) | 100 GB | 105 s | 968 MB/s |
可以看到：
- 磁盘内容不同（零块比例不同）
- 存储目标不同
- qcow2 写入压力不同
都会导致恢复速度差异非常大。
三、为什么同样 100GB，一个 130MB/s，一个 968MB/s？
VM104 的两块磁盘表现完全不同：
| 磁盘 | zeroes | 实际写入 |
|---|---|---|
| scsi0 | ~1–2% | ≈ 98GB |
| scsi1 | ~87% | ≈ 13GB |
也就是说：
- scsi1 虽然“虚拟 100GB”
- 但真正写入只有约 13GB
→ 所以速度看起来接近 1GB/s
这证明：
PBS restore 的瓶颈是 “非零数据写入量”，不是 qcow2 文件尺寸。
四、6TB 虚拟机（VM101）的真实情况
VM101 的 qcow2 虚拟容量为：
6597069766656 bytes ≈ 6.0 TB
但根据实际数据：
有效数据 ≈ 4.5 TB
这正是 PBS --skip-zero 的典型场景。
五、4.5TB 在当前系统中的恢复时间估算
根据实际多台 VM 的 restore 表现：
如果性能接近 VM102（≈220MB/s）
4.5 TB ÷ 220 MB/s ≈ 5.7 小时
如果性能接近 VM104(scsi0)（≈130MB/s）
4.5 TB ÷ 130 MB/s ≈ 9.5 小时
因此：
VM101 的实际恢复时间区间约为
6 小时（理想）到 10 小时（偏慢）
而 zeroes 比例如果高于预期，还会更快。
六、如何在恢复中实时判断“还有多久”
在 PBS restore 日志中，每一行都包含：
progress X% (read Y bytes, zeroes = Z% (K bytes), duration T sec)
真正要写的量是：
有效数据 = Y - zeroes
因此剩余时间可以用：
剩余数据 ÷ (当前有效写入速率)
来计算，非常精确。
七、结论
在 Proxmox Backup Server 的恢复机制下：
虚拟机恢复时间 ≠ 虚拟磁盘容量
恢复时间 ≈ 非零数据量 ÷ 实际写入速度
对于 6TB 级虚拟机：
- 如果其中 25% 是零块
- 实际恢复量就是 4.5TB
- 恢复时间大约 6–10 小时，而不是 15–20 小时
这也是 PBS 在大规模迁移和跨国数据搬迁中的核心优势之一：
稀疏数据越多，恢复越快。