状況の説明
デプロイの途中、ビルドの途中、再起動の途中——突然すべてが止まります：
No space left on device
書き込みが失敗し、ログが止まり、データベースが落ちる。朗報は、どこを見ればいいか分かれば、たいてい5分以内に復旧できるということです。
原因の特定——実際に何が満杯かを調べる
ステップ1：ディスク使用量の全体確認
df -h
**Use%**列をチェックしてください。100%に達している、または近い値があれば、そこが問題です。9割のケースで/（ルート）パーティションが原因です。
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 50G 50G 0 100% /
tmpfs 2.0G 1.2G 800M 60% /dev/shm
ステップ2：inode使用量の確認——見落としがちなポイント
ディスクの空き容量がギガバイト単位で残っていても、inodeが完全に枯渇しているケースがあります。PHPのセッションファイル、メールキュー、Node.jsのキャッシュディレクトリはその典型例で、単一のアプリが数百万もの小さなファイルを生成することがあります。
df -i
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/sda1 3276800 3276800 0 100% /
IUse%が100%の場合、大きなファイルを探すのではなく、大量の小さなファイルを削除する必要があります。
ステップ3：容量を圧迫している場所を特定する
ルートから始めて、問題の原因を見つけるまで掘り下げていきます：
# トップレベル——どこに大きなデータがあるか確認
du -sh /* 2>/dev/null | sort -rh | head -20
# 絞り込む
du -sh /var/* 2>/dev/null | sort -rh | head -20
du -sh /var/log/* 2>/dev/null | sort -rh | head -20
稼働中のサーバーでは、/var/logが一晩で20〜30 GBに膨らむことも珍しくありません。
即時対処——今すぐ空き容量を確保する
古いログを削除する
# 実行中のプロセスに影響を与えずに大きなログファイルを空にする
> /var/log/syslog
> /var/log/auth.log
# systemdのジャーナルログを100MBに削減
journalctl --vacuum-size=100M
# または7日より古いログを削除
journalctl --vacuum-time=7d
古いパッケージキャッシュを削除する
# Debian/Ubuntu——500MBから2GBほど解放されることが多い
apt clean
apt autoremove -y
# RHEL/CentOS
yum clean all
dnf clean all
古いカーネルイメージを削除する（Ubuntu/Debian）
アップデートのたびに古いカーネルが蓄積されます。1つあたり約200〜400 MBを占有します。インストール済みのものを確認してから、aptで自動整理しましょう：
dpkg --list | grep linux-image
# 古いカーネルを自動削除（現在のものと1つ前を残す）
apt autoremove --purge
大きなファイルを手動で探す
# 100MB以上のファイルを検索
find / -type f -size +100M 2>/dev/null
# コアダンプ——1つで数GB以上になることがある
find / -name "core" -type f 2>/dev/null
find /var/crash -type f 2>/dev/null
Dockerが容量を使っている場合
# 未使用のイメージ、停止済みコンテナ、未使用ボリュームを削除
docker system prune -a --volumes
開発環境では、Dockerがいつの間にか20〜40 GBを消費していることがあります。まず確認する価値があります。
見落としやすい原因：削除済みファイルがプロセスに保持されている
ファイルを削除した後でも、プロセスがファイルディスクリプタを開いたまま保持していることがあります。そのプロセスが再起動するまでディスク容量は解放されません。以下のコマンドで確認できます：
lsof | grep deleted | sort -k7 -rn | head -20
7列目にファイルサイズが表示されます。上位に表示されたサービスを再起動してください：
systemctl restart nginx # 実際のサービス名に置き換えてください
恒久的な対策——再発を防ぐ
アプリケーションのログローテーションを設定する
/etc/logrotate.confと/etc/logrotate.d/を確認してください。アプリが独自のログを書き出している場合は、以下のような設定を追加します：
/var/log/myapp/*.log {
daily
rotate 7
compress
missingok
notifempty
delaycompress
}
journaldの上限を設定して肥大化を防ぐ
/etc/systemd/journald.confを編集します：
[Journal]
SystemMaxUse=500M
SystemKeepFree=1G
systemctl restart systemd-journald
緊急事態になる前にディスクアラートを設定する
# ディスク使用率が80%を超えたらメールを送信
*/10 * * * * root df -h / | awk 'NR==2 {gsub("%","",$5); if($5>80) print "Disk usage: "$5"%" | "mail -s \"Disk Alert\" admin@example.com"}'
80%でアラートを受け取れば対処する時間があります。100%になってから通知を受けるのでは、すでに手遅れです。
パーティションを拡張する（容量が足りなくなった場合）
VMやクラウドインスタンスの場合は、まずプロバイダーのコンソールでボリュームをリサイズしてから、ファイルシステムを拡張します：
# ext4
resize2fs /dev/sda1
# xfs
xfs_growfs /
# 確認
df -h /
修正の確認
# 空き容量は戻ったか？
df -h
# inodeは戻ったか？
df -i
# 書き込みテスト——終了コード0なら成功
dd if=/dev/zero of=/tmp/test_write bs=1M count=10 && rm /tmp/test_write
echo $?
書き込みが成功し、df -hで余裕が確認できれば完了です。
クイックリファレンス チェックリスト
df -h— どのパーティションが満杯か確認df -i— inodeの枯渇を確認du -sh /* | sort -rh— 大きなディレクトリを特定lsof | grep deleted— プロセスに保持されたファイルを確認journalctl --vacuum-size=100M— systemdログのトリミングapt clean && apt autoremove— パッケージキャッシュ削除（Debian/Ubuntu）docker system prune -a— Dockerが関係している場合