
一部のシステムでは、ハードドライブ上のデータを毎日バックアップする必要があります。バックアップは、ハードドライブ ストレージに重要な負荷をかけます。バックアップ プロセスは数時間かかる場合があります。その間、システムはハードドライブ上で他の読み取り/書き込みアクティビティを実行できます。
質問は次のとおりです:
- 面倒なバックアップ手順により、並行して実行される読み取り/書き込みの他のハードドライブ操作が大幅に遅くなる可能性があるというのは正しいですか?
- p.1 の回答が「はい」の場合、バックアップには専用のストレージを使用することをお勧めしますか?
- p.2 の回答が「はい」の場合、バックアップ用に別の論理ストレージ (ハード ディスク上の 2 番目の論理ドライブ) を作成すれば十分でしょうか。それとも、別の物理ディスクのみで、バックアップ中のパフォーマンスの問題を防ぐことができますか。
- 専用の物理ドライブを使用する場合と、クラウド プラットフォームによって提供される仮想ストレージを使用する場合には、何か違いがありますか?
- 大量のログ書き込みアクティビティもハードドライブのパフォーマンス問題を引き起こす可能性があると思いますか? バックアップによって他の読み取り/書き込み操作が遅くなるかどうかを理解するのに役立つ経験的な推定値はありますか? たとえば、「システムが 50 MB を超える書き込みを必要とする場合、他のディスク プロセスが遅くなります」
答え1
はい。ハード ドライブはディスクを物理的に回転させる必要があるため、IOPS が非常に低くなります。バックアップをフル稼働させると、他のシステムの読み取り/書き込み速度が大幅に低下します。
これに対する答えは 1 つではありません。バックアップの速度を制限したり、データをミラーリングしてミラーからバックアップしたり、RAID を悪用したりすることもできます。また、すべてのバックアップ手順 (特に増分バックアップ) が書き込み量が多いわけではありません。
ディスクを論理的にパーティション分割しても問題は解決しません。問題はディスクの回転速度です。(「ショート ストローク」のおかげで多少の違いが出るエッジ ケースもありますが、この戦略を正当化するほどではありません)
微妙な違いはありませんが、実装方法によって大きな違いが生じる可能性があります。「クラウド」という言葉を「他の人のコンピューター」に置き換えると、それが明らかになります。実装によっては、違いがなくなる場合もあれば、ディスク IO を帯域幅と交換する場合もあります。当然、クラウド バックアップは書き込み時に送信され、段階的にバージョン管理されます。これは良い戦略です。
HDD へのログの書き込みは、書き込みと断片化の両方を引き起こし、ディスクのパフォーマンスに間違いなく悪影響を及ぼす可能性があります。