どのくらいの頻度でサーバーをデフラグする必要がありますか？
数台のサーバーがあり、それらは2年間最適化されていません。断片化を解消する前に断片化する割合の基準はありますか？
サーバーはWindows 2003です。
実際、サーバー上のデータを最適化することはありません。私は、デフラグにかかる時間のパフォーマンスヒットに見合うだけのファイルサービスのパフォーマンス向上を十分に見ていません。実際、ほとんどのサーバーは、数日間オフラインにしない限り、実際に最適化を完了することはありません。比較的新しいファイルシステムを使用している場合（Windows 2003でデフォルトを変更することを選択した場合を除き）、それはそれほど重要ではありません。また、ストライプRAIDを実行している場合、ファイルはすでに多くのディスクに分割されているため、ファイルの断片化は問題になりません。
何らかの理由で本当にデータをクリーンでデフラグしたいサーバーがある場合、すべてをテープにバックアップし、ドライブをワイプして復元します。それはそれらをすべて完璧なブロックに書き留めます。
Windowsサーバーを最適化するために知っている唯一のユースケースは、バックアップのパフォーマンスを改善することです。バックアップは、ファイルサーバーが実行する大規模なシーケンシャルI/Oのほんのわずかであり、それが断片化に気づく一種のI/Oです。ユーザーがヒットしたときにI/Oファイルサーバーが行う種類は非常にランダムであり、その場合は断片化によってパフォーマンスが向上することがあります。
以前の仕事では、新しいハードウェアに移行したばかりのファイルサーバーがありました。移行直後、バックアップは450MB /分程度で実行されていました（これは何年も前のことです）。 2年後、そのサーバーは約300MB /分をバックアップしていました。次に、これを初めてデフラグしたところ、速度は450MB /分に再び上昇しました。
すべてのバックアップを予定どおりに実行することに問題があり、ボトルネックとなっているのがバックアップされているサーバーであると思われる場合は、デフラグmayが役立ちます。
デフラグのもう1つの使用例は、アーカイブがNTFSに保存されているディスクへのバックアップシステムです。この種のボリュームのバックアップと復元は完全にシーケンシャルであり、断片化に気づきます。ただし、基になるストレージが十分に抽象化されている場合（HP EVAディスクアレイなど）、この種のI/Oでも断片化に気付くことはありません。
つまり、大量シーケンシャルI/Oは、断片化に最も気づくタイプのI/Oです。それが問題のI/Oでない場合、デフラグは問題になりません。
パフォーマンスがあなたの目標であるなら、あなたはしばしばする必要がなく、そうするべきではないことを私は同意するでしょう（一定のデフラグがより多くの害を及ぼし、良いことをします）。
他のルールと同様に、いくつかの例外があります。
ある場合、またはディスク容量が非常に少ない場合（空き容量が15％未満）は、時間があるときにデフラグを実行する必要があります。選択するセクターが非常に少ないと、最新のファイルシステムでも断片化を回避するのに問題があります。
不可避な断片化を引き起こす特定のタイプのアプリケーションを実行している場合は、サーバー固有の最適化プログラムに投資することをお勧めします（これらはバックグラウンドで継続的に実行され、必要に応じて最適化するように設計されています）。 Windows環境で不可避の断片化を引き起こすアプリケーションのタイプは、複数のファイルにわたって大量の遅延書き込みを行うアプリケーションです（最も堅牢なサーバー設計のソフトウェアはこれを回避しますが、デスクトップダウンロードマネージャーのようなもの、特に一部の特定のBitTorrentクライアント）この種の積極的な断片化行動）
以前のジョブではサーバーでDiskeeperを実行したため、ファイルサーバーとアプリケーションサーバーの両方で測定可能なパフォーマンスが向上しました。私たちは彼らの公表された統計に近づいたとは思いませんが、確かにいくつかの利点を見ました。
これは、アイドル時にデフラグするように設定されており、起動時に起動されたいくつかの追加ビットによる影響を制限するために設定されたスケジュールにあります。
コンセンサス（私が同意する）は、サーバー上でデフラグを実行するものではないようです。これは、実際のデフラグ中にパフォーマンスが低下するメリットはないためです。
ただし、TechNetの article は、物理から仮想への変換の実行に関して、P2Vを実行するために必要な時間を短縮する方法として、最適化を推奨しています。これは、P2Vを完了するための限られたメンテナンスウィンドウがある場合に特に重要です。
イメージングフェーズに必要な時間を最小限に抑えるには、ソースコンピュータのハードドライブでディスクの最適化を実行します。また、ソースコンピュータとホストの間に高速ネットワーク接続があることを確認してください。
注目すべきツールの1つは、IOBitによるSmart Defragです。コンピュータがアイドル状態のときにバックグラウンドでデフラグし、ディープオプティマイズやその他の機能を備えています。便利そうに見えるので、そこに置いてもデフラグの心配はありません。
AFAIK、RAIDは断片化の影響を受けません。物理ディスクの数にもかかわらず、FSは依然として各フラグメントに対して個別のI/O要求を発行する必要がありますよね？
ええ、うまくデフラグされたシステムは、バックアップをより速く完了します。また、低いスペースと断片化は適切な組み合わせではないことにも同意します...そのような状況を回避するのに最適です。
デフラグの時間/スケジュールが問題になる場合は、Diskeeper Serverエディションの1つ（無料ではない！）のようなバックグラウンドデフラグソリューションが適しています。アイドル状態のリソースのみを使用してデフラグを実行するため、運用サーバーにも影響はありません。ここのサーバーの一部はDKを使用しており、管理者はDKにかなり満足しているようです。
ところで、一部のBTクライアント（uTorrentが頭に浮かびます）にはtorrentの事前割り当てオプションがあるため、ファイルを収容するのに十分な連続した空き領域がある限り、ダウンロード中に断片化はありません。