サーバー容量不足でサイトが突然停止した時の緊急対処法と、再発防止のための監視設定を実践的に解説します。
サイトが突然動かなくなった！その原因はサーバー容量不足かも
「朝一番でサイトをチェックしたら、表示されない...」「昨日まで正常だったのに、なぜか管理画面にログインできない」
こんな経験をされたことはありませんか？
神奈川でWeb制作を20年以上手がけてきた私たちFivenine Designでは、このようなサーバートラブルの緊急対応を数多く経験してきました。その中でも特に多いのがサーバー容量不足による障害です。
実際に、あるクライアントから「ECサイトが表示されない！売上に直結するので今すぐ復旧してほしい」という緊急連絡を受けたことがあります。調査したところ、サーバー容量が99%に達しており、新しいファイルを書き込めない状態になっていました。幸い迅速な対応で30分ほどで復旧できましたが、もし対処法を知らなければ、数時間〜数日の停止につながっていたかもしれません。
この記事では、そんな緊急事態での対処法と、二度と同じ問題を起こさないための予防策を、実際の案件で培ったノウハウをもとに詳しく解説します。
なぜサーバー容量不足が起こるのか？主な原因を理解する
よくある容量圧迫の原因
サーバー容量が突然99%になる背景には、いくつかの典型的なパターンがあります。
1. ログファイルの肥大化 Webサーバーやアプリケーションが出力するログファイルが蓄積され続け、気づいたときには数GBになっているケースです。特にWordPressのデバッグログや、Laravelのアプリケーションログは放置すると急激に増大します。
2. 画像・動画ファイルの蓄積 CMSで記事投稿を続けていると、アップロードした画像や動画が蓄積されます。特に高画質の画像を多数扱うサイトでは、容量消費が想像以上に早く進みます。
3. バックアップファイルの重複 自動バックアップ機能を設定したものの、古いバックアップが削除されずに残り続けているパターンです。データベースの完全バックアップを毎日取得していると、1ヶ月で相当な容量を消費します。
4. 一時ファイルの残存 アプリケーションが作成した一時ファイルやキャッシュファイルが正常に削除されず、蓄積されるケースもあります。
容量不足が引き起こす具体的な症状
容量不足になると、以下のような症状が現れます：
- サイトが表示されない（500エラー）
- 管理画面にログインできない
- ファイルのアップロードができない
- データベースへの書き込みエラー
- メール送信の失敗
これらの症状が複合的に発生すると、ビジネスに深刻な影響を与えかねません。
【緊急対応】サーバー容量99%からの復旧手順
ステップ1: 現在の容量状況を確認する
まず、サーバーにSSH接続して現在の状況を把握します：
# ディスク使用量の確認
df -h
# 容量を消費している大きなファイル・ディレクトリを特定
du -sh /* | sort -hr | head -20
df -hコマンドで、どのパーティションが満杯になっているかを確認できます。通常、/（ルート）パーティションが99%や100%になっていることが多いです。
ステップ2: 緊急容量確保の実施
A. ログファイルの削除・圧縮
# Webサーバーのログをチェック
ls -lah /var/log/nginx/
ls -lah /var/log/apache2/
# 古いログファイルを圧縮・削除
sudo find /var/log -name "*.log" -type f -mtime +7 -exec gzip {} \;
sudo find /var/log -name "*.gz" -type f -mtime +30 -delete
# WordPressのデバッグログを確認・削除
find /path/to/wordpress -name "debug.log" -exec ls -lah {} \;
find /path/to/wordpress -name "debug.log" -delete
B. アプリケーションのログ削除（Laravel例）
# Laravelのログファイル確認
ls -lah /path/to/laravel/storage/logs/
# 古いログファイルを削除
find /path/to/laravel/storage/logs -name "*.log" -mtime +30 -delete
# 現在のログファイルをクリア（空にする）
echo '' > /path/to/laravel/storage/logs/laravel.log
C. 一時ファイルとキャッシュの削除
# システムの一時ファイル削除
sudo find /tmp -type f -mtime +7 -delete
# アプリケーションのキャッシュ削除（Laravel例）
cd /path/to/laravel
php artisan cache:clear
php artisan view:clear
php artisan config:clear
ステップ3: 古いバックアップファイルの整理
# バックアップディレクトリの確認
ls -lah /backup/
ls -lah /home/backup/
# 30日以上古いバックアップを削除
find /backup -name "*.sql.gz" -mtime +30 -delete
find /backup -name "*.tar.gz" -mtime +30 -delete
ステップ4: 復旧確認とサービス再起動
# 容量確認
df -h
# Webサーバーの再起動
sudo systemctl restart nginx
# または
sudo systemctl restart apache2
# PHP-FPMの再起動（必要に応じて）
sudo systemctl restart php8.1-fpm
実際の案件では、上記の手順で平均15〜30分程度で復旧できています。ログファイルの削除だけで50〜80%の容量を確保できることが多いです。
予防が重要！監視・アラート設定の実装
緊急対応で復旧できても、根本的な解決にはなりません。重要なのは予防的な監視体制の構築です。
自動監視スクリプトの作成
容量使用率を定期的にチェックし、閾値を超えた場合にアラートを送信するスクリプトを作成します：
#!/bin/bash
# disk_monitor.sh
# 設定
THRESHOLD=80 # 警告を出す使用率（%）
EMAIL="[email protected]"
LOGFILE="/var/log/disk_monitor.log"
# 現在の使用率を取得
USAGE=$(df / | tail -1 | awk '{print $5}' | sed 's/%//')
# ログ出力
echo "$(date): Disk usage: ${USAGE}%" >> $LOGFILE
# 閾値チェック
if [ $USAGE -ge $THRESHOLD ]; then
SUBJECT="[ALERT] Server disk usage: ${USAGE}%"
MESSAGE="Warning: Disk usage on $(hostname) has reached ${USAGE}%"
# メール送信
echo "$MESSAGE" | mail -s "$SUBJECT" $EMAIL
# ログに記録
echo "$(date): ALERT SENT - Disk usage: ${USAGE}%" >> $LOGFILE
fi
crontabでの定期実行設定
# crontabの編集
crontab -e
# 15分ごとにチェック
*/15 * * * * /path/to/disk_monitor.sh
# ログローテーション（週次でログファイルを圧縮）
0 0 * * 0 find /var/log -name "*.log" -mtime +7 -exec gzip {} \;
# 古いバックアップの自動削除（月次）
0 2 1 * * find /backup -name "*.gz" -mtime +60 -delete
Laravelアプリケーション向け監視コマンドの作成
Laravelプロジェクトでは、Artisanコマンドとして監視機能を実装することも可能です：
<?php
// app/Console/Commands/MonitorDiskSpace.php
namespace App\Console\Commands;
use Illuminate\Console\Command;
use Illuminate\Support\Facades\Mail;
use Illuminate\Support\Facades\Log;
class MonitorDiskSpace extends Command
{
protected $signature = 'monitor:disk';
protected $description = 'Monitor disk space usage';
public function handle()
{
$usage = $this->getDiskUsage();
$threshold = 80;
Log::info("Disk usage check: {$usage}%");
if ($usage >= $threshold) {
$this->sendAlert($usage);
$this->warn("Alert sent: Disk usage at {$usage}%");
} else {
$this->info("Disk usage OK: {$usage}%");
}
}
private function getDiskUsage()
{
$output = shell_exec("df / | tail -1 | awk '{print $5}' | sed 's/%//'");
return (int) trim($output);
}
private function sendAlert($usage)
{
// メール送信やSlack通知などを実装
Log::emergency("Disk usage critical: {$usage}%");
}
}
# Laravelのスケジューラに登録
# app/Console/Kernel.php内で
$schedule->command('monitor:disk')->everyFifteenMinutes();
よくある失敗パターンと対処法
失敗パターン1: 重要なファイルまで削除してしまう
症状: 容量確保を急ぐあまり、アプリケーションの設定ファイルやデータベースファイルまで削除してしまい、さらなる障害を引き起こす。
対処法:
- 削除前には必ず
ls -lahでファイル内容を確認 - 重要なディレクトリ（
/etc、/var/lib/mysqlなど）は慎重に扱う - 不安な場合は、削除ではなくまず別の場所への移動を検討
# 削除前の安全な確認方法
ls -lah /var/log/nginx/access.log*
file /var/log/nginx/access.log.1 # ファイル種類の確認
# 削除ではなく一時的な移動
mkdir /tmp/cleanup
mv /var/log/nginx/access.log.* /tmp/cleanup/
失敗パターン2: 監視設定の不備
症状: 監視スクリプトを設置したものの、メールが届かない、アラートが機能しないなどで、結果的に再発してしまう。
対処法:
- 監視スクリプト設置後は必ず動作テストを実施
- メール送信機能の確認
- ログファイルによる動作確認
# 監視スクリプトのテスト実行
bash -x /path/to/disk_monitor.sh
# メール送信テスト
echo "Test message" | mail -s "Test" [email protected]
# crontabの実行ログ確認
tail -f /var/log/cron
失敗パターン3: 根本原因の未対処
症状: 一時的な容量確保で復旧したものの、容量を消費し続ける根本原因を解決せず、数週間後に再発してしまう。
対処法: ログファイルのローテーション設定、バックアップの自動削除設定など、継続的な対策を必ず実装する。
# nginx用logrotateの設定例
sudo vi /etc/logrotate.d/nginx
# 設定内容
/var/log/nginx/*.log {
daily
missingok
rotate 7
compress
delaycompress
notifempty
sharedscripts
postrotate
systemctl reload nginx
endscript
}
まとめ：継続的な運用でトラブル知らずのサーバー環境を
サーバー容量99%問題は、適切な対処法を知っていれば迅速に解決できる一方、対策を怠ると重大なビジネス損失につながる問題です。
私たちFivenine Designでは、このような運用面でのサポートも含めて、お客様のWebサイトを長期的に支援しています。特に中小企業のお客様では、専任のIT担当者がいないケースが多いため、予防的な監視設定や緊急時の対応体制構築をセットでご提案することが多くなっています。
実際に監視システムを導入したお客様からは、「安心してビジネスに集中できるようになった」「トラブルの予兆を事前に把握できるようになった」というお声をいただいています。
次にとるべきアクション:
- まずは現在のサーバー容量状況を確認
- 監視スクリプトの設置と動作確認
- ログローテーションなどの自動化設定の実装
- 緊急時対応手順書の作成と共有
もし「自社では技術的に難しい」「設定が不安」という場合は、お気軽にご相談ください。20年以上の経験をもとに、お客様の環境に最適な監視・運用体制をご提案いたします。
