怎么会这样？
对于 93Gb，运行 cp 或 rsync（使用 -W --inplace）需要两个小时；通过专用备份网络进行磁带还原需要 41 分钟。磁带还原速度为 50 Mb/s；磁盘到磁盘的测量和计算结果最高为 16 Mb/s - 如果 CPU 繁忙，则为 2 Mb/s。
恢复软件是 Veritas NetBackup；磁盘位于光纤上的 EMC Symmetrix 阵列上。盒子是 HP rx6600 (Itanium)，16 Gb，运行 HP-UX 11i v2。所有磁盘都位于一张光纤卡上，如下所示：
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 和非快照卷似乎是最快的方法之一。
我将尝试一下并在此报告我的成果。
答案1
另一个问题是，您是否受到 FC 网络内部的 IO 限制，请咨询 SAN 人员证明（图表很好）实际的是否有备用带宽（哦，如果 FC 交换机是思科的，他们如何确保避免交换机内部的带宽问题）
答案2
您是否受到从阵列中的同一个磁盘进行读取和写入的限制？
答案3
如果您的磁带也在 SAN 上，那么传输可能会被交接并直接从磁带传输到磁盘，而副本则需要通过执行复制的主机，因此速度较慢。
答案4
如果磁盘连接到主板上的不同总线，数据可能会通过 3 条或更多内部总线进行复制，而延迟会扼杀磁盘到磁盘复制的 IO。在这种情况下，网络磁带驱动器到目标磁盘的带宽路径完全有可能比源磁盘更高。