ネットワークテープの復元は、ディスクからディスクへのコピーよりも高速です
どうすればいいの？
Cpまたはrsync（-W --inplaceを使用）の実行には、93Gbで2時間かかります。専用バックアップネットワークを介したテープの復元は41分です。テープの復元は50Mb/sです。ディスクからディスクへの測定と計算では、16 Mb/sの上限（CPUがビジーの場合は2 Mb/s）でした。
復元ソフトウェアはVeritasNetBackupです。ディスクは、ファイバー上のEMCSymmetrixアレイ上にあります。ボックスは、HP-UX 11iv2を実行する16GbのHPrx6600（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 VolumeManagerを使用しています。
更新：これはではなくディスクからディスクへの直接のコピーであることが私には思い浮かびます。実際には、ディスクコピーへのスナップショットです。スナップショットを読むと、物事がそれほど遅くなる可能性がありますか？スナップショットはHPVxFSスナップショットです（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倍遅いようです。コマンドラインへのtarの書き込みと同様に、cpの実行は低速です。 tarの使用は（ファイルを使用する場合）わずかに優れていますが、8Gbファイルに制限されています（問題のファイルは96Gb程度です）。スナップショット以外のボリュームでPerlのFile :: Copyを使用することは、最も速い方法の1つであるように思われます。
私はそれを試してみて、私が得たものをここに報告します。
もう1つの質問は、FCネットワーク内でIOバインドされているかどうか、SANみんなにデモンストレーション（グラフは良い） 実際使用可能な予備の帯域幅（ああ、FCスイッチがCiscoのものである場合、スイッチ内の帯域幅の問題を回避していることを確認する方法）
テープもSAN上にある場合は、xferがハンドオフされ、テープからディスクに直接移動している可能性がありますが、コピーを実行するホストを介してコピーを渡す必要があるため、速度が低下します。
アレイ内の同じディスクからの読み取りと書き込みによって制限されていますか？
テストが同じようになっていることを確認するには、tarを介してディスクコピーを実行してみてください（NetBackupはtarを使用してテープから読み取ります）。
$ tar cf --oldstuff | （cd newdir; tar xf-）
すべてのディスクが同じファイバーカード上にある場合、理論的にはその1枚のカードにIOバインドされる可能性がありますが、私はそれを疑っています。
VxFSスナップショットは、特に元のソースファイルシステムがその時点で書き込みでビジーである場合、オーバーヘッドを追加する可能性があります。 VxFSは書き込み時にコピーを行うため、元のディスクが書き込みを受信している場合、スナップショットディスクは元のディスクデータの受信でビジー状態になります。
元のファイルシステムがアイドル状態の場合は、VxFSが要因であることを除外できます。