サーバーを運用していると、ある日突然「ディスク容量が不足しています」というエラーに直面することがあります。容量が逼迫するとログが書き込めず、アプリケーションが停止したり、バックアップが失敗したりといった深刻な障害につながることも少なくありません。特にクラウド環境では容量超過がそのままコスト増加に直結するため、事前の監視と管理が欠かせません。
Linux環境でディスク使用量を確認する際によく使われるのが df と du という2つのコマンドです。df はシステム全体の空き容量や使用状況を把握するのに適しており、du はディレクトリやファイル単位でどこが容量を消費しているかを調査するのに役立ちます。両者を組み合わせることで、容量不足の発生を防ぎ、原因を迅速に特定できるようになります。
本記事では、サーバー管理者が日常業務で直面する「容量不足」トラブルを防ぐために、df と du の基本的な使い方から、実際の調査手順、大容量ファイルの特定方法、さらには定期監視や自動化のポイントまでを網羅的に解説します。これから紹介する手順を押さえておけば、予期せぬサービス停止を防ぎ、安定したシステム運用につなげることができるでしょう。
ディスク使用量確認が必要になるシーン
サーバーの運用では、ディスク使用量を把握することは欠かせません。容量不足が起きるとサービス停止やパフォーマンス低下に直結するため、管理者は定期的にチェックする必要があります。ここでは代表的なケースをいくつか紹介します。
ログファイルの肥大化
最もよくある原因がログファイルの増加です。通常はローテーション設定により古いログが圧縮・削除されますが、設定不備やエラーの多発により短期間で肥大化することがあります。特に /var/log ディレクトリは容量不足の主因になりやすいため注意が必要です。
バックアップファイルの保存先不足
定期的なバックアップは安全な運用に欠かせませんが、そのサイズは数GB〜数十GBに達することもあります。古いファイルを整理せずに放置すると、気づかないうちにストレージを圧迫し、バックアップの新規作成に失敗することもあります。
アプリケーションの動作停止
ディスク容量が枯渇すると、一時ファイルやセッションデータが書き込めなくなり、アプリケーションが停止することがあります。Webサーバーやデータベースの書き込みエラーは、ユーザーに直接的なサービス停止を引き起こすため、最も避けたいトラブルのひとつです。
クラウド環境でのコスト増加
オンプレミスだけでなく、クラウド環境でも容量管理は重要です。AWSやGCPなどではストレージ使用量に応じて課金されるため、不要データを放置するとコストが増大します。定期的な使用量の把握は、コスト最適化の観点からも必須です。
このようにディスク使用量の確認は、単なるメンテナンス作業ではなく 障害回避・コスト削減・サービス安定性の確保 に直結します。だからこそ、管理者は df と du を組み合わせて容量不足を未然に防ぐ体制を整える必要があるのです。
dfコマンドの基本｜全体のディスク使用量を確認
サーバー全体のディスク容量を一目で把握する際に役立つのが df コマンドです。ファイルシステム単位での利用状況を一覧表示してくれるため、「どのパーティションに空きがどれだけあるか」を確認するのに最適です。
基本構文と出力例
df の基本的な使い方は以下の通りです。
df
このまま実行すると、マウントされているファイルシステムの容量・使用量・利用率などが表示されます。ただしデフォルトではブロック数（1ブロック＝1KBなど）で表示されるため、人間には読みにくい結果となります。
よく使うオプション
管理者が実務で頻繁に利用するオプションは以下の通りです。
-h: サイズをKB/MB/GB単位で見やすく表示-T: ファイルシステムの種類を表示-i: iノード使用量を確認（大量の小ファイルによる枯渇を調査するときに有効）
例えば以下のコマンドを実行すると、見やすい形式で容量を確認できます。
df -hT
これにより「ディスク残量がどの程度か」「ファイルシステムの種類は何か」がひと目で分かります。
実務での活用例
- 日常的なサーバーチェック：cronで1日1回
df -hを実行し、結果をメール通知することで容量不足の兆候を早期に発見可能。 - 障害対応時の切り分け：アプリケーションが書き込みに失敗した際、まず
df -hで空き容量を確認するのが定番の第一ステップ。 - iノード調査：容量が余っているのに「ディスクいっぱい」のエラーが出る場合、
df -iでiノードの消費状況を調べると原因が分かることが多い。
注意点
df はファイルシステム単位での情報を表示するため、「どのディレクトリやファイルが容量を消費しているか」までは分かりません。全体を把握する入口として使い、その後の調査には du を組み合わせるのが基本的な流れとなります。
duコマンドの基本｜ディレクトリやファイルごとの使用量を確認
サーバーで容量不足の兆候を確認したら、次に必要になるのは「どのディレクトリやファイルが容量を消費しているのか」を特定することです。ここで活躍するのが du コマンドです。du はディレクトリやファイル単位で使用量を表示するため、容量の原因を深掘りするのに欠かせません。
基本構文と使い方
du の最もシンプルな使い方は以下の通りです。
du /path/to/dir
これで指定したディレクトリ以下の容量をブロック単位で表示します。ただしデフォルトの出力は詳細すぎて見づらいため、実務ではオプションを組み合わせるのが一般的です。
よく使うオプション
-h: サイズをKB/MB/GBで見やすく表示-s: 合計だけを表示（サマリ表示）--max-depth=N: 指定した階層までを表示
例えば以下のコマンドは、直下ディレクトリごとの使用量を見やすく表示します。
du -h --max-depth=1 /var
この結果により、/var/log なのか /var/lib なのかといった具合に、どのサブディレクトリが容量を消費しているかをすぐに判断できます。
実務での活用例
- ログ肥大化の調査：
du -sh /var/log/*を実行して、どのログが容量を占有しているかを特定する。 - ユーザーディレクトリの利用状況把握：
du -sh /home/*でユーザーごとの容量使用量を一覧化。 - 一時ファイルの調査：
/tmpやアプリケーション固有のキャッシュディレクトリを調べることで、不要データの蓄積を早期に発見。
注意点
du はファイルやディレクトリを走査して計算するため、ディレクトリが大きい場合は実行に時間がかかることがあります。また、実行時点でアクセスできないファイルやマウントポイントは結果に含まれない場合もあるため、調査範囲を適切に指定することが重要です。
このように du を使えば、全体容量を確認する df では見えなかった「どこが容量を使っているのか」を具体的に把握できるようになります。容量不足を解決するための実務調査の中核となるコマンドです。
dfとduの違いと使い分け
df と du はどちらもディスク使用量を確認するためのコマンドですが、役割と視点が異なります。その違いを理解しておくことで、トラブル対応や容量調査を効率的に進められます。
dfコマンドの特徴
df はファイルシステム単位での使用量を表示します。どのパーティションにどれだけの空き容量があるかを瞬時に確認できるため、サーバー全体の健康状態を把握する第一歩に最適です。特に「空き容量が残り何％か」を監視する場面では欠かせません。
duコマンドの特徴
一方で du はディレクトリやファイル単位の使用量を表示します。あるパーティションの中で「どのフォルダが容量を圧迫しているのか」を調べたいときに使います。容量不足の原因を深掘りする調査に有効です。
表示が一致しないケース
サーバー管理をしていると、df と du の結果が一致しないことがあります。代表的な理由は以下の通りです。
- 削除済みファイルがプロセスに掴まれている
例えばログファイルを削除しても、プロセスがファイルディスクリプタを保持したままだとduには表示されず、dfでは容量が解放されないまま残ります。lsofコマンドで確認すると原因を特定できます。 - マウントポイントの違い
duは指定したディレクトリ配下を走査しますが、別のファイルシステムがマウントされている場合はカウントに含めないことがあります。そのためdfの合計と差が生じる場合があります。
実務での使い分け
- 全体の空き容量をチェックする →
df - どのディレクトリが肥大化しているか調べる →
du - 結果が食い違うときに原因を追及する →
lsofやマウント状況を確認
このように両者の特徴を理解して正しく使い分けることで、単純な確認から原因追及までスムーズに進めることができます。サーバー運用においては、まず df で全体を俯瞰し、次に du で詳細を掘り下げるという流れが基本となります。
容量不足の原因を特定する実践手順
サーバーで「ディスクがいっぱい」という状況に直面した場合、闇雲にファイルを削除するのは危険です。まずは体系的に原因を特定し、不要なデータを安全に整理することが求められます。ここでは df と du を組み合わせた実践的な手順を紹介します。
ステップ1：全体の容量を確認する
まずはサーバー全体の使用状況を把握します。
df -h
これで「どのパーティションに空きがないのか」が分かります。例えば / が90%以上使用されていれば、ルートファイルシステム内を重点的に調査すべきと判断できます。
ステップ2：大きなディレクトリを洗い出す
次に du を使って、容量を消費しているディレクトリを特定します。
du -sh /* 2>/dev/null
このコマンドでルート直下のディレクトリの容量を一覧表示できます。大きい順に並べたい場合は sort を組み合わせると便利です。
du -sh /* 2>/dev/null | sort -h
これにより /var や /home など、特に容量を消費している領域をすぐに特定できます。
ステップ3：重点ディレクトリを深掘りする
容量を圧迫しているディレクトリが見つかったら、さらに階層を掘り下げます。
du -sh /var/* | sort -h
これで /var/log や /var/lib のように、原因となっているサブディレクトリを明確にできます。
ステップ4：ログや一時ファイルを調査する
実務でよくあるのはログや一時ファイルの肥大化です。以下のコマンドで詳細を確認できます。
du -sh /var/log/*
du -sh /tmp/*
予期せぬ大量ログや削除し忘れた一時ファイルが見つかることも多いです。
ステップ5：削除・整理の判断
不要なファイルを削除する前に、業務上必要かどうか必ず確認します。削除してはいけないシステムファイルや重要ログを誤って消すと、復旧困難な障害に繋がる可能性があります。ログの場合は圧縮（gzip）やローテーション設定を見直すことが推奨されます。
このように段階的に調査することで、効率的かつ安全に容量不足の原因を突き止めることができます。
大容量ファイルを探すテクニック
ディスク使用量が逼迫しているとき、原因の多くは少数の巨大ファイルです。どのファイルが容量を食っているのかを迅速に特定できれば、不要なものを削除したり、アーカイブ先に移動したりする判断がしやすくなります。ここでは代表的な調査方法を紹介します。
duとsortを組み合わせる
du コマンドはディレクトリ単位だけでなく、ファイル単位の容量も表示できます。そこに sort と tail を組み合わせると、大きなファイルをランキング形式で抽出可能です。
du -ah /var | sort -h | tail -n 20
このコマンドは /var 以下のファイル・ディレクトリをサイズ順に並べ、上位20件を表示します。ログファイルやキャッシュが異常に肥大化している場合、すぐに把握できます。
findコマンドで巨大ファイルを検索
find コマンドは条件指定が可能で、特定サイズ以上のファイルだけを探すのに適しています。
find / -type f -size +1G
これで1GB以上のファイルを全体から検索できます。ディスク全体を走査するため時間はかかりますが、巨大ファイルを漏れなく抽出できる方法です。
実務でよくあるケース
- 誤って残されたバックアップ：古いデータベースのダンプやアーカイブファイルが数十GB単位で残っている。
- コアダンプファイル：アプリケーションの異常終了時に生成される
coreファイルが容量を圧迫する。 - キャッシュや一時ファイル：アプリのキャッシュディレクトリや
/tmp内の不要ファイルが整理されず蓄積している。
調査のコツ
- まず
duで大きなディレクトリを特定し、次にfindで巨大ファイルを抽出する流れが効率的。 - 不要と判断する前に、中身や生成元を必ず確認すること。特にバックアップやログは削除前に別ストレージへ退避させるのが安全です。
このようなテクニックを駆使することで、容量不足の直接的な原因を素早く突き止めることができます。
定期監視・自動化のポイント
ディスク使用量の調査は突発的なトラブル時だけでなく、日常的な監視サイクルに組み込むことが重要です。容量不足は気づいたときにはすでにサービスに影響が出ているケースが多いため、定期的に自動チェックを行う仕組みを整えておくと安心です。
cronで定期実行する
もっとも手軽な方法は cron を使って df や du を定期的に実行し、結果をログやメールで受け取る方法です。
0 6 * * * df -h > /var/log/df_check.log
この設定では毎朝6時に df -h の結果を保存できます。さらに mail コマンドと組み合わせれば、管理者にメールで送信することも可能です。
duによる履歴管理
特定ディレクトリの容量推移を記録しておけば、異常な増加を早期に察知できます。
du -sh /var/log >> /var/log/logdir_usage.log
ログファイルに追記していくことで、グラフ化やトレンド分析も容易になります。
外部監視ツールとの連携
Nagios、Zabbix、Prometheus などの監視ツールでは、ディスク容量チェックのテンプレートが用意されています。これらを導入することで、閾値を超えた時点で即座にメールやSlack通知を飛ばせます。インフラが複数台にわたる場合や大規模環境では、監視ツールの利用が必須と言えるでしょう。
アラートの設計ポイント
- 警告レベル：70%超過で注意喚起
- 危険レベル：90%超過で緊急対応
- 通知チャネルはメールだけでなく、チャットツールやアラート管理サービス（Opsgenie, PagerDutyなど）に接続すると実運用で便利です。
このように監視・自動化を組み合わせることで、「気づいたら容量ゼロ」という致命的な事態を避けられます。人手に頼らずシステムで継続的にチェックする仕組みが、安定したサーバー運用の基盤になります。
容量トラブルを未然に防ぐ運用Tips
ディスク容量は一度不足してしまうと復旧に時間がかかり、サービス停止につながるリスクが高まります。そのため、日常的に予防策を講じておくことが非常に重要です。ここではサーバー管理者が実務で役立つ運用の工夫を紹介します。
ログローテーションの徹底
ログファイルの肥大化は容量不足の代表的な原因です。logrotate を設定すれば、定期的にログを圧縮・削除し、保存世代数も制御できます。特にアクセスログやエラーログは生成量が多いため、日次・週次でのローテーション設定を推奨します。
一時ファイルの自動削除
/tmp やアプリケーションのキャッシュディレクトリにファイルが溜まり続けると、数GB単位の無駄な容量消費につながります。tmpfiles.d の設定や cron スクリプトを用いて、古いファイルを自動削除する仕組みを導入しておきましょう。
バックアップの整理
バックアップは必要不可欠ですが、古い世代を無制限に残すとストレージを圧迫します。世代管理ルールを決め、一定期間を過ぎたものは削除または外部ストレージに移動することが望ましいです。特にフルバックアップと差分バックアップを組み合わせて効率化するのが実務的です。
容量監視の閾値設定
定期監視を行う際は、空き容量が70％を切った時点で警告、90％を超えたら緊急通知、といったルールを設定すると効果的です。メール通知に加えて Slack や Teams への連携を行えば、チーム全体で迅速に対応できます。
不要データの定期チェック
- 古いログやバックアップの削除
- テスト用に作成した大容量ファイルの整理
- アプリのキャッシュクリア
これらを月次・週次の運用フローに組み込むことで、容量不足のリスクを最小化できます。
このような日常的な対策を積み重ねていくことで、トラブル発生を未然に防ぎ、サーバーを安定して運用できるようになります。容量確認は単発の作業ではなく、継続的な管理の一環として捉えることが大切です。
参考・参照リンク
Linuxでのディスク使用量確認や運用管理について、さらに詳しく学びたい場合に役立つ外部リソースをまとめました。
- GNU Coreutils: df マニュアル
- GNU Coreutils: du マニュアル
- Linux man pages — df(1)
- Linux man pages — du(1)
- logrotate — Linux man page
- Zabbix公式ドキュメント — ディスク監視
これらのリンク先を活用すれば、df・du の詳細な仕様や実践的な監視設定について、さらに深い理解が得られます。
コメント