C：\はOS用、D：\はデータ用ですか？

「昔に」私たちは常にOSドライブ（Windows）をデータドライブから分離しました。Linuxの世界では、あまり慣れていませんが、知恵によって、ベストプラクティスの構成で定義および使用されるボリュームがさらに増えることがわかっています。

サーバーストレージがSAN（ディスクリソースが多くの個々のオペレーティングシステムとアプリケーションによって共有されている）上にある可能性が高いので、OSとデータパーティションをボリュームレベルで分離することは本当に重要ですか？

あなたの考えは何ですか？

OSとデータをストレージごとに分離するための3つの主要なドライバーがあります。

1. スペース。ErikAが指摘しているように、あなたは本当にあなたのOSボリュームがスペースを使い果たして欲しくないのです。あらゆる種類の悪いことが起こり得ます。これら2つの成長方法を分離する
2. I / Oアクセス要件。OSボリュームで使用されるI / Oのタイプは、通常、データボリュームで使用される種類とは大きく異なります。I / Oタイプを分離しておくことは、多くのレベルで非常に良いアイデアです。
3. ストレージポータビリティ。サーバーOSをアップグレードするときが来たら、OSボリュームを核にしてすべてのデータを保持できます。または、SANまたはVM環境では、データボリュームを新しくインストールしたばかりのサーバーに移動するだけで、アップグレードの時間を節約できます。

また、一部のオペレーティングシステム（Windowsもその1つです）は、OSボリュームのサイズ変更にあまり親切に対応していません。つまり、通常、サーバーをフォーマットするときに、その存続期間に必要なだけの量を与える必要があります。これを、サーバーの存続期間中に何度もサイズ変更できるデータボリュームと比較してください。OSとDatavvolumes自体が同じ実際のストレージに格納されている完全に仮想化された環境でも、OSボリュームのサイズを変更できないことは大きなハンディキャップになる可能性があります。Windows 2008+は現在、C：\ドライブに30 GBを推奨しています。これは、Server 2003で使用していた10 GBとはかなり異なります。これは、多くのWindows管理者が2003年から2008年に移行するときに失敗するものです。

はい、確かにOSとデータを分離しています。共有パーティションを使用すると、パーティションがいっぱいになり、OSにパッチを適用できなくなったり、（さまざまな理由により）パーティションを拡張できなくなったりすることが何度も何度もありました。

IMO、2つのパーティションを管理するオーバーヘッドは、提供された分離のために支払うための小さなコストです。

あなたが参照したSANベースのシステムに関しては、それでもOSパーティションがいっぱいになるデータから保護することはできません。完全に仮想化されたストレージを使用すると、OSとデータが別々のスピンドルに確実に存在するようにすることについてそれほど心配する必要はありません。

システムで何をしているのかによります。OSを再インストールする必要がある場合は、すべてのデータを別のパーティションに配置することで、手間を省くことができます。そうでなければ、私はもはや必要性を見ていない。私の2セント。

一般的な原則として、デフォルトのOSスペース（C：など）をデータ（D :)から分離することをお勧めしますが、ログファイル（L :)に小さなパーティションを作成して、少し維持することをお勧めしますより安全で、一部の種類のサービス拒否攻撃を防ぎます。

Linuxは、使用する物理ディスクや仮想パーティションの数に関係なく、ファイルシステムが1つのルートディレクトリの下に階層的に残るという点で非常に優れています。私は間違いなくディスクをパーティション分割しますが、データとOSの分離は必ずしも必要ではありません（とにかく2つが混同されることが非常に多いため）。

私は見てみます：

1. ディスクをいっぱいにし、他のディレクトリのスペースの問題を引き起こす可能性のあるサブディレクトリ（たとえば、/ homeと/ var / logのパーティション）。
2. パフォーマンス上の理由から、ディレクトリ構造のさまざまな部分にさまざまなファイルシステムが必要かどうか（つまり、安定性のためのXFS、万能使用のためのExt3など）
3. 将来的に拡張する必要がある可能性のあるディレクトリ-ディレクトリの名前を変更し、新しいディスクスペースのセットをディレクトリの場所にパーティション化してマウントし、データを古い場所から新しい場所にコピーできるため、これらはパーティション分割の適切な候補です。ロケーション。

歴史的なLinux（まあ、Unixは本当に）パーティション分割の推奨事項は、（ネットワーク化された）メインフレームサーバーOSとしての起源に一部起因します。たとえば、ログと一時データは通常、それらのストレージ領域に多くの摩耗があるため分離されていましたが、失われたとしてもそれほど問題にはなりませんでした。

デスクトップシステムを構築している場合は、データ/非データ/スワップの分割を行います。真剣な鎮静化を期待しているサーバーを構築しているのでなければ、/ usr / localや/ var / tmpのようなものはスペース割り当ての頭痛の種になるだけです。

私はそれがまだ素晴らしいと思います-あなたは100Gbのデータを持っています（あまりにも多くのpr0n男:)）そしてあなたはOSを再インストールする必要があります（または、Windowsの履歴に沿って、ビルドを削除するために定期的に再インストールしてください）それが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：\ドライブの単純な保護以上のものを取得していますが、発生する前に他の問題に対処するために、より完全なシステム監視を実施しています。