Windowsサーバーに複数のパーティションがあるのはなぜですか？
私のIT服には、ちっぽけなCドライブ/パーティション（10GB）とより大きなDドライブ/パーティションを備えたサーバーを展開するためのテンプレートがあります。なぜこれをするのですか？ Windows（少なくとも最近まで、そして最小限）は、一般的なサーバー展開で動的マウントポイントを実際に使用していません。
編集
したがって、概要の下にコメントの多くがあります。
- 小さいパーティションを回復する方が高速です。これには、NTFSの破損が含まれます。これは、システム全体を台無しにするのではなく、特定のパーティションに保持されます。
- 暴走プロセスからある程度の保護が得られます。これには、クォータを設定する機能が含まれます。
- RAID構成のコストをいくらか節約できます
- 仮想化、レイド、および高帯域幅ネットワークの前の時代からの宗教的なホールドオーバー。
＃3（これはパーティションに対する議論だと思います）を除いて、私はまだ別々のパーティションを持つ理由がわかりません。データを保護したい場合は、データを別の実ディスクまたは仮想ディスクのセットに配置するか、他の場所（NAS、SANなど）の共有リソースにマップしませんか？
データがオペレーティングシステムのボリュームをいっぱいにし、サーバーをクラッシュさせるのを防ぐため。
クォータを使用する場合、ファイルサーバーは通常ボリュームごとに設定されるため、個別のボリュームの恩恵を受けます。 （たとえば、ユーザーのホームディレクトリを1つのボリュームに配置し、プロファイルを別のボリュームに配置し、会社のデータを別のボリュームに配置します。）
p.s. 10Gbは、システムボリュームに対して小さすぎるように聞こえます。数年に及ぶWindowsの更新とサービスパックの後、すぐにいっぱいになります。
プログラム/データファイルをOSのインストールから分離すると、バックアップからの復元が容易になります。 OSパーティションには少なくとも25GBを割り当てたいのですが、ポイントは同じです。
通常、パーティションを作成する利点はありません。
アプリケーション（Microsoftなど）は、宛先ディレクトリを選択できる場合でも、％SystemDrive％にスペースを要求することで有名です。 Windows Updateの自動更新サービスでパッチを適用したファイルのバックアップを保存しないように選択できないため、％SystemRoot％の下の "$ ninstall $"ディレクトリのサイズが大きくなります。人為的に制約された％SystemDrive％を使用することは、私にとっては単なる仕事の補佐です。
私は通常、共有ディレクトリとデータを単一のルートレベルのサブディレクトリの下に置きます。これは、アプリケーションとデータを分離しておくという私のニーズを満たしています。
とはいえ、一般的にこれは「宗教的」な問題であり、私はそれについて人々と議論しません。サーバーでやりたいことをしてください。 「データ」パーティションがないことは私に役立ちました。
（今、別々の物理ボリューム/スピンドルを持っています...それは別の話です。）
これを行う理由の一部は、ドライブがいっぱいになるような暴走プロセスがある場合、ディスクの容量が不足してもWindowsが地面に衝突しないためです。
これを行う2つ目の理由は、OSとデータパーティションに異なるサイズのドライブ/異なるRAIDレベルを許可するためです。たとえば、（ここでは数値を丸めて薄い空気から引き出しています）2x100GB SAS OSミラーパーティション用のドライブ、次に6x700GB SAS RAID 10データパーティション用のドライブ。これを行うと、1日の終わりにシステムのコストを簡単に1000ドル節約できます。
3番目の理由は実際には非常に単純です。DellCDでサーバーを構築した人は誰も注意を払っていませんでした。デフォルトでは、10 GBのOSドライブが作成されます（新しいリリースでは20）。
今エヴァンが言ったように、これは本当に「宗教的」信念に接する個人的な好みです。正直なところ、今日のドライブのサイズでは、どちらの方法でも正常に機能します。自分が慣れていること、または企業の基準で定められていることを実行します。
仮想化の考えは興味深いトピックをもたらします。 Evanが指摘したように、私が言わなければならなかったことのほとんどは、さまざまなRAIDコンテナについて話していました。ただし、VMWare環境には、20GBの基本テンプレートがあります。ここで興味深い部分がここに来て、私のサーバーはすべてSANでホストされており、2つのボリュームが提示されています。
テンプレートの一部である20GBドライブと
可変データサイズシステムの要件に従って接続するデータドライブ。
90％の時間、これら2つのディスクは同じRAIDセット上にありますが、マシンへの2つの異なる「物理」ドライブです。いつものように、仮想化は「標準的な」IT思考プロセスに曖昧さの層をもたらします。
あなたの質問に対する正確な答えはありませんが、ドライブ/パーティションのセットアップを設計するのに役立つと思われるいくつかの逸話があります。
（1）破損したNTFS
OSとデータ用の2つのパーティションを持つサーバーがありました。何年にもわたるある時点で、データパーティションに問題が発生し、約6レベルの深さでネストされた単一のファイルを削除または名前変更できなくなりました。結局、唯一の解決策は、パーティションをワイプしてデータを再ロードすることでした。明らかに、パーティションがなければはるかに苦痛だったでしょう。
（2）完全なデータパーティション
上記と同じサーバーは、その寿命の別の時点で、OSパーティションで数十GBが使用可能であったにもかかわらず、完全に完全なデータパーティションで終わることに成功しました。一時的な対策として、ジャンクションポイントを使用して、新しいサーバーが到着するまでOSパーティションにデータを一時的に保存しました。醜いですが、うまくいきました。パーティションを回避することは、醜い修正を回避することを意味します。
（3）Server 2008 UAC
新しいサーバーで、ローカル管理者またはドメイン管理者でない限り、C：ドライブ以外のドライブの管理に問題がある可能性があることを発見しました。 Administratorsグループに属しているだけでは十分ではありません。これは、私が今のところ無効にしているUACの奇妙さによるものです。
（4）ボリュームシャドウコピー
シャドウコピー（別名以前のバージョン）は、パーティションごとにオン/オフを切り替えます。特定のデータセットの以前のバージョンを格納するスペースを無駄にしたくない場合は、パーティションが最適です。
私が好む行動方針は、オペレーティングシステム専用に個別のRAID 1アレイを用意して、OSとデータを完全に分離することです。これにより、柔軟性が大幅に向上します。たとえば、OSのインストールをまったく変更せずに、データストレージに使用されるすべてのハードドライブをアップグレードできます。
OS専用のC：ドライブを使用して、サーバー上の複数のパーティションを使用します。主にデータベース、ユーザーファイル/フォルダー、共有ファイル/フォルダーなどのデータの保存に使用するその他のパーティション。
もちろんサービスにもよりますが、それには価値があります。他の場所でほのめかされているように、パーティションが異なれば、下にあるストレージの特性も異なります。そのため、異なるドライブ文字は、パーティションではなく、異なる下層drivesを表す必要があります。むかしむかし、スワップファイルを独自のパーティションに配置することは賢明な方法でしたが、それはかつてほど有益ではありません。それ以外の場合は、他の場所への移動を拒否するOSおよび使いにくいアプリケーション用のC：ドライブと、他の場所への再配置可能なアプリを保持してください。
仮想化を使用すると、C：ドライブをファイルバックアップストレージにすることができますが、D：、E：、F：などのドライブを実際にはブロックレベルのストレージのNPIV直接プレゼンテーションにすることができます。または、OSドライブをミラーリングされたディスクのペア（72GBまたは144GBにすることができます）にし、OS以外のドライブをRAID10セットにするか、まったく別のものにすることもできます。
私の経験では、最も重要な点は不良ブロックとスキャンディスクです。10TBのボリュームが不良ブロックを取得し、特に重要なサーバーでスキャンディスクが必要になるのを見たくない場合があります。 ！）ユーザーが最初にファイルを要求し、次にITスタッフを非難し、最後にあなたに向かって叫んでいる間、終了するまでの時間。
パーティションがある場合、不良ブロックは小さなドライブ（少なくとも、サーバーの動作を妨げるブロック）にあり、ユーザーがあなたに向かって叫ばないように、十分な速度でスキャンおよび修正されます（なぜなら、それに直面しましょう。それでもIT関連の責任はあります）。
ショートストロークについての言及は見られなかったので、ここに追加します。
機械式ドライブのボリューム/パーティションが小さいほど、アクセス時間/待ち時間が短縮されます。これにより、場合によってはパフォーマンスが著しく向上する可能性があります。
10GBのブートパーティションは小さすぎるようですが、今日では25〜80GBのボリュームの方が快適に見えます。実際のサイズに関係なく、いくつかの理由でドライブをフル容量にフォーマットしません。その理由のほとんどはパフォーマンスの問題に戻ります。
同じ物理ドライブ上のDパーティションが、めったに使用されないデータまたは緊急使用のみを目的としたものである場合でも、C：はショートストローク効果の恩恵を受けます。そこにある鍵は、他の人がそのスペースをプライマリストレージであるかのように使用しないようにすることです。二次パーティションを定期的に使用すると、この利点が無駄になります。
また、小さなパーティションを使用すると、新しいドライブが到着するまでアレイを劣化させたままにする必要がなく、劣化したRAID 1のスペアとして36GBまたは73GBのスペアドライブを使用できる場合があります。小さい方のSSDを使用して、そのオプションのサイズを変更していない場合は、小さいパーティションを引き継ぐこともできます。
アップグレード/リカバリ
OSのアップグレードまたはリカバリを実行する場合、オペレーティングシステムが専用ボリュームにあると、はるかに簡単でクリーンになります。仮想環境では、データ「.VHD」を新しいサーバーにコピーするだけで、サービスを復元/アップグレードできます。
ボリュームシャドウコピーサービス
この機能は、ボリュームごとにのみオン/オフにできます。このテクノロジーは、使用可能な空き領域に基づいて復元ポイントを割り当てることで機能するため、別のボリューム専用にするのが最も効率的です。使用可能な空き容量が多いほど、復元を実行できる容量が増えます。 OSドライブは、インストールされた更新プログラムや一時的なプログラムファイルなどのためにスペースを消費します。これの以前のバージョンを割り当てることは、復元ポイントが短くなることを意味し、テクノロジの適切な使用法ではありません。
圧縮vs EFS
ボリュームで使用できるのはこれらのテクノロジーの1つだけなので、専用ボリュームを使用すると競合を防止できます。
管理
これは、OSボリューム上のネストされたサブフォルダーとは対照的に、別のボリュームに移動する方がはるかに簡単であるため、技術的な理由よりも優先されます。
ネストされたサブフォルダーよりもボリュームごとにこれを管理する方が簡単なので、アクセス許可の適用についても同じことが言えます。
OSボリューム-0空き容量
これは私にはかなり前から起こっていませんが、起こったとき、非常に奇妙なことが起こりました。ユーザーがOSボリュームのコンテンツの変更を許可されている場合（ファイル共有を介して、大きなファイルをデータベースにアップロードするなど）、サービス拒否シナリオが発生します。これがOSが存在する場所以外のボリュームで発生すると、解決はmuchより簡単になります。
Windows IISサーバーを実行している場合、ディレクトリトラバーサルを防ぐために、ホストされているWebサイトファイルを配置した場所からOSドライブを分離しました。
これは主にWindows 2000の問題でした。
システムパーティションが小さい場合は、そのパーティションで診断と修復を実行するのにかかる時間が短縮されるため、ダウンタイムが短縮されます。たとえば、予期しないディスクまたはファイルシステムの問題があり、2 TBシステムとデータの組み合わせパーティション）でchkdskを実行するために再起動する必要がある場合、サーバーは明日までオンラインに戻らない可能性があります。このパーティションはわずか20 GBなので、30分未満でバックアップを実行でき、パーティションをバックアップしたりイメージ化したりする時間も短縮できます。
とはいえ、サービスパックや修正プログラムを使用すると、その領域がすぐに消費されるため、前述の10 GBの制限は驚くほど小さいようです。 20〜30GBの方が適しています。
ファイルの断片化も忘れないでください。サーバーのデータドライブは、通常、ログファイルでいっぱいになり、データベースが常に拡張されます。システムパーティションにも、Windowsの更新と内部ログに関する同じ問題があります。ただし、システムパーティションの断片化の問題は、システム全体を停止させます。データドライブの同じ問題は、アプリケーションのパフォーマンスにのみ影響します。
ドライブパーティションテーブルの問題もあり、小さなポイントですが、テーブルが大きくなると、特に大量のファイルがある場合に、インデックスを作成して検索する速度が遅くなります。