Linuxディスク容量不足の調査方法｜dfとduの実践的な使い方
※本記事にはプロモーション（広告）を含みます。
ディスク容量不足に気づいたら、まずdf -hでパーティション単位の使用率を確認し、次にduで肥大化しているディレクトリを絞り込むという二段階の調査が最短ルートです。闇雲にファイルを消す前に、この順序で原因箇所を特定すれば、誤って必要なデータを削除するリスクを避けられます。本記事ではdfとduの実践的な使い分けと、削除しても容量が戻らない場合の対処まで、コマンド例を交えて解説します。
- ディスク容量不足の初動確認
- duコマンドで肥大化箇所を特定する
- 容量を圧迫しやすい典型パターン
- 削除しても容量が戻らない場合
- 再発を防ぐ運用の組み方
- よくある質問
- まとめ
ディスク容量不足の初動確認
サーバーの動作が急に重くなったり、アプリケーションのログに「No space left on device」と出力されたりした場合、最初にやるべきことは全パーティションの使用率把握です。感覚で「/varが怪しい」と当たりを付けて調査を始めると、実際には別のマウントポイントが原因だったというケースも珍しくありません。
dfコマンドの基本操作
df -hを実行すると、マウントされている各ファイルシステムのサイズ・使用量・空き容量・使用率がGB/MB単位（-hはhuman-readableの意味）で一覧表示されます。
$ df -h Filesystem Size Used Avail Use% Mounted on /dev/sda1 50G 47G 1.2G 98% / /dev/sdb1 200G 180G 10G 95% /var tmpfs 3.9G 0 3.9G 0% /dev/shm
この出力で98%や95%といった数値が見えたら、そのマウントポイント配下を重点的に調べる対象として絞り込めます。逆にUse%が低いパーティションを長時間調べても時間の無駄になるため、まずここで対象を絞ることが調査時間の短縮につながります。
inode不足という別の落とし穴
容量に余裕があるのに「No space left on device」が出る場合、inode（ファイル管理用の管理領域）の枯渇を疑ってください。df -iを実行すると、IUsed（使用中のinode数）とIFree（空きinode数）が確認できます。小さなファイルを大量生成するアプリケーション（セッションファイルやキャッシュファイルなど）を運用していると、容量ではなくinode数が先に上限へ到達することがあります。
$ df -i /var Filesystem Inodes IUsed IFree IUse% Mounted on /dev/sdb1 13107200 13107198 2 100%
IUse%が100%近い場合は、容量削減よりも先に小さいファイルを大量に生成しているプロセス（メールキュー、セッションストア、tmpディレクトリの一時ファイルなど）を特定する必要があります。
duコマンドで肥大化箇所を特定する
dfで問題のあるマウントポイントが分かったら、次はduでディレクトリ単位の容量を掘り下げます。duは指定したディレクトリ配下のファイルサイズを再帰的に合計するコマンドで、対象範囲を絞りながら深掘りしていくのが基本の使い方です。
階層を絞って絞り込む
du -h --max-depth=1 /varのように--max-depthオプションを付けると、指定した階層までの合計サイズだけを表示できます。/var直下のようにファイル数が多いディレクトリでいきなり全階層を再帰的に調べると出力が大量になり、目視での確認が難しくなるため、depth=1から始めて怪しいディレクトリだけ深掘りしていく方法が効率的です。
$ du -h --max-depth=1 /var 4.2G /var/lib 120G /var/log 8.5G /var/cache 1.1G /var/spool 133G /var
この例では/var/logが120GBと突出しているため、次はdu -h --max-depth=1 /var/logを実行し、さらに配下のどのログファイル・ディレクトリが肥大化しているかを特定します。
サイズ順に並べ替えて確認する
ディレクトリ内のファイル数が多い場合は、duの出力をsortと組み合わせるとサイズの大きい順に一覧化できます。
$ du -ah /var/log | sort -rh | head -n 10
このコマンドは/var/log配下の全ファイル・ディレクトリのサイズを表示し（-a）、サイズの大きい順に並べ替え（sort -rh）、上位10件だけを抽出します（head -n 10）。数百・数千ファイルが存在するディレクトリでも、この一行で原因ファイルの当たりを付けられます。
特定サイズ以上のファイルを検索する
ディレクトリを跨いで巨大ファイルを網羅的に探したい場合はfindコマンドが有効です。
$ find / -xdev -type f -size +500M -exec ls -lh {} \;-size +500Mで500MB超のファイルを抽出し、-xdevを付けることで他のマウントポイントを跨いだ検索を防ぎます。バックアップの一時ファイルやコアダンプファイルなど、想定外の場所に置かれた大容量ファイルを見つける際に役立ちます。
容量を圧迫しやすい典型パターン
調査を重ねていくと、容量不足の原因はいくつかの典型パターンに集約されることが分かります。あらかじめ傾向を知っておくと、初動での当たりの付け方が速くなります。
ログファイルの無制限な増加
アプリケーションログやアクセスログがローテーション設定なしで運用されていると、時間経過とともに際限なく肥大化します。特にエラーログは、障害発生時に同じエラーが秒単位で出力され続け、数時間で数十GBに達することもあります。du -h --max-depth=1で/var/logが突出している場合は、この可能性を最初に疑ってください。
パッケージキャッシュの蓄積
apt（Debian系）やyum/dnf（RHEL系）はパッケージ更新のたびにキャッシュファイルを保存します。長期間クリーンアップしていない環境では、これが数GB規模に膨らんでいることがあります。
| ディストリビューション | キャッシュ場所 | クリーンアップコマンド |
|---|---|---|
| Debian / Ubuntu | /var/cache/apt/archives | apt clean |
| RHEL / CentOS / Rocky Linux | /var/cache/dnf | dnf clean all |
| Amazon Linux | /var/cache/yum | yum clean all |
パッケージ管理コマンドの詳細な挙動やオプションはディストリビューションのバージョンによって異なるため、実行前に各公式ドキュメントで対応バージョンの仕様を確認してください。
Dockerイメージ・コンテナの残骸
Dockerを使用している環境では、停止済みコンテナや未使用イメージ、ビルドキャッシュが/var/lib/docker配下に蓄積し続けます。docker system dfを実行すると、イメージ・コンテナ・ボリューム・ビルドキャッシュそれぞれの使用量を確認できます。不要なリソースをまとめて削除するdocker system pruneは、稼働中のコンテナやイメージに影響しない範囲で実行対象を確認してから使う必要があります。誤って稼働中のイメージを削除すると本番サービスに影響するため、実行前にdocker system prune -a --dry-runのような事前確認オプションがない場合は、対象一覧を目視で確認してから実行してください。
削除しても容量が戻らない場合
ログファイルを削除したはずなのにdf -hの空き容量が変わらない――このトラブルに遭遇したエンジニアは少なくないはずです。原因は、プロセスがファイルをオープンしたまま削除したことにあります。
lsof +L1で削除済みファイルを特定
Linuxでは、あるプロセスがファイルをオープンしている間にファイルを削除しても、そのプロセスがファイルを閉じるまでディスク上の実体は解放されません。この状態を確認するにはlsof +L1コマンドを使用します。
$ lsof +L1 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NLINK NODE NAME nginx 1234 www 13w REG 253,1 5368709 0 1048 /var/log/nginx/access.log (deleted)
NAME列に「(deleted)」と表示されているファイルが、削除済みだが解放されていない実体です。SIZE/OFF列にその領域の容量が表示されます。この状態を解消するには、該当プロセス（この例ではnginx）を再起動するか、シグナルでログファイルの再オープンを指示する必要があります。
安全な解放手順
プロセスをいきなりkillするとサービスが停止するため、以下の順序で対応することを推奨します。
- 該当プロセスがどのサービスか特定する（COMMAND列とPID列を確認）
- ログローテーションの仕組みを持つデーモンなら、reloadシグナル（例:
systemctl reload nginx）を送る - reloadに対応していないアプリケーションは、メンテナンス時間帯を確保したうえで再起動する
- 再起動後に
df -hで容量が解放されたことを確認する
本番環境でのサービス再起動は影響範囲が大きいため、実施前に必ず担当チーム内で調整し、可能であればメンテナンスウィンドウを設けたうえで作業してください。
再発を防ぐ運用の組み方
一度容量不足を経験した環境では、同じ調査を繰り返さないための仕組み化が次のステップになります。
logrotateによる自動管理
logrotateはログファイルを一定サイズ・一定期間で自動的に切り替え、古いログを圧縮・削除してくれる仕組みです。/etc/logrotate.d/配下に設定ファイルを置くことで、アプリケーションごとにローテーション周期や保持世代数を指定できます。
/var/log/myapp/*.log {
daily
rotate 14
compress
missingok
notifempty
}この設定例では、ログを毎日ローテーションし（daily）、直近14世代を保持し（rotate 14）、古いログを圧縮する（compress）よう指定しています。ログファイルが存在しなくても（missingok）、空でも（notifempty）エラーにならないため、運用中のトラブルを避けやすくなります。設定オプションの詳細はlogrotateのバージョンによって差異があるため、man logrotateまたは公式マニュアルで最新の仕様を確認してください。
監視によるしきい値アラート
ディスク使用率が一定のしきい値を超えたタイミングで通知が届く仕組みを組んでおくと、深刻な状態になる前に対応できます。Zabbix、Prometheus + Node Exporter、CloudWatch(AWS環境)など、監視ツールの選択肢は複数ありますが、共通して重要なのは以下の2点です。
| しきい値 | 対応の目安 |
|---|---|
| 使用率80% | 警告通知。翌営業日中に原因調査を開始する |
| 使用率90% | 緊急通知。即時に本記事の手順で調査を開始する |
| 使用率95%以上 | サービス影響を想定し、不要ファイル削除やスケールアップを即時実施する |
しきい値の具体的な数値は環境ごとのディスク増加速度によって調整が必要です。1日あたりのログ増加量が大きいシステムでは、80%到達時点で既に対応が遅れている場合もあるため、過去の使用率推移グラフを見ながら自環境に合った値を設定してください。
定期的な棚卸しの習慣化
監視アラートに頼るだけでなく、月次や週次でduコマンドによる使用量の棚卸しを実施しておくと、しきい値に達する前の予兆を掴めます。cronでdu -h --max-depth=1 /var > /var/log/disk_usage_$(date +%Y%m%d).logのようなコマンドを定期実行し、履歴を残しておくと、容量増加のペースを後から振り返ることもできます。
よくある質問
Q1. dfとduの結果が一致しないのはなぜですか
dfはファイルシステム全体の使用量、duは指定ディレクトリ配下のファイルサイズ合計を表示します。削除済みだが解放されていないファイル（前述のlsof +L1で確認できる状態）が存在する場合、その分がdfの使用量には含まれる一方でduの集計には現れないため、両者の数値に差が生じます。
Q2. duの実行に時間がかかりすぎる場合はどうすればよいですか
ファイル数が非常に多いディレクトリでは、duがすべてのファイルを走査するため時間がかかります。--max-depthオプションで階層を絞り込む、あるいは調査対象のディレクトリを事前にdfの使用率が高いマウントポイントに限定することで、走査範囲を減らせます。
Q3. ディスク容量不足でサービスが停止した場合、最優先で行うべきことは何ですか
まずdf -hで状況を把握し、緊急避難的に削除しても安全なファイル（古いログのアーカイブ、パッケージキャッシュなど）から解放して稼働を復旧させます。その後、本記事の手順に沿って恒久的な原因を特定し、再発防止策を講じる流れが基本です。
Q4. tmpfsやオーバーレイファイルシステムもdu/dfの対象になりますか
tmpfsはメモリ上に確保される一時ファイルシステムですが、dfの一覧には通常のマウントポイントと同様に表示されます。Dockerのオーバーレイファイルシステムも同様に表示対象ですが、コンテナ内部からduを実行する場合はホスト側の実容量と表示が一致しないことがあるため、ホスト側でも併せて確認してください。
Q5. クラウド環境（AWS EC2など）でディスク拡張はどう行いますか
EBSボリュームのサイズ変更後は、OS側でパーティションとファイルシステムの拡張作業（growpartやresize2fs、xfs_growfsなど）が別途必要です。手順はディストリビューションやファイルシステムの種類によって異なるため、利用しているクラウドサービスとOSの公式ドキュメントを確認しながら作業してください。
関連記事
まとめ
ディスク容量不足の調査は、df -hによるマウントポイント単位の把握から始め、duコマンドで–max-depthオプションを使いながら階層を絞り込んでいく流れが基本です。容量を削除しても数値が戻らない場合はlsof +L1でオープン中の削除済みファイルを疑い、原因プロセスの安全な再起動やreloadで解放します。調査の都度ファイルを手動で削除するだけでなく、logrotateによる自動ローテーションと監視ツールによるしきい値アラートを組み合わせておくことで、同じ調査を繰り返さない運用に近づきます。コマンドのオプションや挙動はディストリビューション・バージョンによって細部が異なるため、実行前には公式ドキュメントで対象環境の仕様を確認し、本番環境での削除・再起動作業は影響範囲を踏まえたうえで慎重に実施してください。
df/duコマンドの基本操作から、inode不足・削除済みファイルの容量未解放といった実務でつまずきやすいポイント、logrotateや監視によるしきい値アラートを組み込んだ再発防止策まで、実践的な手順に沿って構成しています。本記事はInfra Academy編集部が各ベンダー公式ドキュメント・エンジニア監修をもとに作成しています。インフラ・クラウド構築は環境により異なります。本番環境への適用前に必ずテストを実施してください。情報の正確性には万全を期していますが、最新情報は各公式ドキュメントをご確認ください。 編集ポリシーはこちら
