OS

Linuxでディスク容量がいっぱいになったときの調査方法｜df・duで原因を特定する

Linuxサーバーでディスク容量不足が発生したときに、dfで満杯のファイルシステムを確認し、duで容量を消費しているディレクトリやファイルを絞り込む手順を解説します。

この記事でわかること

  • dfでファイルシステム単位の使用率と空き容量を確認する。
  • duで容量を多く使っているディレクトリを段階的に絞り込む。
  • 削除やログ整理の前に、対象ファイルの用途と影響を確認する。
  • dfとduの数値が合わない場合は、マウントポイントや削除済み・使用中ファイルも確認する。

容量不足が起きたときに最初に確認すること

アプリケーションの停止、ログ出力の失敗、バックアップエラーなど、容量不足によって発生している症状を確認します。いきなりファイルを削除せず、対象サーバー、実行ユーザー、調査対象のマウントポイントを整理してください。基本の流れは、ファイルシステム全体を確認する→対象マウントポイントを特定する→大きなディレクトリを絞り込む→原因を確認して対処する、です。

dfはファイルシステム単位、duは指定したパス配下の使用量を確認するコマンドです。役割を分けて使うと、調査対象を効率よく絞り込めます。

dfで容量が不足しているファイルシステムを特定する

まずはdf -hを実行し、ファイルシステム名、全容量、使用量、空き容量、使用率、マウント先を確認します。-hは容量を読みやすい単位で表示する指定です。GNU Coreutilsではdfがファイルシステムの使用量と空き容量を表示します。

BASH
df -h
# 出力例（説明用。実環境の結果ではありません）
# Filesystem      Size  Used Avail Use% Mounted on
# /dev/sda2        40G   38G  2.0G  95% /
# /dev/sda3       100G   52G   48G  53% /home
# /dev/sdb1       200G  190G   10G  95% /var
確認対象分かること次に行う調査
dfファイルシステム全体の使用率・空き容量使用率の高いマウントポイントを特定する
du指定パス配下のディレクトリ・ファイルの使用量容量の大きい場所を掘り下げる
dfとduの使い分け

例では / と /var の使用率が高いため、次にそれぞれを調査します。df -Tを使うとファイルシステム種別も確認できます。NFSなどのリモートファイルシステムが含まれる環境では、ローカルディスクだけとは限らないため、種別とマウント先を確認してください。

duで容量を消費しているディレクトリを絞り込む

対象のマウントポイントが分かったら、du -shで候補ディレクトリの合計使用量を確認します。-sは合計、-hは読みやすい単位での表示です。duは指定したパス配下の使用量を推定するため、権限不足があると一部を確認できない場合があります。

BASH
du -sh /var /home /opt 2>/dev/null
# 出力例（説明用。実環境の結果ではありません）
#  18G  /var
#  6.2G /home
#  1.4G /opt

# /var配下を大きい順に確認する例
sudo du -xhd1 /var 2>/dev/null | sort -h
# 出力例
#  1.1G /var/cache
#  2.8G /var/lib
#   14G /var/log
#   18G /var

この例では /var/log が大きいため、du -sh /var/log/* のようにさらに対象を絞ります。-xは別のファイルシステムをまたがない指定ですが、利用できるオプションや表示形式は実装によって異なるため、実行環境のmanページも確認してください。

大きなファイルと容量不足の原因を確認する

大きなディレクトリを特定したら、ログ、キャッシュ、バックアップ、一時ファイル、アプリケーションデータのどれに該当するかを確認します。ファイル単位で探す場合は、対象パスと検索範囲を限定します。

BASH
sudo find /var/log -xdev -type f -size +500M -printf '%s %pn' 2>/dev/null | sort -n
# 出力例（説明用。実環境の結果ではありません）
# 734003200 /var/log/example/app.log
# 2147483648 /var/log/example/access.log
原因候補確認すること
ログローテーション、保存期間、圧縮、出力設定、現在使用中か
キャッシュ再生成可能か、削除によるアプリケーション影響がないか
バックアップ保管要件、世代数、別ストレージへの移動可否
一時ファイル作成元のプロセス、古いファイルか、削除してよいか
アプリケーションデータデータベースやアップロード領域の運用・バックアップ状況
原因候補と確認方法

ログは単純な削除ではなく、ローテーションや圧縮、保存期間の見直しが適切な場合があります。削除、圧縮、サービス再起動を行う前に、対象ファイルが使用中でないか、監査・バックアップ要件がないか、復旧に必要なデータではないかを確認してください。

dfとduの結果が合わない場合の確認ポイント

dfはファイルシステムが確保している領域を、duは指定パスから参照できるファイルを集計するため、数値が一致しないことがあります。まず、duが別のマウントポイントをまたいでいないか、調査対象のパスが正しいかを確認します。

ディレクトリを調べても原因が見つからない場合は、削除済みでもプロセスが開いたままのファイルを確認します。Linuxでは、プロセスが保持するファイルディスクリプターを /proc//fd から確認できます。ファイルの最後の参照が閉じられるまで、削除済みファイルの領域が解放されない場合があります。

BASH
sudo sh -c "ls -l /proc/[0-9]*/fd/* 2>/dev/null" | grep '(deleted)'
# 出力例（説明用。実環境の結果ではありません）
# ... /proc/1234/fd/5 -> /var/log/example/app.log (deleted)

該当プロセスが分かっても、直ちにkillや再起動を実行しないでください。サービスの影響範囲と運用手順を確認し、必要に応じてログの再オープンや計画的な再起動を行います。対処後はdfを再実行し、使用率と空き容量が改善したか、サービスとログ出力が正常に戻ったかを確認します。

参考