- ベストアンサー
Debian lennyでディスク容量を圧迫して困っています
- Debian lennyでディスク容量が足りず困っています。2週間前にも同様の事例が起こり、バックアップしてあったファイルを削除したが、再び容量不足が起きました。
- 現在の使用率は97%であり、使用可スペースがわずかです。
- 原因と解決方法を知りたいので、どのように調査すれば良いか教えてほしい。
- tetsuya3261192
- お礼率75% (3/4)
- Linux系OS
- 回答数2
- ありがとう数13
- みんなの回答 （2）
- 専門家の回答
質問者が選んだベストアンサー
そういうことが起きやすいのは/varディレクトリー下ですね。 du -h --max-depth=1 /var という書式で、/var下の容量の多いディレクトリーがわかります。 (要root権限だっけ) とりあえず、不要のログを削除するのが一つの暫定手段でしょう。 こういった特定ディレクトリーの容量不足(パーティション計画ミス)の問題は 数十年前からあるものですから、当然ながらUNIX系OSでは効率的な対策が備わっています。 それが、mountによって、物理的に違うストレージを論理上のpathに割り当て アプリケーションレベルの設定変更無しに、ストレージ追加ができる仕組みです。 (UNIXより新しいOS Windowsではこのストレージ抽象化が盛んではありません) たとえば、10GBのルートパーティションなのに、/varが7GBも超えるような異常事態に /パーティションを変更すること無く…つまり、OSの起動が可能のままに 10GBの新規パーティションを作り、/varにマウントしてしまえば /varの浪費によるルートファイルシステムの容量不足を解消することができます。 これは顧客対応係を、業務拡大に伴い顧客対応課に昇格させるような運用です。 fdisk,mkfs,chown,chmod,mount,umountといったコマンドを理解する必要があります。 実際のHDD追加時には、cpやtarなどを適切に利用し 対象ディレクトリー内のファイル/ディレクトリーの権限設定を引き継ぐ必要があります。 クリティカルな状況では、サーバー停止を短時間に抑えるために ディレクトリー下のフルコピーと、サーバー停止後の更新分コピーの併用が必要でしょう。 そのほか、/etc/fstabの編集の必要もありますし 場合によっては、vol_idでパーティションのUUIDを確認する必要も生じます。 (追加HDDコントローラーの認識順変異などへ対応するためです) 一般的には別途用意した追加HDDでこういった対応を行ないますが 緊急時の応急処理として、/homeパーティションなどの 既存パーティションの一部を切り分けて/varに転用することもできますし (gpartdなどを使う必要があり、リスクはあります) 本当に困った時には、USBメモリーでどうにかなることもあります。 (ただ書き込みの遅いUSBメモリーはサーバー性能に大きく響く恐れがあります) まぁ、次にサーバーを止められる日には、ちゃんと対応しないといけないでしょうが USBメモリーでの応急処置なら、サーバーの停止時間はわずかなものです。 C:の拡大とアプリケーション環境の復旧などの一連の作業のために 専用のソフトを用意して、一日がかりの作業…という不便なOSに比べれば 合理的なストレージ管理と言えます。 もっとも、まず試してみるべきはapt-get cleanで 自動ダウンロードされたdebファイル群を削除するとかだと思います。 容量不足により、システムが正常起動できない際にも手早い。
その他の回答 (1)
- D-Matsu
- ベストアンサー率45% (1080/2394)
dfではファイルシステム単位でしか見ることができません。 ディレクトリ単位で見るにはduを使います。
お礼
duでディレクトリを確認し、logのせいだということがわかりました！ ありがとうございました！
お礼
duでディレクトリを確認し、logのせいだということがわかりました！ ありがとうございました！