Linuxのディスク使用量を調べて肥大の原因を突き止める運用点検｜du/df【2026年版】

ディスク肥大が静かに進む理由

「気づいたら / パーティションが残り数 GB」という状況は、長期稼働のサーバーではよくある運用上の問題です。原因としてとくに多いのは、ログの無制限な蓄積・バックアップファイルのローテーション漏れ・コンテナランタイムのキャッシュ・systemd-journald のジャーナル肥大の4パターンです。いずれも単発の作業ではなく、運用フローの隙間から徐々に拡大するため、気づいたときにはすでに空き容量が危機的になっていることがあります。

本記事では「アラートが鳴った」「df で残り10%を切った」といった実際のトリガー状況を想定し、df による全体把握 → du による原因箇所の絞り込み → 対処 → 検証という一連の調査フローを整理します。コマンドのオプション一覧ではなく、現場で使える調査の流れを主軸に置きます。

df でパーティション全体の状態を把握する

調査の出発点は df です。どのマウントポイントが逼迫しているかを最初に確認します。

df -hT

-h で人間が読みやすい単位（GB/MB）に変換し、-T でファイルシステムの種類を合わせて表示します。出力の「Use%」列が80%を超えているマウントポイントが調査対象です。

ここで確認しておきたいのは、tmpfs や overlay 行です。前者は Docker や systemd が生成する一時ファイルシステム、後者はコンテナのレイヤーです。これらを実ディスクの枯渇と誤認しないよう、-T でタイプを見て実体デバイスを特定します。デバイスとパーティション構成を俯瞰したい場合は lsblk を併用すると分かりやすくなります。

du で肥大箇所を段階的に絞り込む

df で「/var が問題」と分かったら、次は du でどのサブディレクトリが原因かを階層的に掘り下げます。全ディレクトリを一度に展開すると出力が膨大になるため、--max-depth を使って1階層ずつ確認するのが実務上の定石です。

du -ah --max-depth=1 /var | sort -rh | head -20

-a はファイルも含めて表示、-h は人間が読みやすい単位、sort -rh で降順にソートし、head -20 で上位20件に絞ります。これで /var 直下の大きな要素が一目で並びます。

上位に /var/log が来た場合はさらに掘り下げます。

du -ah --max-depth=1 /var/log | sort -rh | head -20

特定のログファイルまで絞り込めたら、そのファイルを削除する前に必ず中身を確認します。現在も書き込み中のファイルを削除すると、プロセスがファイルディスクリプタを保持している間は実際のディスク領域が解放されない問題が発生します。lsof | grep deleted でこの状態を検出できます。

ファイルシステム全体で100MB以上の大きなファイルを横断的に探したい場合は find を組み合わせます。

find / -xdev -size +100M -type f 2>/dev/null | sort

-xdev は他のマウントポイントをまたがないオプションで、調査対象を現在のファイルシステムに限定します。tmpfs や別パーティションの大きなファイルを混入させないために重要です。

典型的な肥大原因と対処

systemd-journald のジャーナル肥大

2026年時点で多くのディストリビューションが採用している systemd 環境では、/var/log/journal/ がバイナリ形式でログを蓄積します。デフォルト設定では上限なく増加するケースがあり、/var 肥大の大きな原因になります。

journalctl --disk-usage

これで現在のジャーナル使用量を確認できます。500MB を超えているようであれば、次のコマンドで安全にトリムできます。

journalctl --vacuum-size=500M

恒久的な上限を設けるには /etc/systemd/journald.conf の SystemMaxUse= を設定します。再起動後も有効なため、こちらを本来の対処として施しておくのが望ましい運用です。

コンテナランタイムのキャッシュ

Docker や Podman を稼働させているホストでは、使われなくなったイメージ・停止中のコンテナ・未使用ボリュームが積み重なります。

docker system df

イメージやキャッシュの内訳が確認できます。不要なものを一括削除する場合は docker system prune -a が使えますが、実行中のコンテナが参照しているリソースには影響しないものの、停止中のコンテナも含めて削除されるため、本番環境では対象を絞って実行する方が安全です。

ローテーションされていないアプリケーションログ

独自アプリケーションや古いミドルウェアは logrotate の管理外のログを出し続けることがあります。/etc/logrotate.d/ 配下に対象ファイルのエントリが存在するか確認し、なければ追加します。また、logrotate が正しく動作しているか logrotate -d /etc/logrotate.conf でドライランを行い、設定の不備を事前に検出できます。

誤削除を防ぐための確認と切り戻し準備

調査後に削除・トリムを行う前に、以下の点を確認します。

• 削除対象ファイルにアクセスしているプロセスがないか（lsof <ファイルパス>）
• ログファイルであればサービスの再起動やシグナル送信でローテーションが可能か
• バックアップ用ファイルであれば保持ポリシーを確認してから削除するか
• 削除前にファイルのサイズとタイムスタンプを記録しておく

削除後は df -h で空き容量が期待通り回復しているかを確認します。大きなファイルを削除したにもかかわらず容量が減らない場合は、前述の「プロセスがファイルをオープンし続けている」状態を疑います。lsof | grep deleted で確認し、該当プロセスを再起動することで領域が解放されます。

ファイルシステムに Btrfs や ZFS を使用している環境では、スナップショットが実ディスクを大量消費することがあります。btrfs subvolume list / や zfs list -t snapshot で不要なスナップショットを確認するステップも調査フローに組み込みます。

2026年の現行環境での注意点

2026年時点で広く普及している Ubuntu 24.04 LTS・RHEL 9系・Debian 12 を前提にした場合、従来の調査フローといくつか異なる点があります。

まず、du のブロックサイズ表示はカーネルのブロックサイズ（通常4KB）が基準であり、Btrfs などの圧縮ファイルシステムでは --apparent-size オプションを付けないと実際のファイルサイズと乖離が出る場合があります。圧縮が有効な環境では du --apparent-size -sh <対象> で論理サイズを確認する習慣が有効です。

次に、ncdu（NCurses Disk Usage）の活用です。apt や dnf でインストール可能なこのツールは、du の調査をインタラクティブなTUIで行えるもので、階層をキーボードで掘り下げながらリアルタイムに確認できます。SSH 接続先での調査に特に便利です。

また、/proc や /sys、/dev は仮想ファイルシステムであり実ディスクを消費しませんが、du -sh /* を実行すると時間を取られたりエラーが大量に出たりします。最初から du -ah --max-depth=1 /var のように対象パスを絞って実行するのが実務的です。

さらに、systemd-resolved や snapd（Ubuntu 環境）も独自のキャッシュ領域を持ちます。/var/cache/snapd/ や /var/lib/snapd/ が思いのほか大きくなっている場合は、snap list --all で古いリビジョンを確認し snap remove --revision で整理できます。

定期的なディスク使用量の監視には、df を cron や systemd timer で定期実行してアラート用スクリプトに渡す方法が引き続き有効ですが、Prometheus + node_exporter を導入している環境では node_filesystem_avail_bytes メトリクスをアラートルールに組み込む方が確実です。観測の仕組みと対処の手順をセットで整備しておくことで、次回の肥大時に初動を早めることができます。