Linuxでディスクが容量不足になった時の対処手順|原因ファイルの特定から安全な削除まで

宮崎智広 この記事の監修:宮崎智広(Linux実務・教育歴20年以上・受講者3,100名超)
HOMELinux技術 リナックスマスター.JP(Linuxマスター.JP)Linuxtips, Linuxトラブルシューティング > Linuxでディスクが容量不足になった時の対処手順|原因ファイルの特定から安全な削除まで
「df -hコマンドを実行したら Use% が 100% になっていた」「ディスクが満杯でサービスが止まった」——こんな経験、Linuxサーバーを運用していれば必ず一度は遭遇します。
容量不足はパニックになりがちですが、手順を知っていれば冷静に対処できます。

この記事では、Linuxでディスク容量が不足した時の対処フロー(原因ファイルの特定から安全な削除まで)を体系的に解説します。
dfコマンドで状況を確認してから、duコマンドで原因を特定し、安全にディスクを空ける具体的な手順まで、ステップごとに説明します。

この記事のポイント

・dfコマンドで「どのパーティションが満杯か」を最初に把握する
・duコマンドで「容量を食っているディレクトリ」を絞り込む
・ログ・コアダンプ・古いバックアップが原因の大多数を占める
・削除前に必ずファイルの用途を確認してから実施する


「このままじゃマズい」と感じていませんか?
参考書を開く気力もない、同年代に取り残される不安——
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
図解60P/登録10秒/解除も3秒 / 詳細はこちら

ディスク容量不足が引き起こす問題

ディスクが満杯になると、様々な深刻な問題が発生します。

Webサーバーが停止:Apacheなどのアクセスログが書き込めなくなり、500エラーが続出する
データベースの破損リスク:MySQLやPostgreSQLはトランザクションログを書けないと異常終了する
メール配送の失敗:メールキューがディスクに書けなくなり、メールが届かなくなる
cronジョブの失敗:一時ファイルが作れず、定期バッチが止まる

特に /var パーティションが満杯になるケースが現場で圧倒的に多い印象です。ログファイルが積み上がり、いつの間にかいっぱいになるパターンです。

STEP 1:dfコマンドで満杯パーティションを特定する

まず全体像を把握するために df コマンドを実行します。

# ディスク使用量をヒューマンリーダブルな形式で確認する $ df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 4.0M 0 4.0M 0% /dev tmpfs 7.7G 0 7.7G 0% /dev/shm tmpfs 3.1G 8.8M 3.1G 1% /run /dev/sda1 50G 49G 500M 99% / /dev/sda2 100G 40G 60G 40% /home tmpfs 7.7G 12K 7.7G 1% /run/user/0

上記の例では `/dev/sda1`(ルートパーティション `/`)の Use% が 99% になっています。
この場合、ルートパーティション配下のどこかに大量のファイルが積み上がっているとわかります。

パーティション構成の詳細を見たい場合は、mount コマンドの使い方も参照してください。マウントポイントとファイルシステムの対応関係が把握できます。

1. df -h の主要な見方

列名 意味
Filesystem デバイス名(/dev/sda1 など)
Size パーティションの合計容量
Used 使用済み容量
Avail 空き容量
Use% 使用率(90% を超えたら要警戒)
Mounted on マウントポイント(/ /home /var など)

2. inodeが満杯のケースも忘れずに確認

Use% が 100% に見えないのにファイルを作れない場合、inode が枯渇している可能性があります。

# inodeの使用状況を確認する(-i オプション) $ df -i Filesystem Inodes IUsed IFree IUse% Mounted on /dev/sda1 3276800 3276799 1 100% /

IUse% が 100% ならファイルの数が上限に達しています。小さいファイルが大量に作られているケースで発生しがちです(PHPのセッションファイルなど)。

STEP 2:duコマンドで原因ディレクトリを絞り込む

満杯になっているパーティションが判明したら、次は `du` コマンドで「どのディレクトリが容量を食っているか」を掘り下げます。

1. ルートディレクトリから大きい順に確認する

# 第1階層のディレクトリを容量の大きい順に表示する $ du -sh /* 2>/dev/null | sort -rh | head -20 24G /var 15G /home 8G /opt 3G /usr 1.2G /tmp 200M /etc ...

