質問を始める前に、私はシステム管理者ではなく、助けを求めている素人であることを述べておきます。
私は Linux 3.10.0-514.26.2.el7.x86_64 と Amazon Web Services 外部バックアップ サービスを使用しています。これを機能させるには、サーバー上にバックアップ ディレクトリが必要です。このディレクトリには、外部バックアップ サービスによってすべてのファイルが圧縮され、コピーされ、そこからアクセスされます。
問題は、そのディレクトリに別のパーティションをマウントする必要があるかどうかです。バックアップには大量の HD 領域が必要になる場合があり、この目的のために別のパーティションを用意しておけば、理論上は、空きディスク領域が少ないという問題から日常的なサーバー操作や Web サイトを保護できるはずです。
しかし、それは正しいアプローチでしょうか? もっと良い方法はあるのでしょうか?
答え1
私は他の回答には敬意を表して反対しますが、適切なパーティショニングは Linux サーバーをさまざまな方法で維持するために不可欠であると言います (Windows については経験がないため、あまり言えません)。
私は常にバックアップ用に別のパーティションを使用していますが、これはスペースを適切に計画するだけでなく、回復プロセスにも非常に役立っています。以下に概要を説明します (携帯電話から入力しているため、書式が間違っていることをお許しください)。
パーティションを分離すると、容量を分離できるため、何かがそのパーティションの空き領域をすべて使い果たしても、システムの残りの部分に影響はありません。たとえば、/var/log について考えてみましょう。ユーザーが意図せず logrotate を壊し、ログがルートの 100% を使い果たしたサーバーを見たことがあります (または、たとえばトラフィックの急激な増加によって発生する可能性があります)。
AWS の場合、別のディスクに別のパーティションを作成すると、別のインスタンスにマウントして、そこにデータを復元できます (例: フォレンジック調査用)
(バックアップ関連に限ったことではありませんが) パーティションを分離すると、マウント時に noexec プロパティを設定して侵入の可能性を最小限に抑えることができます (実際には、実行ファイルが配置されているパーティションを除いて、システム上のほとんどのパーティションに対してこれを行う必要があります)
これは AWS システムだとおっしゃっているので、サーバーに別の EBS ディスクをマウントする代わりに、S3fs 拡張機能を利用して、S3 バケットをバックアップ用のパーティションとしてマウントすることをお勧めします。これの利点は、S3 上のデータの耐久性が非常に高いことです。
2つの点に注意してください。バックアップの実行が成功していることを常に監視する必要があり、定期的にデータの回復可能性をテストする必要があります（例えばGitlabで起こったことだ）
さらに、別の EBS ディスクを使用する場合は、LVM の使用は絶対に避けてください。1 - 複数のディスクにわたる LVM パーティションの断片化により、データが失われる可能性が高くなります (残念ながら、LVM はまだ作成者が期待するほど優れていません)。2 - AWS で EBS ディスクを拡張できるようになったため、LVM の断片化なしでスペースを追加できます。
答え2
いいえ。あなたの場合、パーティションは長期的には生活を困難にするだけです。将来起こりうる*障害の数が増えるだけです。
ディスク容量不足の問題に対する解決策は 2 つあります。
- モニタリング（即時対応）。
- キャパシティプランニング（長期的）。
これらを実装し、それからあなたはいくつかのとても神秘的アクティビティによってバックアップのサイズが突然急増する可能性があるため、パーティショニングを導入するという (不安定な) 議論が必要になります。
[*] システム管理者としてのあなたの第一の義務（あなたは実際そうなのです）は、ユーザーよりもはるかに悲観的になることです。