C：\はOS用、D：\はデータ用ですか？
「昔」私たちは常にOSドライブ（Windows）をデータドライブから分離していました。 Linuxの世界では、私はあまり詳しくありませんが、その知恵によって、ベストプラクティス構成で定義および使用されるボリュームがさらに増えることを認識しています。
サーバーストレージがSAN（ディスクリソースが多くの個々のオペレーティングシステムとアプリケーションによって共有されている）にある可能性が高いので、OSとデータパーティションが本当に重要になりますか？ボリュームレベルで分離されますか？
あなたの考えは何ですか？
OSとデータをストレージごとに分離しておくための3つの主要なドライバーがあります。
- スペース。 ErikAが指摘しているように、OSボリュームの容量が不足することは本当に望ましくありません。あらゆる種類の悪いことが起こる可能性があります。これら2つの成長方法を分離する
- I/Oアクセス要件。 OSボリュームで使用されるI/Oのタイプは、通常、データボリュームで使用されるタイプとは大きく異なります。 I/Oタイプを分離しておくことは、多くのレベルで非常に良い考えです。
- ストレージの移植性。サーバーOSをアップグレードするときは、OSボリュームを削除して、すべてのデータを保持できます。または、SANまたはVM環境では、データボリュームを新しくインストールしたサーバーに移動するだけで、アップグレードの時間を節約できます。
また、一部のオペレーティングシステム（Windowsなど）では、OSボリュームのサイズを変更するのにあまり親切ではありません。つまり、サーバーをフォーマットするときに、通常、存続期間中に必要なだけのボリュームを指定する必要があります。これを、サーバーの存続期間中に何度もサイズ変更できるデータボリュームと比較してください。 OSとDatavvolume自体が同じ実際のストレージに格納されている完全に仮想化された環境でも、OSボリュームのサイズを変更できないことは大きなハンディキャップになる可能性があります。 Windows 2008+は、最近C：\ドライブに30GBを推奨しています。これは、Server2003で使用していた10GBとはかけ離れています。これは、2003年から2008年に変換を行うときに、多くのWindows管理者を釘付けにするものです。
はい、間違いなくOSをデータから分離します。共有パーティションを使用すると、パーティションがいっぱいになり、OSにパッチを適用できなくなったり、（さまざまな理由で）パーティションを拡張できなくなったりすることが何度もあります。
IMO、2つのパーティションを管理するオーバーヘッドは、提供される分離の代償としてわずかです。
あなたが言及したSANでバックアップされたシステムに関しては、それでもOSパーティションをいっぱいにするデータからあなたを保護することはできません。完全に仮想化されたストレージを使用すると、OSとデータが別々のスピンドルに存在することを保証することについてそれほど心配する必要はありません。
一般的に、デフォルトのOSスペース（C :)をデータ（D :)から分離することは良い考えですが、ログファイル（L :)用に小さなパーティションを作成して少し保持することもお勧めしますより安全になり、一部の種類のサービス拒否攻撃を防ぎます。
Linuxは、使用する物理ディスクまたは仮想パーティションの数に関係なく、ファイルシステムが1つのルートディレクトリの下に階層的に保持されるという点で非常に優れています。私は間違いなくディスクをパーティション分割しますが、必ずしもデータとOSの分離のためではありません（とにかく2つが混同されることが非常に多いため）。
私は見るでしょう：
- どのサブディレクトリがディスクをいっぱいにし、他のディレクトリのスペースの問題を引き起こす可能性があります（つまり、/ homeおよび/ var/logからのパーティション分割）。
- ディレクトリ構造のさまざまな部分がパフォーマンス上の理由でさまざまなファイルシステムを必要とするかどうか（つまり、安定性のためのXFS、万能の使用のためのExt3など）
- 将来どのディレクトリを拡張する必要があるか-ディレクトリの名前を変更し、新しいディスクスペースのセットをディレクトリの場所にパーティション分割してマウントし、データを古いものから新しいものにコピーするだけでよいため、これらはパーティション化の候補として適しています。ロケーション。
歴史的なLinux（まあ、実際にはUnix）のパーティショニングの推奨事項は、（ネットワーク化された）メインフレームサーバーOSとしての起源に一部起因しており、ハードウェアの（当時の）相対的な信頼性の欠如に影響されたと思われます。たとえば、ログと一時データは通常、これらのストレージ領域が多くの消耗を伴うために分離されていましたが、それらが失われたとしてもそれほど問題にはなりませんでした。
デスクトップシステムを構築している場合は、データ/非データ/スワップの分割を行います。深刻な問題が発生することを期待しているサーバーを構築しているのでない限り、/ usr/localや/ var/tmpを分離することはスペース割り当ての頭痛の種になります。
それはあなたがシステムで何をしているかによると思います。 OSを再インストールする必要がある場合は、すべてのデータを別のパーティションに配置することで、面倒な作業を省くことができます。そうでなければ、私はもう必要性を見ていません。私の2セント。
それでもいいと思います-100Gbのデータがあり（pr0nの男が多すぎます:)）、OSを再インストールする必要があります（または、Windowsの履歴に従って、定期的に再インストールしてビルドアップを削除しますcruft）の場合、Cパーティションにある場合よりも、そのままにしておくのは非常に簡単です。
ただし、Windowsは特にCドライブのディレクトリにあらゆる種類のものを詰め込むのが好きなので、そこには問題があると思います-その「ユーザー」ディレクトリだけでなく、すべてのアプリデータとさまざまな断片がスタックしてしまいますProgramDataでも。
また、別の要因があります-本当に大きなもの（うん、そのpr0n）とは別に、継続的なバックアップを実行するオンラインバックアップツール（またはローカルバックアップユーティリティ）がたくさんあります。これらを考慮すると、バックアップの場所からデータを簡単に復元できるため、データを分離することはそれほど優先されません。
個人的には、データとOSを分割しようとしています。また、アプリを別のパーティションに配置して、OSのバックアップを大幅に小さくしようとしています。
私は別の考え方の悪魔の擁護者になります。
パフォーマンス上の理由から、ベンダーはOSパーティションを「スパース」にしないことを推奨しており、OSパーティション全体を事前に割り当てることを望んでいるとします。これにより、SANドライブに10Gbから20Gb（またはそれ以上）の未使用スペースが発生します。
これは単一のVMには問題ありませんが、それぞれが独自の10〜20Gbの空白オーバーヘッドを持つ複数の「パフォーマンスクリティカル」サーバーが存在する可能性があります。私たちの環境では、この空白がSANディスクの20％を占めています。SANディスクを埋めるには制限があることに注意してください（ただし、別の話です）。
経営陣には選択肢がありました
1）「ホワイトスペース」の他の要件に加えて、SAN上の20％の無駄なスペースを吸収し、発生する可能性のある「フルディスク」シナリオを分離します。
2）すべてをC：\ドライブに置き、アプリケーションログが原因でドライブがいっぱいになるリスクを冒します。
彼らは何をしましたか？
Windows 2008R2がホストOSのC：\ドライブを動的に拡張でき、フルになるとドライブを拡張できることを考えると、管理者はコストを「節約」し、SCOMなどの監視ツールに再投資しました。
現在、C：\ドライブの充填を単に保護するだけではありませんが、他の懸念に対処するために、より完全なシステム監視を実施しています。