ディスク容量が不足した

ディスクが満杯になると、すべてが一斉に壊れます。データベースは書き込みを受け付けなくなり、サイトはエラーを返し、journalctl は動作を拒否し、セッションログに書き込む領域が残っていないため SSH でさえ入れなくなることがあります。素早く、順番に行動する必要があります。

確認

df -h
df -i

最初のコマンドは容量を、2 番目は inode を表示します。inode が満杯になると、ギガバイトの空きがあっても同じ「No space left on device」エラーが発生します。これは、ディレクトリに何百万もの小さなファイル（PHP セッション、キャッシュ、キュー）が蓄積された場合に起こります。

使用容量はパネルの /hosting/vds/m/<id>、「概要」タブのリングでも確認できます。これは qemu-guest-agent から報告されたデータで埋まります。エージェントが削除されている場合、リングは空のままで、パネルには代わりにインストールコマンドが表示されます。

原因を特定する

du -xh --max-depth=1 / 2>/dev/null | sort -h | tail -15
du -xh --max-depth=1 /var 2>/dev/null | sort -h | tail -15
ncdu -x /                     # apt install ncdu, interactive
find / -xdev -type f -size +500M -exec ls -lh {} \; 2>/dev/null

-x フラグは検索を単一のファイルシステム内に留め、/proc やマウントされたディレクトリへさまよい込むのを防ぎます。

典型的な原因は、/var/log のログ、/var/cache のパッケージキャッシュ、/var/lib/docker の Docker イメージとボリューム、データベースダンプ、/root や /tmp に忘れられたアーカイブ、古いアプリケーションリリースのファイルです。

容量を解放する

journalctl --vacuum-size=200M
apt clean                                   # Debian, Ubuntu
dnf clean all                               # AlmaLinux, CentOS Stream
docker system prune -af --volumes           # careful: will remove unused volumes
find /tmp -type f -mtime +7 -delete

journal を恒久的に制限するには、/etc/systemd/journald.conf を編集します（SystemMaxUse=300M）。詳細は記事 systemd ジャーナル を参照してください。アプリケーションのファイルには logrotate を設定します。ローテーションがなければ、1 つの app.log が簡単に数十ギガバイトまで膨れ上がります。

罠：削除されたがまだ開かれているファイル

巨大なログを削除したのに、df は同じ数値を表示します。プロセスがファイルを開いている限り、容量は返されません。

lsof +L1 | head -20

正しい対処は、ファイルを保持しているサービスを再起動する（systemctl restart nginx）か、ファイルを削除せずに切り詰めることです。

: > /var/log/nginx/access.log

罠：inode の枯渇

df -i
find /var/www -xdev -type d -printf '%h\n' | sort | uniq -c | sort -rn | head

数十万のファイルがあるディレクトリを探し、マシンを落とさないように分割してクリーンアップします。

find /var/lib/php/sessions -type f -mtime +2 -delete

まったく空きがない場合

ディスクが 100% 満杯でシステムがほとんど動かない場合は、パネルの「コンソール」タブからログインし、少なくとも 100 メガバイトを解放して（journalctl --vacuum-size=50M はほぼ確実に機能します）、通常どおりトラブルシューティングを続けます。本当に深刻な場合は、レスキューディスク が役立ちます。マシンは SystemRescue で起動し、ディスクは /dev/sda として表示され、それをマウントして外部からクリーンアップできます。

再発を防ぐために

• 85% のしきい値でアラート — サイトダウンタイムアラート を参照してください。
• システムのログだけでなく、すべてのアプリケーションログをローテーションします。
• データベースダンプとアーカイブは /root に置いておかず、すぐにサーバー外へ送ります。
• クリーンアップするものがなくなり、データが増え続ける場合は、より大きなディスクのティアに移行します：40、80、120、160、200、250 GB。アップグレードのみ可能です。ディスクは縮小できず、ダウングレードは利用できません。

/var/lib と /usr からファイルを無作為に削除しないでください。そこにはデータベースのデータとシステムパッケージがあります。まずディレクトリが何に属しているかを把握し、それからクリーンアップしてください。