サーバーの空き容量が一気にゼロへ――。監視が赤く染まり、アプリはログを書けず、最悪の場合はOSの挙動まで不安定になります。
実務でよくある原因は二つ。
無制限に成長したログの肥大、そして削除したはずのファイルをプロセスが握り続ける「deletedハンドル」です。
どちらも現場では“とりあえず rm したのに空かない”という混乱を招きがちですが、適切な初動を踏めば数分で落ち着きを取り戻せます。
このガイドは、復旧を急ぐ運用担当者のために止血→原因特定→再発防止をひと続きの手順にまとめました。判断基準ごと整理します。
本番環境で怖いのは、誤爆と取り返しのつかない削除です。そこで本記事では、削除よりもまず縮小、広範囲よりも最小範囲という原則を徹底し、コピペで回せるコマンドと注意点を添えました。運用の現場でそのまま使える、実務直結の初動手順集として活用してください。
詳細な流れを横断的に確認したい場合は Linuxトラブルシューティング総合ハブ から全体像をご覧いただけます。
ディスク逼迫のサインと即時判断
df/du で「どのマウントが苦しいか」を30秒で把握
最初にやることは、逼迫しているのがどのマウント（パーティション）かを掴むことです。df -h を叩いて、使用率とマウントポイントを一望します。/ が真っ赤なのか、/var やアプリ用の別ボリュームが詰まっているのかで、後続の手当てが変わります。
# 使用率とマウントポイントを人間に読みやすく表示
df -h | awk 'NR==1 || $5+0 >= 80' # 80%以上だけに絞るのも有効
どのマウントか当たりがついたら、そのマウント内に絞って大きい場所を特定します。du は範囲を狭めるほど高速です。-x を付ければ同一ファイルシステムに限定でき、他のマウントに跨らずに“太いところ”を見つけられます。
# 例：/var が逼迫していると分かった場合
sudo du -ahx /var | sort -hr | head
数十秒で「/var/log が巨大」「/var/lib/journal が突出」などの第一印象を持てれば、止血の手を素早く選べます。
inode 逼迫の同時チェック（df -i）
容量（ブロック）だけでなく、inode の枯渇にも注意します。小さなファイルが爆発的に増えると、使用容量に余裕があっても新規ファイルを作れない状態になります。df -i で IUse% を確認し、90%超えなら inode 側の異常を疑います。キャッシュやテンポラリ、アプリの細切れログが元凶になりやすく、止血は「大量の極小ファイルを安全に片づける」方向になります。
# inode 使用率を確認
df -i | awk 'NR==1 || $5+0 >= 80'
inode 逼迫のときは、find で極小ファイルを傾向把握し、アプリやジョブの生成元を押さえます。
# 1KB未満のファイルが多いディレクトリを概観
sudo find /var -xdev -type f -size -1k -printf '%h\n' | sort | uniq -c | sort -nr | head
影響範囲の切り分け（/var, /home, /tmp, / の優先度）
逼迫の場所が分かったら、影響の出方を見積もります。まず /var が詰まると、ログ書き込みやパッケージ管理、キューやキャッシュに影響が出ます。/tmp の逼迫は一時ファイル生成の失敗を招きやすく、ビルドや変換系が止まりやすい。/home はユーザ領域なのでアプリ本体への直接影響は限定的ですが、開発・デプロイのワークスペースを圧迫します。/（ルート）が苦しい場合は OS 全体に波及しやすく、最優先で止血します。
この段階のゴールは、止血の選択肢を瞬時に並べることです。/var/log のサイズ肥大が当たりなら journald の vacuum や logrotate の暫定運用、/var/lib で削除済みファイルを疑うなら lsof +L1 に進む、といったように、次の一手を明確にします。
まず止血：安全に空きを作る原則
削除より“縮小”を優先する理由
ディスクが逼迫したとき、慌てて rm コマンドでログを削除するのは危険です。
削除した瞬間に空きが戻るとは限らず、むしろ プロセスが握っているファイルは「deleted」状態のまま残り続けることがあります。その結果、空きは回復せず、復旧の見通しがつかなくなるケースも少なくありません。
また、誤って必要なファイルを削除してしまえば、ログ解析や監査証跡が失われるリスクがあります。したがって初動では「削除」ではなく、**容量を縮めるアプローチ（truncate・vacuum・logrotate）**を優先するのが安全です。
サービス影響を最小化する手順設計
逼迫対応は、復旧と同時に影響範囲を最小に抑えることが求められます。
アプリケーションが停止してもよい時間帯なら再起動によるログの再オープンが確実ですが、常時稼働サービスでは難しいこともあります。その場合は、プロセスを止めずにログを縮小する方法（例：copytruncate や truncate -s 0）を選択します。
また、応急処置と恒久対応を区別することも重要です。応急で縮めて空きを作り、サービスを安定させた後で、改めて設定変更や再設計を行うフローを前提にしましょう。
一時退避領域・スナップショットの扱い
もし別ボリュームに十分な空きがあるなら、一時的に大きなログやデータを退避するのも手段のひとつです。たとえば /mnt 配下の一時領域や外部ストレージに退避し、本来のディスクから切り離すことで即時の空きを確保できます。
ただし、退避したファイルを削除するかどうかは要件次第です。監査ログやアクセスログは後で必要になる場合があるため、削除ではなく圧縮・移動を選択する方が安心です。クラウド環境ならスナップショットを取り、必要に応じて解析できるようにするのも有効です。
このように「削除」よりも「縮小」や「退避」を優先する原則を守れば、復旧作業中の二次トラブルを防ぎつつ、安全に空きを取り戻せます。
journald（systemd-journal）の肥大対策
journalctl --vacuum-size/--vacuum-time の即時縮小
systemd が管理するバイナリログ（journal）は、放置すると数 GB 以上に肥大化し、/var/log/journal がディスクを食いつぶすことがあります。
応急対応としてもっとも即効性があるのは vacuum オプションです。
# 過去ログを削除し、500MBに収まるまで縮小
sudo journalctl --vacuum-size=500M
# または30日より古いログを削除
sudo journalctl --vacuum-time=30d
これらの操作は「古いアーカイブを間引く」仕組みなので、稼働中のサービスには影響を与えずに空きを確保できます。まず止血を優先するなら、このコマンドが最短ルートです。
journald.conf の上限設計（SystemMaxUse / SystemKeepFree）
vacuum はその場しのぎなので、再発防止には journald の上限設定を必ず行います。設定ファイルは /etc/systemd/journald.conf にあります。
代表的な設定項目は以下のとおりです。
SystemMaxUse=
journal が使用できる最大容量を指定（例：1G）。SystemKeepFree=
指定した分だけ必ず空きを残すよう調整。SystemMaxFileSize=
1ファイルあたりの上限サイズを制御。
編集後は systemctl restart systemd-journald で反映します。
# /etc/systemd/journald.conf
[Journal]
SystemMaxUse=1G
SystemKeepFree=500M
これにより「気づいたら journal が数十 GB」という事態を防げます。
バイナリジャーナルの保全と監査要件の折り合い
監査ログを一定期間保持しなければならない場合、vacuum や上限設定と要件が衝突することがあります。その場合は journal をテキスト化してアーカイブする運用が有効です。
# 日次でjournalをテキスト化し、gzで圧縮
journalctl --since "yesterday" --until "today" > /var/log/journal-archive/$(date +%F).log
gzip /var/log/journal-archive/$(date +%F).log
こうすることで、journald 本体は容量制御を効かせつつ、必要な証跡を外部に残すことができます。
journal の管理は「止血の速さ」と「再発防止の確実さ」を両立するのがポイントです。
vacuum で即応、journald.conf で制御、必要に応じてアーカイブ保存。この流れを Runbook にまとめておけば、再び逼迫したときにも迷わず動けます。
アプリケーションログの一時対応と設計見直し
logrotate の手動実行と copytruncate の使い所・注意点
アプリケーションが出力するテキストログは、サイズが肥大して容量を圧迫しやすい領域です。
応急対応としては、まず logrotate を即時に回すのが効果的です。
# 設定ファイルを指定して即時実行
sudo logrotate -f /etc/logrotate.conf
もし対象ログがプロセスに握られていて rm しても空きが戻らない場合、copytruncate オプションを利用した設定で一時的にサイズを削れます。これは「コピーしてからファイルを空打ちにする」仕組みで、サービスを止めずに済むのが利点です。
ただしコピーの間に書き込みがあった場合、その部分が欠損するリスクがあります。したがって 緊急時の応急策に限定し、恒久的な運用には避けたほうが安心です。
SIGHUP でのログ再オープン／サービス再起動の判断軸
多くのデーモンやアプリケーションは、SIGHUP シグナルを受けるとログファイルを再オープンするように設計されています。
その場合は kill -HUP <pid> でログを開き直し、古いファイルを安全にローテートできます。
# Apache や Nginx など典型的な例
sudo kill -HUP $(cat /var/run/nginx.pid)
もしアプリが SIGHUP をサポートしていない場合は、サービス再起動が確実です。ダウンタイムが許容できない環境では、可用性を考慮した切り替え計画が必要になります。
圧縮・保持数・世代管理の暫定→恒久移行プラン
logrotate の設定ファイルでは、圧縮形式（gzip/bzip2/zstd）や保持数、ローテーション間隔（日次・週次・サイズ基準）を細かく定義できます。応急時は「すぐ空きを作る」ことが優先ですが、復旧後は以下を見直して再発防止に繋げます。
- サイズ基準でのローテーション（
size 100Mなど）を導入 compressとdelaycompressで圧縮世代を整理rotate 7のように保持世代を制御し、過剰保存を避ける
このように、即時対応から恒久設計へと自然に移行できるような logrotate 設計に整えておくと、次のディスク逼迫を未然に防げます。
「deletedハンドル」で空かない領域の解放
lsof +L1 で握られた削除済みファイルを特定する
「rmしたのに空き容量が増えない」──そんなときは deletedハンドルを疑います。これは、ファイルのリンク名は消えていてもプロセスがそのファイルを開いたまま保持している状態です。中身（inode）は解放されず、容量が塞がったままになります。
特定には lsof +L1 を利用します。
# 削除済みなのにプロセスに握られているファイルを一覧
sudo lsof +L1
# 出力例
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NLINK NODE NAME
nginx 12345 www 4w REG 253,0 10485760 0 1234 /var/log/nginx/access.log (deleted)
NLINK が 0 で、(deleted) と付いているのがポイントです。PID とプロセス名を確認し、どのアプリが握っているかを把握します。
再起動／SIGHUP／truncate -s 0 の優先度とリスク
deleted ハンドルを解放するには、プロセスをどう扱うかで手順が変わります。
- サービス再起動
最も確実。PID が握っているファイルハンドルを閉じるので、即時に領域が解放されます。ただしダウンタイムが発生します。 - SIGHUP を送る
多くのデーモンはSIGHUPでログファイルを再オープンします。サービスを落とさずに解放できるため、可用性を優先する環境で推奨されます。sudo kill -HUP <PID> truncate -s 0でサイズをゼロ化
プロセスが握ったままのファイルに対して、中身を空にする方法です。所有権やパーミッションはそのまま残ります。
どうしても再起動できない環境での最終手段と考えましょう。sudo truncate -s 0 /proc/<PID>/fd/<FD番号>
それぞれメリットとリスクがあるため、本番環境では 「再起動 > SIGHUP > truncate」 の順で検討するのが安全です。
コンテナ・PID 名前空間での観測ポイント（宿主 vs コンテナ）
Docker や Podman などのコンテナ環境では、コンテナ内で削除しても宿主側で容量が戻らないケースがあります。これは 宿主のカーネルが inode を握り続けているためです。
この場合はコンテナ内部ではなく、ホストOS側で lsof +L1 を実行して特定する必要があります。ログ出力先をボリュームに切り出すなど、設計段階での対策も合わせて検討すると安心です。
その場で回せる初動オペチェックリスト
現状把握 → 逼迫マウントを特定
まずはどこが詰まっているかを確認します。df -h で全体の使用率を見て、80％以上に達しているマウントを洗い出します。続いて du -ahx /対象パス | sort -hr | head を使って、重たいディレクトリを上位から掘り下げていきます。これで「どこを止血するか」の的を外しません。
止血 → journal やアプリログを縮小
/var/log/journal が肥大している場合は journalctl --vacuum-size=500M のように縮小します。アプリのログなら logrotate を手動で回し、どうしても縮小できなければ copytruncate を応急的に利用します。削除でなく縮小を選ぶことで、空き容量を確実に回収できます。
deleted 調査 → 握ったままのファイルを解放
削除したのに空きが戻らないときは lsof +L1 を実行し、PID とファイルを突き止めます。サービス再起動が最も安全ですが、止められない場合は kill -HUP <PID> でログ再オープン、最終手段として truncate -s 0 を検討します。
大物探索 → 突出したファイルを探す
逼迫要因が一見でわからない場合は、du や ncdu を用いて大きなファイル・ディレクトリを見つけます。キャッシュやコアダンプが数 GB 占めている場合も多く、整理だけで即時回復することがあります。
恒久化 → 設定と監視の整備
応急処置で復旧した後は必ず恒久策に移ります。journald.conf で上限を設定し、logrotate の保持数・圧縮設定を見直します。さらに監視に「容量の増加速度」や「inode 使用率」を組み込み、再発前に気づける仕組みを作っておきましょう。
この 5 ステップを Runbook として手元に持っておけば、いざという時に迷わず動けます。ディスク逼迫は「時間との勝負」だからこそ、手順を型にして即応できる状態を整えることが肝心です。
どこが太っている？大型ディレクトリ／ファイルの速攻特定
du -ahx ./ | sort -hr | head の反復ドリルダウン
逼迫の原因がログや deleted ハンドル以外に潜んでいることもあります。そんなときに役立つのが、du と sort を組み合わせた定番ワンライナーです。
cd /var
sudo du -ahx ./ | sort -hr | head
このコマンドは /var 以下のファイルとディレクトリをサイズ順に並べ、上位10件を表示します。
「/var/cache が膨らんでいる」「アプリの一時ディレクトリが異常に大きい」といった傾向を即座に見つけられるので、逼迫原因を短時間で切り分けるのに非常に有効です。
ポイントは 繰り返し掘り下げること。大きなディレクトリが見つかったら、その配下に対して同じコマンドを実行し、さらに細かい原因箇所を追い詰めていきます。
ncdu・dust など TUI/CLI ツールの活用
時間に余裕があれば、インタラクティブなツールを使うのもおすすめです。ncdu はテキストベースの UI でディスク使用量を可視化し、カーソル操作で掘り進められるため、SSH 越しでも快適に調査できます。
# Debian/Ubuntu 系
sudo apt install ncdu
# Red Hat 系
sudo yum install ncdu
同様に dust や duf などの軽量ツールもあり、視覚的に大きなディレクトリを把握する助けになります。
一時ファイル・キャッシュ・コアダンプの扱い
逼迫の元凶になりやすいのが /tmp やアプリケーションのキャッシュディレクトリ、さらにはコアダンプファイルです。これらは本来、一時利用や障害調査でのみ必要なものですが、放置すると数 GB〜数十 GB に膨らむことがあります。
/tmpは定期的なクリーンアップを仕組み化する- キャッシュはサービス設計に応じて「消して良いもの」と「保持すべきもの」を区別する
- コアダンプは保存場所と保持方針を明示し、必要に応じてアーカイブしてから削除
こうした基本的な整理ルールをあらかじめ定めておくことで、緊急時に「削除していいか迷う」時間を減らせます。
本番で避けたいNG対応
「rmだけ」で終わらせる危険性
ディスク逼迫時に慌ててログファイルを rm で削除するのは、典型的な落とし穴です。プロセスがファイルを握ったままの場合、名前が消えても inode は保持され、容量は解放されません。空きが戻らないばかりか、ログ解析のための証跡も失われ、二重のリスクを抱えることになります。
無計画な find -delete の乱用
大きなディレクトリを丸ごと削除するために find で一括削除を実行すると、思わぬシステムファイルやアプリケーションデータを巻き込む危険があります。特に /var 配下には、ログ以外にもキャッシュやライブラリデータ、サービス用の永続ファイルが混在しています。復旧どころかサービス障害を招く可能性が高いため、NG対応の代表例といえます。
システム領域の無計画圧縮・削除
容量を確保しようとして /usr や /var/lib を不用意に削除・圧縮するのも危険です。パッケージ管理やデータベースの稼働に必要なファイルが含まれており、削除すれば即座にサービスが落ちます。空き容量を取り戻すはずが、システム停止という致命的な結果を招きかねません。
スワップ・一時領域の誤操作
/swapfile や一時ディレクトリを無計画に削除すると、OS やアプリケーションの挙動が著しく不安定になります。特にスワップ領域を消してしまうと、メモリ不足時の保護が効かなくなり、サーバーがクラッシュするリスクがあります。
NG対応に共通するのは「場当たり的で、安全確認をしていないこと」です。
ディスク逼迫は焦りを生みますが、縮小・退避・適切な調査を優先し、削除は最終手段にとどめる姿勢が本番環境では不可欠です。
事後の振り返りと再発防止
監視とアラート設計（使用率＋増加速度＋inode）
逼迫を経験した後は、次を防ぐ仕組みづくりが欠かせません。監視は「使用率」だけでなく「増加のスピード」も見ておくと効果的です。
例えば「24時間で10％以上増加したら警告」といった設定にすれば、まだ余裕がある段階で異常を検知できます。
また、容量だけでなく inode 使用率も監視に組み込むことで、極小ファイル大量生成によるトラブルを防げます。
ログ方針の標準化（ローテーション、再起動手順、Runbook）
ログ管理の方針が曖昧だと、同じ逼迫を繰り返すことになります。
- journald の容量上限をあらかじめ設定する
- logrotate の間隔や保持世代を標準化する
- アプリケーションごとに「SIGHUPでログを切り替えられるか」「再起動が必要か」を確認して手順化する
こうした内容を Runbook（対応マニュアル）にまとめ、誰が担当しても同じ流れで対応できるようにしておくことが大切です。
週次点検と容量予測（トレンド可視化と容量計画）
逼迫は突発的に見えても、多くの場合は少しずつ容量を食い続けた結果です。週に一度は du の上位結果を記録して比較すると、「この1週間で /var/log が急激に増えている」といった傾向が見えてきます。
さらに監視ツールや可視化ツールを使い、グラフで容量推移を確認できるようにすれば、予兆をもとに容量追加や設計改善の判断ができます。クラウド環境であれば、自動スケーリングやボリューム拡張の仕組みを組み込むのも有効です。
ディスク逼迫は「緊急時の冷静な初動」と「日常的な地道な監視」の両方でしか防げません。一度のトラブルをきっかけに、仕組みそのものを見直し、再発しないサイクルをつくっていくことが、安定運用の近道です。
ありがちな元凶と恒久対策の方向性
ログ設計の型化（journald とテキストログの住み分け）
アプリの標準出力・標準エラーを journald に集約し、必要に応じてファイルへフォワードする方針に統一すると、容量制御の主語が一つになります。journald 側は SystemMaxUse / SystemKeepFree を明示して上限管理、テキストログは logrotate でサイズ基準のローテーションを徹底します。どちらも「どれだけ増えるか」を設計に織り込んでおくことが再発防止の第一歩です。
ローテーションと再オープンの標準手順
logrotate は「いつ」「どれだけ」回すかを決めるだけでなく、「どう切り替えるか」も決めておく必要があります。SIGHUP での再オープンが可能かをアプリごとに確認し、不可ならメンテナンス時間帯の再起動手順を標準化します。copytruncate は無停止性の確保に役立ちますが欠損リスクがあるため、緊急時に限定する運用ルールを明文化しておきましょう。
コアダンプ・一時領域・キャッシュの方針
/var/crash やアプリのダンプ出力、ビルドや変換の一時領域は、意図せず肥大しやすい“隠れ肥満”ゾーンです。保存場所・保持期間・容量上限を決め、日次あるいは週次のクリーンアップをタスク化します。クラウドであれば、低コストストレージに自動アーカイブしてから削除する流れにしておくと、調査性と保管コストの両立が図れます。
コンテナ環境の設計見直し
ログはホスト共有ボリュームやログ収集サイドカーへ集約し、コンテナ内の匿名レイヤに溜めない設計にあらためます。ホスト側での lsof +L1 観測と合わせ、どこで握られているかを一発で追える監視・可視化の導線を用意しておくと、初動の迷いを減らせます。
結び
ディスク逼迫は、慌てて削除に走るほど長引きます。
削るより「縮める」、広く触るより「狭く特定する」。
この原則で、journal の vacuum・logrotate の即時実行・lsof +L1 の特定という“最短コンボ”を素早く回し、復旧後は上限設定と標準手順に落としてサイクルを閉じる。運用の現場で手が勝手に動くよう、本文のコマンドと判断軸をそのまま Runbook に写し込み、チームで共有しておくと安心です。
参考・参照リンク
- journal の縮小オプション（
--vacuum-size/--vacuum-time）：freedesktop.org の journalctl マニュアル。 (freedesktop.org) journald.confの容量制御（SystemMaxUse/SystemKeepFreeほか）：freedesktop.org の公式ドキュメント。 (freedesktop.org)- logrotate の
copytruncateの注意点（欠損リスクの明記あり）：man7 の logrotate(8)。 (man7.org) lsof +L1（削除済みだが開かれたままのファイルの特定）：Unix & Linux/Stack Exchange の解説。 (Unix & Linux Stack Exchange)truncateコマンド（サイズ縮小/拡張の仕様）：GNU coreutils マニュアル、man7。 (GNU)duと-xオプションの概要：Wikipedia（du の解説）。 (ウィキペディア)- journald の実運用ノート：ArchWiki。 (ArchWiki)
