突然のエラー！サーバーが容量パンク寸前？
こんにちは！「リナックス先生」です。
突然ですが、VPSを運用していて「ファイルが保存できない」「データベースが起動しない」といったトラブルに遭ったことはありませんか？
先生、大変です！
WordPressの記事を更新しようとしたら「更新に失敗しました」って出るんです。
ターミナルで何かコマンドを打っても No space left on device って言われてタブ補完すら効きません！
それは「ディスク容量不足」のエラーね。
格安VPSの20GB〜50GBなんて、ログやバックアップであっという間に埋まってしまうわ。
でも焦らないで。「どこが肥大化しているか」を特定して掃除すれば、必ず復旧できるわよ！
1. 調査編：何が容量を食っているのか？
闇雲にファイルを消す前に、まずは「現状把握」が鉄則です。No space left on device の原因は、実は2種類あります。
① ディスク容量自体の不足（df -h）
まずは基本の容量チェックです。
[root@localhost ~]# df -h Filesystem Size Used Avail Use% Mounted on /dev/vda2 30G 30G 0G 100% / <-- ここが100%なら「容量不足」 devtmpfs 456M 0 456M 0% /dev
Use% が100%になっていれば、巨大なファイルがディスクを圧迫しています。後述の手順で削除しましょう。
② ファイル数の上限「Inode」の枯渇（df -i）
「容量は空いているのにエラーが出る」という場合は、これです。
Linuxには保存できるファイルの個数（Inode）に上限があります。小さなファイル（メールやキャッシュなど）が数百万個あると、容量がスカスカでも書き込めなくなります。
[root@localhost ~]# df -i Filesystem Inodes IUsed IFree IUse% Mounted on /dev/vda2 1966080 1966080 0 100% / <-- これが「Inode枯渇」！
IUse% が100%の場合、不要な「大量の小ファイル」を削除する必要があります。
犯人（巨大ディレクトリ）の特定
容量不足の場合、以下のコマンドで「どこが重いか」をランキング形式で特定します。
# ルート直下のディレクトリ容量を表示（処理に少し時間がかかります） [root@localhost ~]# du -sh /* 2>/dev/null | sort -hr 15G /var <-- 怪しい 5.2G /usr 2.1G /home ...
/var が大きい場合、さらに中を調べます。
[root@localhost ~]# du -sh /var/* 2>/dev/null | sort -hr 10G /var/log <-- ログファイルが犯人！ 4.5G /var/lib <-- データベース等が犯人！
2. 解決編①：巨大ログファイルの安全な削除
/var/log が肥大化している場合、システムログやWebサーバーログが原因です。
Apacheログの掃除方法
WordPressなどのWebサイトを運営していると、アクセスログが数GBになることがあります。
# ディレクトリ移動 [root@localhost ~]# cd /var/log/httpd/ # サイズ確認 [root@localhost httpd]# ls -lh # 古いログ（日付がついたもの）は削除してOK [root@localhost httpd]# rm access_log-202* error_log-202*
【重要】稼働中ログの安全な消し方
現在書き込み中のファイル（access_log など日付がないもの）を rm で削除するのは危険です。
ファイル自体は消えても、Apacheプロセスがファイルを掴んだまま離さず、「ファイルは見えないのに容量が空かない」というゾンビ状態になります。
稼働中のログを消したい場合は、中身だけを空にします。
# ファイルの中身を空にするコマンド [root@localhost httpd]# echo "" > access_log [root@localhost httpd]# echo "" > error_log
システムジャーナル（journald）の掃除
Linux自体の操作ログも肥大化しがちです。専用コマンドで掃除します。
# 現在の消費量を確認 [root@localhost ~]# journalctl --disk-usage # 100MB以下になるように古いものを削除 [root@localhost ~]# journalctl --vacuum-size=100M
3. 解決編②：DBバイナリログの削除
/var/lib/mysql が肥大化している場合、MySQL/MariaDBの「バイナリログ（binlog）」が犯人の可能性が高いです。
これはDBの変更履歴を記録するファイルで、放っておくと無制限に増え続けます。
バイナリログの確認と削除
# ファイル確認 [root@localhost ~]# ls -lh /var/lib/mysql/mysql-bin.* -rw-rw---- 1 mysql mysql 1.1G ... mysql-bin.000001 -rw-rw---- 1 mysql mysql 1.1G ... mysql-bin.000002
これらを削除するには、必ずMySQLにログインしてコマンドで消します（rmコマンドはNG）。
# MySQLにログイン [root@localhost ~]# mysql -u root -p # 現在より前のバイナリログを全削除 MariaDB [(none)]> PURGE BINARY LOGS BEFORE NOW();
【再発防止策】
設定ファイル（/etc/my.cnf.d/server.cnf 等）に有効期限を設定しておきましょう。
[mysqld] # ログ保存期間を7日に制限 expire_logs_days = 7
4. 解決編③：パッケージキャッシュの削除
dnf や yum でアップデートした際の一時ファイルも数GB溜まることがあります。
# キャッシュを全削除 [root@localhost ~]# dnf clean all
5. それでも解決しない場合：プロセスの確認
「ファイルを大量に消したのに df -h の容量が減らない！」
そんな時は、削除されたファイルをプロセスがまだ掴んでいる可能性があります。
# 削除されたのに掴まれているファイルを探す [root@localhost ~]# lsof | grep deleted httpd 1234 root 4w REG 253,1 1073741824 ... /var/log/httpd/access_log (deleted)
このような表示が出たら、該当のプロセス（上記ならhttpd）を再起動することで、完全に開放されます。
[root@localhost ~]# systemctl restart httpd
まとめ：定期的な「断捨離」を忘れずに
VPSはメンテナンスフリーではありません。
今回紹介したコマンドを使えば一時的な復旧は可能ですが、運用を続ける限り再び容量不足は発生します。
ありがとうございます！
MySQLのログだけで10GBもありました…！
これを消したらサクサク動くようになりました！
それは良かったわ。
でも、頻繁に掃除が必要なら、それはサーバーのスペック不足のサインかもね。
労力をかけるコストと、サーバー代を天秤にかけて考えるのもエンジニアの仕事よ。
▼大容量でも安いVPSを探すなら
「20GBや30GBじゃ足りない！」「画像をもっとたくさん保存したい」という方は、ストレージ容量あたりのコスパが良いVPSを選ぶのがおすすめです。
以下の記事で、スペックと価格を徹底比較しています。
▼管理が面倒ならレンタルサーバーも検討を
「コマンドで掃除するのは大変…」「容量を気にせず使いたい」という方は、レンタルサーバーがおすすめです。
月額数百円で300GB以上使えるプランもあり、運用コストを大幅に下げられます。
コメント