怎么会这样？
对93Gb运行cp或rsync（带-W –inplace）需要两个小时; 通过专用备份networking的磁带恢复时间为41分钟。 磁带恢复是50 Mb / s; 磁盘到磁盘的测量和计算是16 Mb / s的顶端 – 如果CPU繁忙，则为2 Mb / s。
还原软件是Veritas NetBackup; 磁盘位于光纤上的EMC Symmetrixarrays上。 该机箱是一台运行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进行testing时，我使用1024k（或1048576或8192 * 128）的块大小。
我真的不知道这是块的大小。 我在PerlMonks上读过Perl模块File :: Copy比cp快; 这是有趣的：我想知道。
如果NetBackup正在使用tar，那么它不使用cp：这也可能解释速度增加。
更新：从快照读取的速度几乎是从实际设备读取速度的两倍。 运行cp很慢，写入命令行的tar也是如此。 使用tar稍微好一些（使用文件时），但限于8Gb的文件（有问题的文件是96Gb左右）。 使用perl的File :: Copy与非快照卷似乎是最快的方法之一。
我要去尝试一下，并在这里报告我所得到的。
另一个问题是，你是否在FCnetworking内部进行了IO绑定，要求SAN人员展示 （graphics是好的） 实际的备用带宽（哦，如果FC交换机是思科的，他们如何确保他们避免交换机内部的带宽问题）
你是否受限于读取和写入数组中的同一个磁盘？
如果您的磁带也位于SAN上，则可能是xfer正在从磁带直接转移到磁盘上，而拷贝需要通过执行拷贝的主机传递，因此速度较慢。
为了确保您的testing是类似的，请尝试通过tar执行磁盘复制（NetBackup使用tar从磁带读取）：
$ tar cf – oldstuff | （cd newdir; tar xf – ）
如果你的所有磁盘都在同一个光纤卡上，理论上你可以在这张卡上绑定IO，但是我怀疑它。
VxFS快照可能会增加开销，特别是当原始源文件系统正忙于写入时。 VxFS在写入时进行复制，因此如果原始磁盘正在接收写入，则快照磁盘将忙于接收原始磁盘数据。
如果原始文件系统空闲，则可以排除VxFS是一个因素。
如果磁盘连接到主板上的不同总线上，则数据可能会跨3个或更多内部总线复制，并且等待时间会导致磁盘到磁盘副本的IO损坏。 在这种情况下，networking磁带驱动器完全有可能比源磁盘具有更高的到目标磁盘的带宽path。