どうすればいいの？
cp または rsync (-W --inplace を使用) を実行すると、93Gb で 2 時間かかります。専用バックアップ ネットワーク経由のテープ リストアは 41 分です。テープ リストアは 50 Mb/s です。ディスク間の測定と計算では、最高 16 Mb/s で、CPU がビジーの場合は 2 Mb/s でした。
復元ソフトウェアは Veritas NetBackup です。ディスクはファイバー経由の EMC Symmetrix アレイにあります。ボックスは HP-UX 11i v2 を実行する 16 Gb の HP rx6600 (Itanium) です。すべてのディスクは 1 枚のファイバー カード上にあり、次のようにリストされています。
HP AD194-60001 PCI/PCI-X Fibre Channel 2-port 4Gb FC/2-port 1000B-T Combo Adapter (FC Port 1)
ディスクはすべて、HP LVM ではなく Veritas Volume Manager を使用しています。
アップデート：これはない単なるディスクからディスクへのコピーですが、実際にはスナップショットディスク コピーに。スナップショットの読み取りによって、速度がそれほど低下しているのでしょうか? スナップショットは 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: を使用すると、速度の向上も説明できるかもしれません。
アップデート：スナップショットからの読み取りは、実際のデバイスからの読み取りのほぼ 2 倍の速度で実行されるようです。cp の実行は遅く、tar によるコマンド ラインへの書き込みも遅くなります。tar を使用すると (ファイルを使用する場合) 若干改善されますが、8Gb ファイルに制限されます (問題のファイルは 96Gb 程度です)。非スナップショット ボリュームで perl の File::Copy を使用するのが、最も高速な方法の 1 つと思われます。
試してみますので、結果をここで報告します。
答え1
もう1つの疑問は、FCネットワーク内でIOが制限されているかどうかです。SAN担当者に問い合わせてください。示す（グラフは良いです）実際の利用可能な予備帯域幅（ああ、FC スイッチが Cisco のものである場合、スイッチ内の帯域幅の問題をどのように回避しているか）
答え2
アレイ内の同じディスクからの読み取りと書き込みに制限がありますか?
答え3
テープも SAN 上にある場合、転送がテープからディスクに直接渡される一方で、コピーを実行するホストを経由するコピーが必要になる可能性があり、そのため速度が遅くなります。
答え4
ディスクがマザーボード上の異なるバスに接続されている場合、データは 3 つ以上の内部バスにコピーされる可能性があり、遅延によりディスク間のコピーの IO が停止します。この場合、ネットワーク テープ ドライブのターゲット ディスクへのパスの帯域幅が、ソース ディスクのパスの帯域幅よりも本質的に高い可能性があります。