ディスク空き容量を素早く確認して容量枯渇を未然に防ぐ実務手順

まず結論：この1コマンドで全体を把握する

ディスク空き容量をサーバー全体で一覧確認するには、df -h が最短です。マウント済みのすべてのファイルシステムを人間が読みやすい単位（MB・GB）で表示します。

df -h

出力例（Ubuntu 24.04 / Rocky Linux 9 などの現行ディストリ共通）：

Filesystem       Size  Used Avail Use% Mounted on
/dev/sda3        145G  5.1G  132G   4% /
/dev/sda1         45M  6.6M   36M  16% /boot
tmpfs            500M     0  500M   0% /dev/shm
/dev/nvme0n1p1   476G   98G  354G  21% /data

Use%（使用率）が 80% を超えたら注意サイン、90% を超えるとアプリケーションがエラーを返し始めるケースが多いです。NVMe SSD 搭載サーバーではデバイス名が /dev/nvme0n1p* 形式になります。古い資料に載っている /dev/hda（IDE接続）は現在の環境ではほぼ見かけません。

出力の各列を正しく読む

オプションを組み合わせると、確認できる情報の粒度が上がります。

# 特定のパスが属するファイルシステムだけを確認
df -h /var

# ファイルシステムの種別（ext4 / xfs / btrfs など）も一緒に表示
df -hT

-T オプションを付けると ext4・xfs・btrfs・tmpfs などの種別が確認できます。tmpfs（/dev/shm や /run）は RAM 上に展開されるため、物理ディスクの残量には関係ありません。混在している環境では種別を確認してから判断するのが確実です。

df -h /var/log のようにパスを指定すると、そのパスが乗っているファイルシステムの情報だけを取り出せます。「ログが膨らんでいるパーティションはどれか」を素早く切り分けるのに便利です。

「空きがあるのに書き込めない」— inode の枯渇も確認する

ディスク容量には余裕があるのにファイルを作成できない、というトラブルが現場でときどき発生します。原因の多くは inode（アイノード）の枯渇です。inode はファイルのメタ情報を管理する領域で、ファイル数が極端に多い環境（PHPセッションファイル・メールスプール・一時キャッシュの大量蓄積など）では、容量より先に inode が尽きることがあります。

# inode の使用状況を確認（-i オプション）
df -ih

出力例：

Filesystem      Inodes IUsed IFree IUse% Mounted on
/dev/sda3         9.2M  450K  8.7M    5% /
/dev/sda1          32K   300   31K    1% /boot
tmpfs             125K   800  124K    1% /dev/shm

IUse% が 100% に達すると、そのファイルシステムには新規ファイルを一切作れなくなります。df -h で容量の空きを確認するのと合わせて df -ih も習慣的にチェックしておくと、このトラブルの大半を事前に防げます。

どのディレクトリが容量を食っているかを特定する

df でパーティション全体の使用率は分かりますが、「どのディレクトリが原因か」を掘り下げるには du コマンドを使います。

# /var 以下のディレクトリ別容量をサイズ降順で上位20件表示
du -sh /var/* 2>/dev/null | sort -rh | head -20

ログが肥大化していれば /var/log、パッケージキャッシュなら /var/cache/apt（Debian/Ubuntu 系）や /var/cache/dnf（RHEL 系）が上位に現れます。

systemd 環境では journald がログを /var/log/journal/ 以下に蓄積するため、専用コマンドで確認・削減できます。

# journald が占有しているディスク容量を確認
journalctl --disk-usage

# 直近2週間以外の古いジャーナルログを削除
sudo journalctl --vacuum-time=2weeks

# サイズ上限を指定して削減（例：500MB 以下に収める）
sudo journalctl --vacuum-size=500M

注意：du は再帰的にディレクトリを走査するため、大きなディレクトリに対して実行すると完了まで時間がかかり、I/O 負荷も上がります。本番サーバーで実行する際はピーク時間帯を避けてください。

定期確認・アラートの仕組みを作る

手動確認だけでは見落としが起きます。ある運用現場では週末のログ爆発を見逃した結果、月曜朝にデータベースの書き込みが止まるインシデントが発生しました。以下のワンライナーをベースに自動検出の仕組みを作っておくことをお勧めします。

# 使用率が 80% を超えたパーティションだけを抽出して表示
df -h | awk 'NR>1 && int($5) >= 80 {print $0}'

これを cron や systemd timer で定期実行し、出力があった場合にメール・Slack 通知を送る構成にすると、閾値超えを自動検出できます。

#!/bin/bash
# /etc/cron.daily/disk-alert として保存し chmod +x を付与して使う
THRESHOLD=80
RESULT=$(df -h | awk -v t="$THRESHOLD" 'NR>1 && int($5) >= t {print $0}')
if [ -n "$RESULT" ]; then
  echo "$RESULT" | mail -s "[ALERT] Disk usage over ${THRESHOLD}% on $(hostname)" admin@example.com
fi

環境差の注意：メール送信には mailutils（Debian/Ubuntu 系）または mailx（RHEL 系）のインストールが別途必要です。Prometheus + Grafana や Zabbix などの監視基盤がある環境では、node_exporter のディスク使用率メトリクスをそのまま流用するのが現実的です。

また、ジャーナルログの肥大化を根本から防ぐには /etc/systemd/journald.conf に上限値を設定しておく方法が有効です。

# /etc/systemd/journald.conf に追記（例：上限を 500MB に設定）
[Journal]
SystemMaxUse=500M

# 設定を反映
sudo systemctl restart systemd-journald

# 反映後の確認
journalctl --disk-usage

この設定を入れておくだけで、長期間放置したサーバーのジャーナルが際限なく膨らむ事態を防げます。df -h による日常確認と合わせて、最初にやっておきたい設定のひとつです。