VPSやサーバーを運用していると、「ディスク容量が100%になってサービスが止まった」「どのファイルが容量を食っているのか分からない」というトラブルに直面することがあります。
ディスクの空き容量を調べる 「df」 コマンドと、どのディレクトリやファイルが肥大化しているかを調べる 「du」 コマンドをマスターしておけば、容量不足トラブルも迅速に解決することができます。
この記事では、「df」 と 「du」 の基本的な使い方から、実務で使える調査コマンドを解説します。
ディスク全体の空き容量を確認する df
「df」（Disk Free）は、システム全体のディスク使用状況や空き容量を表示するコマンドです。
「-h」（human-readable）オプションを付けて実行すると、使用量や空き容量のサイズが人間が見やすい単位（MB, GB）で表示されて分かりやすくなります。
出力例
$ df -h Filesystem Size Used Avail Use% Mounted on tmpfs 789M 2.9M 787M 1% /run /dev/sda1 110G 96G 7.9G 93% / tmpfs 3.9G 842M 3.1G 22% /dev/shm tmpfs 5.0M 8.0K 5.0M 1% /run/lock tmpfs 789M 204K 789M 1% /run/user/1000 /dev/sdb1 234G 220G 15G 94% /media
出力項目の意味
- Filesystem: ファイルシステム名（デバイスやパーティションの名前）
- Size: ファイルシステムの総容量
- Used: 現在使用している容量
- Avail: 利用可能な空き容量（Available）
- Use%: ディスク使用率（全体の何％を使っているか）
- Mounted on: マウント位置（どのディレクトリに割り当てられているか）
見るべきポイント
ルートパーティション（/）のディスク使用率が100%（空き容量0）になると、OS全体のファイル書き込みや一時ファイルの生成ができなくなり、Webサーバーやデータベースの停止などシステム全体で深刻なトラブルが発生します。Use% が90%を超えている場合は早めの調査と対処が必要です。
容量はあるのに「No space left on device」？（inode枯渇）
ディスク容量が余っているのにファイルが作成できない場合、ファイル数の上限（inode）が枯渇している可能性があります。
「df -ih」 コマンドを実行して、IUse%（inode使用率）が100%になっていないか確認しましょう。
$ df -ih Filesystem Inodes IUsed IFree IUse% Mounted on tmpfs 987K 1.7K 985K 1% /run /dev/sda1 7.0M 1.2M 5.9M 17% / tmpfs 987K 983 986K 1% /dev/shm tmpfs 987K 6 987K 1% /run/lock tmpfs 198K 220 198K 1% /run/user/1000 /dev/sdb1 0 0 0 - /media
※「/dev/sdb1」はinodeを使用しないファイルシステムである「vfat」(FAT32)でフォーマットされているため、0 や -（ハイフン）と表示されます。
出力項目の意味
- Filesystem: ファイルシステム名（デバイスやパーティションの名前）
- Inodes: 作成可能なファイル・ディレクトリの最大総数（総inode数）
- IUsed: 現在使用しているinode数（作成済みファイル・ディレクトリ数）
- IFree: 利用可能な空きinode数（あと何個作成できるか）
- IUse%: inode使用率（ここが100%になると容量に空きがあってもファイルが作成できなくなります）
- Mounted on: マウント位置（どのディレクトリに割り当てられているか）
ディレクトリ・ファイルの容量を調べる du
「du」（Disk Usage）は、指定したディレクトリやファイルがどれだけのディスク容量を消費しているかを調べるコマンドです。
以下のオプションを使用することで、表示結果が格段に読みやすくなります。
- -s（summary）: サブディレクトリを1つずつ再帰的に出すのではなく、指定した対象の「合計値のみ」を表示
- -h（human-readable）: K, M, G のように分かりやすい単位で表示
出力例
# 現在のディレクトリ全体の合計サイズを確認 $ du -sh . 1.4M . # /var/log ディレクトリの合計サイズを確認 $ sudo du -sh /var/log 1.2G /var/log
実践！容量を食っている原因フォルダを特定するコマンド
ディスクが満杯になったときに、どのディレクトリが原因かを特定するための定番コマンドです。
サーバー全体のフォルダ容量を、容量が大きい順に並べて確認することができます。
$ sudo du -h --max-depth=1 / 2>/dev/null | sort -hr
指定した階層（深さ）までの容量を一覧表示する --max-depth（隠しフォルダも網羅）
- du -sh * と異なり、--max-depth=1 を使うと、指定した階層（深さ）までの容量を.cache や .local などの隠しディレクトリも含めて完全に集計できるため確実です。
- 「2>/dev/null」は、「/proc」「/run」など、権限がないファイル・フォルダへのアクセスエラー（標準エラー出力）をゴミ箱（/dev/null）に捨てることで、エラーメッセージを表示させずに結果だけをきれいに確認できるようにしています。
- sort -hr: 人間に読みやすい単位（G > M > K）で大きい順にソートします。
実行例：原因ディレクトリを階層ごとに掘り下げる
まずは 「du」 でルート（/）から1階層下までのディレクトリごとの容量を確認します。
今回は結果が見やすいように、末尾に head -n 5 をパイプで繋げて上位5件のみを表示しています。
$ sudo du -h --max-depth=1 / 2>/dev/null | sort -hr | head -n 5 341G / 220G /media 61G /home 26G /snap 13G /var
ルート直下で容量が大きいディレクトリが確認できたら、気になるディレクトリに対象を絞ってさらに1階層下を調査します。
今回はシステム領域である「/var」ディレクトリを確認してみます。
$ sudo du -h --max-depth=1 /var 2>/dev/null | sort -hr | head -n 5 13G /var 11G /var/lib 1.2G /var/log 240M /var/cache 50M /var/snap
/var 配下では /var/lib が大半の容量を占めていることが分かりましたので、続いて /var/lib の中身をさらに掘り下げてみます。
$ sudo du -h --max-depth=1 /var/lib 2>/dev/null | sort -hr | head -n 5 9.9G /var/lib/snapd 8.3G /var/lib/snapd/cache 1.3G /var/lib/snapd/snaps 358M /var/lib/snapd/seed 4.8M /var/lib/snapd/assertions
調査の結果、/var/lib/snapd/cache（Snapパッケージのダウンロードキャッシュ）が 8.3GB も消費していることが特定できました！
Snapのキャッシュデータは不要であれば削除しても問題ないためクリーンアップを行うことでディスクの空き容量を大幅に増やすことができます。
コメント