上記の例では `/var` が 24G と断トツなので、/var の中身を掘り下げます。
`2>/dev/null` はアクセス権限エラーメッセージを捨てるためのリダイレクトです(Permission denied が大量に流れるのを防ぎます)。

2. 絞り込んだディレクトリの中を掘り下げる

# /var 配下を容量の大きい順に表示する $ du -sh /var/* 2>/dev/null | sort -rh | head -20 21G /var/log 1.5G /var/cache 300M /var/lib 80M /var/spool

# /var/log 配下をさらに掘り下げる $ du -sh /var/log/* 2>/dev/null | sort -rh | head -20 18G /var/log/nginx 2.5G /var/log/messages 80M /var/log/secure 50M /var/log/cron

ここまで絞り込めると、「nginxのアクセスログが18Gになっている」と具体的に原因がわかります。

3. 特定ファイルを1個ずつ確認する

ディレクトリが特定できたら、その中の個別ファイルを確認します。ls コマンドの基本オプションを使って、サイズとタイムスタンプを一緒に確認するのが基本です。

# ファイルサイズの大きい順に表示(-S でサイズソート) $ ls -lhS /var/log/nginx/ -rw-r--r-- 1 root root 15G Jan 10 09:23 access.log -rw-r--r-- 1 root root 1.2G Jan 8 23:59 access.log.1 -rw-r--r-- 1 root root 400M Jan 7 23:59 access.log.2 -rw-r--r-- 1 root root 200M Jan 6 23:59 access.log.3

STEP 3:原因別の対処方法

原因が特定できたら、次は適切な方法で削除・圧縮します。闇雲に `rm` するのは厳禁です。

1. ログファイルが肥大化している場合

古いローテーション済みログ(.log.1、.log.2 など)は削除しても問題ありません。ただし、現在書き込み中のファイル(拡張子なしの .log ファイル)はプロセスが掴んでいるため `rm` だけでは解放されないことがあります。

# ローテーション済みの古いログを削除する(例:30日より古いもの) $ find /var/log -name "*.log.*" -mtime +30 -exec rm {} \; # 現在書き込み中のログを安全に空にする(rm ではなく truncate を使う) $ truncate -s 0 /var/log/nginx/access.log

`truncate -s 0` はファイルを削除せずにサイズを 0 にするコマンドです。nginx などのプロセスがファイルディスクリプタを持ったままでも、安全に空にできます。`rm` で削除するとプロセスが古いファイルを掴み続け、ディスクが解放されないことがあります。

なお、本来はlogrotateを使った定期ローテーションを設定しておくべきです。今後の対策として必ず検討してください。

2. コアダンプが溜まっている場合

# コアダンプファイルを探す $ find / -name "core" -o -name "core.[0-9]*" 2>/dev/null # 確認してから削除する $ find / -name "core" -mtime +7 -exec ls -lh {} \; $ find / -name "core" -mtime +7 -exec rm {} \;

3. /tmp が肥大化している場合

# /tmp の大きいファイルを確認する $ du -sh /tmp/* 2>/dev/null | sort -rh | head -10 # 7日より古い一時ファイルを削除する(アクセス中のファイルは自動的にスキップされる) $ find /tmp -mtime +7 -exec rm -rf {} \; 2>/dev/null

4. 古いバックアップや圧縮アーカイブを整理する

バックアップファイルが古くなり不要になっているケースも多いです。残すべきバックアップは圧縮してサイズを削減できます。tar コマンドの実用例を参考に、古いログを tar.gz 化してアーカイブする方法が有効です。

# 古いバックアップファイルを探す(例:/backup 配下) $ find /backup -name "*.sql" -mtime +90 -exec ls -lh {} \; # 古いSQLバックアップをtar.gzに圧縮して容量を節約する $ find /backup -name "*.sql" -mtime +90 | while read f; do gzip "$f" echo "圧縮完了: $f.gz" done

5. パッケージキャッシュが溜まっている場合(RHEL・CentOS系)

