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