怎麼會這樣？
對於 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 交換器是 Cisco 交換機，他們如何確保避免交換器內部的頻寬問題）
答案2
您是否受到陣列中同一磁碟讀取和寫入的限制？
答案3
如果您的磁帶也在 SAN 上，則 xfer 可能會被移交並直接從磁帶傳輸到磁碟，而副本則需要透過執行複製的主機傳遞，因此速度較慢。
答案4
如果磁碟連接到主機板上的不同匯流排，則資料可能會跨 3 個或更多內部匯流排進行複製，並且延遲會消耗磁碟到磁碟複製的 IO。在這種情況下，網路磁帶驅動器完全有可能具有比來源磁碟更高的到目標磁碟的頻寬路徑。