サーバーのディスク容量が満杯に近づいた表示を前に、何が容量を食っているか落ち着いて調べようとしている一人運用の保守担当者
障害対応・運用監視約10分

ディスク使用率100%を防ぐ｜ログローテーションと監視の基本

夜中にスマホが鳴る。サイトが見られないという連絡。 ログインして調べると、原因はコードでもアクセス急増でもなく——「ディスクがいっぱいで、もう何も書き込めない」。

そんな経験、ありませんか。 ディスク使用率100%は、保守運用の現場でいちばん起きやすいトラブルのひとつです。そして同時に、事前に防ぎやすいトラブルでもあります。じわじわ進むので、仕組みさえ整えておけば「満杯になる前に気づいて手を打つ」ことができます。

この記事では、なぜ満杯で止まるのか、何が容量を食っているかの調べ方、ログをため込まない設定、手遅れになる前に気づく監視を、一人運用の目線で整理します。全部を一度にやらなくて大丈夫です。

結論：ディスク満杯は「調べる・減らす・気づく」で防ぎます。①df と du で今の使用率と「何が重いか」を把握、②ログは logrotate で自動圧縮・削除、③100%前（例：85〜90%）に通知が来る監視を1つ。まずは「df -h を1回見る」ところから。

閾値や保存日数は用途次第です。ここを出発点に、環境に合わせて調整してください。コマンドはLinux系を前提にしています。

なぜディスク100%でシステムが止まるのか

ディスクが満杯になると、CPUやメモリに余裕があっても、多くのソフトが「書き込めること」を前提にしているため動けなくなります。

起きてからの復旧は重くなりがちです。だからこそ、満杯になる前に気づいて減らすのが現実的です。

まず調べる：何が容量を食っているか

ディスク使用率は df で確認し、容量を食っている場所は du でたどる、という調べ方の順番を示した図
まず df で全体の使用率を見て、次に du で「どこが重いか」を上からたどる

容量を減らす前に、「今どれくらい使っていて、何が重いのか」を知ります。順番はシンプルです。

① df で全体の使用率と枯渇の種類を見る

df -h
df -i

Use% が高い場所（/ か、/var か、/home か）を特定します。あわせて df -i で inode 枯渇も確認します。サイズに空きがあっても inode が尽きると新規作成ができません。inode が枯渇していたら、小さなファイルの整理や再配置を検討します。

② du で「重い場所」を上からたどる

満杯に近い場所が分かったら、その中で何が容量を食っているかをたどります。

du -xh -d 1 -x /var | sort -h

-d 1 は1階層だけ、-x は別ファイルシステムに降りない指定です。大きいものが下に来るので、いちばん重いディレクトリへ一段ずつ降りていきます。たいていは /var/log（ログ）や一時ファイル、バックアップ置き場が候補です。

③ 慌てて消さない（ここが大事）

重い場所が分かっても、いきなり rm は避けます。使用中のファイルを消すと、プロセスがつかんだままで容量が戻らないことがあります。削除済みだがプロセスが保持しているファイルは、次で探せます。

lsof +L1

該当プロセスを再起動すると解放されます。ログは「古いものだけ」を対象にし、今書き込み中のファイルは触らないのが基本です。

ログをため込まない：ログローテーションの基本

ディスク満杯の最頻原因は、ログがたまり続けることです。logrotate の設定で「いつ・何世代・どう圧縮して残すか」を決めます。押さえるのは次の4点＋α。

例（環境の既存ポリシーに合わせて調整してください）:

/var/log/myapp/*.log {
    daily
    rotate 14
    compress
    delaycompress
    missingok
    notifempty
    create
    # アプリが再オープンする場合は postrotate で通知
    # postrotate
    #     systemctl reload myapp.service || true
    # endscript
    # 再オープンできない場合だけ代替で copytruncate を検討
    # copytruncate
}

重要ポイント（現場での選び方）：

設定を変えたら、本番適用前に挙動をテストします。

また、systemd-journald が肥大化している場合は、まず使用量確認とクリーンアップを検討します。

journalctl --disk-usage
journalctl --vacuum-size=…  または  --vacuum-time=…

手遅れになる前に気づく：監視の入れ方

ローテーションしても、バックアップや一時ファイルの暴走で増えることはあります。だから「100%前に気づく監視」を最低1つ。

最小実装の例：cron で df を閾値判定してメール通知、または利用中クラウドのディスク使用率/ファイルシステム系メトリクスにしきい値アラームを設定。

閾値と通知運用の考え方は、監視アラートの鳴らしすぎを減らす記事も参考に。

具体例：よくある3つの「容量を食う犯人」

「とにかく消す」ではなく、「増え続ける原因を止めて、自動で減る」に寄せるのがコツです。

影響：仕組みを整えると、何が変わるか

放置すると、ある日突然「全部が書けない」障害に化けます。じわじわ進むぶん、気づく仕組みさえあれば防げます。

明日やること：まず df -h を1回見る

  1. サーバーで df -h と df -i を実行し、今の使用率と inode を見る。
  2. 満杯に近い場所があれば、du -xh -d 1 -x <その場所> | sort -h で重いディレクトリを一段だけ特定。
  3. いちばん重いものが「ログ」なら、/etc/logrotate.d/ を確認し、対象漏れや missingok/compress/delaycompress/create の要否を点検。
  4. 監視がなければ、「90%を超えたらメール1通」から始める。
  5. 削除で容量が戻らない時は lsof +L1 を確認し、該当プロセスを再起動。

この5分で「今うちのディスクは大丈夫か」が分かります。

コンテナ環境の注意点（ひとこと）

詳細は利用中の公式情報で確認してください。

ディスク満杯を防ぐチェックリスト

最低ライン（優先順位つき：これだけで回る） 1) 現状把握：df -h/df -i と du -xh -d 1 -x で重い場所を特定 2) ためない：アプリ独自ログを含め logrotate 対象化（missingok/compress/必要ならdelaycompress/create、アプリが再オープン可なら postrotate で通知、不可なら慎重に copytruncate） 3) 気づく：使用率90%でメール1通の簡易監視

余力が出たら拡張

免除条件（省略可）

確認項目

よければ、こちらも

ディスク監視は、障害を「起きてから」ではなく「起きる前」に止める備えのひとつです。鳴った後の段取りや原因にたどり着くログの見方も、あわせて型にしておくと落ち着けます。

ディスクに十分な空きがある表示を見て、満杯の心配から解放されて穏やかに安心している保守運用の担当者

ディスク満杯は、ある日いきなり全部を止めてしまう怖いトラブル。でも、じわじわ進むぶん、気づく仕組みさえあれば防げます。 今日は df -h を1回見るだけで十分です。その小さな確認が、「突然サイトが落ちる夜」を、静かに遠ざけてくれます。

ほかの実務ヒントは記事一覧からどうぞ。保守運用の小さな備えを、メールでも少しずつお届けしています。

関連用語