マウントに失敗したときにルートシステムがいっぱいになるのを防ぐ最良の方法は？

内部Webサーバー（仮想化され、ReviewBoardをホストしますが、あまり関係ありません）があり、NFSマウントの失敗により/がいっぱいになる比較的一貫した障害モードがあります。DistroはUbuntuです（尋ねないでください）。ソリューションが別のディストリビューションに依存している場合、実装が遅くなります。

バックアップは/ mnt / backup /に実行されていますが、これは別のシステムへのNFSマウントが想定されています。残念ながら、マウントが失敗またはドロップすると、ルートファイルシステムでバックアップが実行されます。これは、想像できるように/がいっぱいになるまで時間がかからず、サービスが失敗し始めます。

多くの可能な解決策が議論されています。

1. / mnt / backupsを監視し、rootでないことを確認してください。おそらくcronジョブ。

2. / mnt / protected / backupsを使用し、最初に/ protectedを小さなファイルシステムにマウントします。おそらくローカルファイルへのループマウントなので、失敗する可能性ははるかに低くなります。

3. Chmod a-rwx / mnt / backups（ルートファイルシステムマウントポイント）。保護された監督の上にマウントすることがうまくいくかどうかはわかりませんが、そうだと思います。

4. マウントされたツリーで、「Backups」というディレクトリを作成してから、「ln-s / mnt / backup / Backups / Backups」というソフトリンクを作成します。ローカルツリーにはサブディレクトリが含まれていないため、/ mnt / backupがマウントされていない限り、バックアップに/ Backupsを使用すると失敗します。

5. バックアップスクリプトでディレクトリが正しくマウントされていることを確認します。

これらのアプローチ、賛否両論、またはこの種の厄介さからルートファイルシステムを保護する標準的な方法として人々が使用するその他のテクニックに関するフィードバックに興味があります。

番号5-続行する前に、バックアップスクリプトにテストを入れて、ディレクトリがマウントされていることを確認します。マウントが利用できないか存在しない場合、スクリプトは失敗します。または、バックアップを実行する前に物事がマウントされていることを確認できます。

mountpoint指定されたディレクトリがマウントポイントかどうかを確認するコマンドを試してください：

mountpoint -q /mnt/backups || mount /mnt/backups

最もエラーが発生しないソリューションは、マウントポイントを書き込み不可にすることです。これがソリューション＃3です。ただし、実行する必要がある追加の手順が1つあります。chattr +i /mnt/backups。これは、アクセス許可がなくても、rootがディレクトリに書き込むことができるためです。chattr +i（セット不変フラグ）もないルートは、それに書き込むことができます。マウントがマウントされると、権限はローカルディレクトリではなくリモートディレクトリの権限になるため、権限は重要ではありません。

ewwhiteが言ったこと。また、基本システムの正常性を監視するための追加の監視も悪い考えではありません。

Monitのようなものは、どれだけのスペースが残っているかを確認できます。システムモニタリングを徹底的に行いたい場合は、Nagiosを見ることができますが、Monitは軽量であり、基本を実行します。

Ubuntuを使用しているため、Monitはすでにレポジトリにあるため、「sudo apt-get install monit」を実行し、構成ファイルを確認して、適切な場所にアラートを送信し、適切なサービスを監視するよう指示します。ここに簡単なチュートリアルがあります。

以下は、cronジョブとして実行できる1つのライナーです。問題のマウントがfstabにあると想定しています。

if mountpoint -q /mnt ; then : ; else mount /mnt ; fi

長期的なソリューション：Ubuntuでこれを行う方法（私はRH中心です）またはそれが価値があるかどうか（マシンが1つだけの場合）ボリューム、ファイルシステム、サーバーマシン上のボリュームグループです。したがって、標準的な慣行の問題として、/、/ tmpのLVM論理ボリュームを作成します。/ usr、/ usr / local、/ opt、/ home、/ var、スワップ領域、および/ boot用の個別のパーティション。このアプローチにより、ファイルシステムがシステムをいっぱいにして無効にするのがさらに難しくなります。実際、このアプローチは/ファイルシステムをいっぱいにすることをほとんど不可能にします。もちろん、/ tmp、/ varを監視する必要があります。データを格納する必要がある場合は、データ用にまったく異なるボリュームグループを作成します。このアプローチには他の利点もあり、ファイルシステムを自由に拡張し、それらを移動し、新しいものを作成するなど。