# dnf / yum のパッケージキャッシュをクリアする $ dnf clean all # または yum を使う環境(CentOS 7 など) $ yum clean all # キャッシュサイズを確認する $ du -sh /var/cache/dnf/

STEP 4:プロセスが掴んでいる削除済みファイルの解放

`rm` でファイルを削除したはずなのに `df` を見ても容量が減らない——この現象はよく発生します。
原因は「プロセスがファイルのファイルディスクリプタを保持している」ためです。ディレクトリエントリは消えても、ディスク領域はプロセスが終了するまで解放されません。

# 削除済みだがプロセスが掴んでいるファイルを探す(lsof -nP は名前解決しない高速版) $ lsof -nP | grep "(deleted)" nginx 12345 root 10w REG 8,1 15000000 /var/log/nginx/access.log (deleted) # 対処1: 対象プロセスを再起動してファイルディスクリプタを手放させる $ systemctl restart nginx # 対処2: truncate でサイズを0にしてから再起動する(中断が嫌な場合) $ truncate -s 0 /var/log/nginx/access.log $ kill -USR1 $(pgrep nginx)

トラブルシュート

「df では余裕があるのにファイルが書けない」

先ほど触れた inode 枯渇の可能性があります。`df -i` でIUse%を確認してください。inode不足の場合は、大量の小さいファイルを削除するのが対処法です。

# ディレクトリ別のinode使用数を調べる(小さいファイルが多い場所を特定する) $ find / -xdev -printf '%h\n' 2>/dev/null | sort | uniq -c | sort -rn | head -20 # PHPセッションファイルが原因の場合はまとめて削除する $ find /var/lib/php/session -mtime +1 -exec rm {} \;

「duの合計値がdfの使用量と合わない」

`du` は削除済みだがプロセスが掴んでいるファイルをカウントしません。差がある場合は `lsof | grep deleted` で確認してください。また、`/proc` 配下など特殊なファイルシステムは `du` に含まれないことがあります。

「消したのに容量が戻らない」

前述のプロセスが掴んでいるケースが最多です。`lsof -nP | grep "(deleted)"` を実行して確認してください。対象プロセスを `systemctl restart` するだけで解決することがほとんどです。

本記事のまとめ

Linuxのディスク容量不足への対処手順をまとめます。
やること コマンド
満杯パーティションを確認する df -h
inode枯渇を確認する df -i
第1階層の容量を大きい順に確認する du -sh /* 2>/dev/null | sort -rh | head -20
サブディレクトリを掘り下げる du -sh /var/* 2>/dev/null | sort -rh | head -20
古いログを削除する(30日超) find /var/log -name "*.log.*" -mtime +30 -exec rm {} \;
書き込み中のログを安全に空にする truncate -s 0 /var/log/xxx/access.log
dnfキャッシュをクリアする dnf clean all
削除済みでプロセスが掴んでいるファイルを確認する lsof -nP | grep "(deleted)"
手順の鉄則は「df で全体 → du で絞り込む → 用途確認してから削除」の3段階です。
焦って闇雲に削除するのが最も危険なので、上から順にコマンドを実行して原因を特定してから対処するようにしてください。

再発防止には logrotate の設定見直しと、定期的なディスク使用量の監視(cronで df を記録するなど)を強くお勧めします。

ディスク容量トラブルを未然に防ぐには、サーバー設計の「型」を知ることが近道です

ディスク容量不足の根本原因はほぼ「設計段階でのパーティション分割不足」と「ログ管理の仕組み未整備」です。パーティション設計・logrotate・監視の仕組みを体系的に身につけることで、こうしたトラブルを未然に防げます。
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル(図解60P)』を完全無料でプレゼントしています。

「独学の時間がもったいない」「プロから直接、現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。

無料メルマガで学習を続ける

Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。

登録無料・いつでも解除できます

暗記不要・1時間後にはサーバーが動く

3,100名以上が実践した「型」を無料で公開中

プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。

登録10秒/合わなければ解除3秒 / 詳細はこちら

Linux無料マニュアル(図解60P) 名前とメールで30秒登録
宮崎 智広

この記事を書いた人

宮崎 智広(みやざき ともひろ)

株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。

趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。