怎么会这样？
对于 93Gb，运行 cp 或 rsync（使用 -W --inplace）需要两个小时；通过专用备份网络进行磁带恢复需要 41 分钟。磁带恢复为 50 Mb/s；磁盘到磁盘被测量并计算为最高 16 Mb/s - 如果 CPU 繁忙，则为 2 Mb/s。
还原软件是 Veritas NetBackup；磁盘位于光纤上的 EMC Symmetrix 阵列上。该盒子是一个运行 HP-UX 11i v2 的 16 Gb 的 HP rx6600 (Itanium)。所有磁盘都在一张光纤卡上，如下所示：
HP AD194-60001 PCI/PCI-X Fibre Channel 2-port 4Gb FC/2-port 1000B-T Combo Adapter (FC Port 1)
这些磁盘也都使用 Veritas Volume Manager（而不是 HP LVM）。
更新：我突然想到这不仅仅是一个直接的磁盘到磁盘复制；实际上，它是磁盘副本的快照。读取快照会减慢速度吗？快照是 HP VxFS 快照（不是 vxsnap）；也许快照和 VxVM 之间的交互导致速度下降？
更新：使用 fstyp -v，块大小（f_bsize）似乎是 8192；默认的 UNIX 块大小为 512（或 8192/16）。使用 dd 进行测试时，我使用了 1024k（或 1048576，或 8192*128）的块大小。
我真的想知道它是否是块大小。我在 PerlMonks 上读到 Perl 模块 File::Copy 比 cp 快；这很有趣：我想知道。
如果 NetBackup 使用 tar，那么它没有使用 cp: 这也可以解释速度的提高。
更新：似乎从快照读取几乎是从实际设备读取的两倍。运行 cp 很慢，就像 tar 写入命令行一样。使用 tar 稍微好一点（使用文件时），但仅限于 8Gb 文件（有问题的文件是 96Gb 左右）。将 perl 的 File::Copy 与非快照卷一起使用似乎是最快的方法之一。
我将尝试这样做，并将在这里报告我得到的结果。
另一个问题是您是否在 FC 网络中绑定了 IO，请 SAN 人员演示（图表很好）实际可用的备用带宽（哦，如果 FC 交换机是 Cisco 交换机，他们如何确保避免交换机内部的带宽问题）
您是否受到阵列中同一个磁盘的读取和写入的限制？
如果您的磁带也在 SAN 上，那么 xfer 可能会被移交并直接从磁带传输到磁盘，而副本需要通过执行复制的主机传递，因此速度较慢。
为确保您的测试完全一致，请尝试通过 tar 进行磁盘复制（NetBackup 使用 tar 从磁带读取）：
$ tar cf - oldstuff | (cd newdir; 焦油 xf -)
如果你所有的磁盘都在同一张光纤卡上，理论上你可以在一张卡上绑定 IO，但我对此表示怀疑。
VxFS 快照可能会增加开销，尤其是在原始源文件系统当时正忙于写入的情况下。VxFS 确实在写入时复制，因此如果原始磁盘正在接收写入，快照磁盘将忙于接收原始磁盘数据。
如果原始文件系统空闲，则可以排除 VxFS 是一个因素。
如果磁盘连接到主板上的不同总线，则数据可能会通过 3 个或更多内部总线进行复制，并且延迟会扼杀磁盘到磁盘复制的 IO。在这种情况下，与源磁盘相比，网络磁带驱动器完全有可能具有到目标磁盘的固有更高带宽路径。