Skip to content

Ursachen und Lösungen für 507 Insufficient Storage-Fehler | Festplattenkapazität, S3, Cloud-Umgebung

Kategorie:Server · Infrastruktur
Dieser Artikel ist derzeit nur auf Japanisch verfügbar. Übersetzte Versionen werden schrittweise veröffentlicht.

Der Fehler 「507 Insufficient Storage」 kann während Datei-Uploads oder der Verarbeitung großer Datenmengen auftreten. Dieser Fehler zeigt an, dass der Server nicht genügend Speicherplatz hat, um die Anfrage zu verarbeiten. Dieser Artikel erklärt systematisch von den Ursachen des Fehlers 507, Methoden zur Überprüfung der Festplattenkapazität, Maßnahmen zur Vermeidung von Log-Bloat, Verwaltung der Cloud-Speicher-Kapazität bis zur Konfiguration der Überwachung.

Von unzureichendem Datenträgerspeicher bis zum Fehler 507 Unzureichender Speicherplatz → HTTP 507 Entstehungsfluss Ursache Log bloat (no logrotate) Temp files in /tmp DB data growth S3 bucket quota inode exhaustion df -h: 100% Datenträger voll HTTP 507 Insufficient Storage Maßnahmen: logrotate / tmp-Bereinigung / Überwachung (Prometheus node_exporter)
Abbildung 1: Typischer Ablauf von unzureichendem Speicherplatz bis zum Auftreten des Fehlers 507

Was ist ein 507-Fehler

HTTP 507 Insufficient Storage ist ein Statuscode, der in RFC 4918 (WebDAV-Erweiterung) definiert ist. Er wird zurückgegeben, wenn der Server nicht den erforderlichen Speicherplatz zur Verfügung stellen kann, um die Anfrage abzuschließen. Ursprünglich war es ein Statuscode für das WebDAV-Protokoll, wird aber heute auch als generischer Fehler im Zusammenhang mit Dateispeicher verwendet.

Dieser Fehler ist häufig eine vorübergehende Zustandsanomalie und wird behoben, wenn Sie Speicherplatz freigeben. Wenn es jedoch ignoriert wird, kann es zu schwerwiegenden Ausfällen führen, wie z. B. Datenbankschreibfehler, Stopps der Protokollausgabe und Crashes der gesamten Anwendung.

Verwandte Status Name Unterschiede
413 Content Too Large Die Anfragegröße überschreitet das konfigurierte Limit (Serverkapazität ist nicht relevant)
507 Insufficient Storage Unzureichende physische/logische Speicherkapazität auf dem Server
503 Service Unavailable Vorübergehende Dienstunterbrechung(kann durch Kapazitätsmangel verursacht werden)

So überprüfen Sie den Festplattenspeicher des Servers

Wenn ein 507-Fehler auftritt, überprüfen Sie zunächst die Festplattenkapazität des Servers. Verwenden Sie die folgenden Befehle angemessen, um zu identifizieren, wo die Kapazität verbraucht wird.

# ファイルシステムごとの使用量を確認
df -h

# 出力例:
# Filesystem      Size  Used Avail Use% Mounted on
# /dev/sda1        50G   47G  3.0G  94% /
# /dev/sdb1       200G  180G   20G  90% /data

# 特定ディレクトリの使用量を確認
du -sh /var/log/
du -sh /var/www/
du -sh /tmp/

# サブディレクトリごとの使用量をソートして表示
du -h --max-depth=1 /var/ | sort -rh | head -20

# inode(ファイル数)の使用状況も確認(容量はあるのにファイルが作れない場合)
df -i

# 大きなファイルを探す(100MB以上)
find / -type f -size +100M -exec ls -lh {} \; 2>/dev/null | sort -k5 -rh | head -20

# 最近24時間以内に更新された大きなファイルを探す
find /var -type f -mtime -1 -size +50M -ls 2>/dev/null

Maßnahmen gegen Vergrößerung von Protokolldateien(logrotate)

Eine der häufigsten Ursachen für unzureichenden Datenträgerspeicher ist die Vergrößerung von Protokolldateien. Es ist nicht ungewöhnlich, dass Zugriffsprotokolle, Fehlerprotokolle und Anwendungsprotokolle auf mehrere GB anwachsen. Konfigurieren Sie <code>logrotate</code> unter Linux ordnungsgemäß, um automatische Protokollrotation durchzuführen.

# /etc/logrotate.d/nginx の設定例
/var/log/nginx/*.log {
    daily           # 毎日ローテーション
    missingok       # ログファイルが無くてもエラーにしない
    rotate 14       # 14世代分を保持
    compress        # gzip で圧縮
    delaycompress   # 直近1世代は圧縮しない
    notifempty      # 空のログはローテーションしない
    create 0640 www-data adm  # 新しいログファイルの権限
    sharedscripts
    postrotate
        [ -f /var/run/nginx.pid ] && kill -USR1 $(cat /var/run/nginx.pid)
    endscript
}
# /etc/logrotate.d/app の設定例(アプリケーションログ)
/var/www/app/storage/logs/*.log {
    daily
    missingok
    rotate 7         # 7日分を保持
    compress
    delaycompress
    notifempty
    create 0644 www-data www-data
    maxsize 100M     # 100MB を超えたら日次以外でもローテーション
    dateext          # 日付をファイル名に付与
    dateformat -%Y%m%d
}

# 手動でローテーションを実行(テスト)
sudo logrotate -f /etc/logrotate.d/app

# ドライラン(実行せずに結果を確認)
sudo logrotate -d /etc/logrotate.d/app

# ログのサイズを即座に確認
ls -lhS /var/log/nginx/ | head -10
ls -lhS /var/www/app/storage/logs/ | head -10

Bereinigung des tmp-Verzeichnisses

Es kommt auch häufig vor, dass temporäre Dateien während des Uploads, Sitzungsdateien und Cache-Dateien sich im Verzeichnis <code>/tmp</code> ansammeln und die Kapazität belasten.

# /tmp の使用量を確認
du -sh /tmp/

# 古い一時ファイルの確認(7日以上前)
find /tmp -type f -mtime +7 -ls | head -20

# 古い一時ファイルを削除(7日以上前のファイル)
find /tmp -type f -mtime +7 -delete

# PHPセッションファイルの確認と掃除
du -sh /var/lib/php/sessions/
find /var/lib/php/sessions/ -type f -mtime +1 -delete

# PHPのアップロード一時ファイルが残っていないか確認
ls -la /tmp/php*

# systemd-tmpfiles を使った自動掃除(systemd環境)
# /etc/tmpfiles.d/cleanup.conf に以下を追加:
# d /tmp 1777 root root 7d
# 上記設定は /tmp 内の7日以上前のファイルを自動削除
# cron で定期的に掃除するスクリプト例
# /etc/cron.daily/cleanup-tmp

#!/bin/bash
# 7日以上前のtmpファイルを削除
find /tmp -type f -mtime +7 -delete 2>/dev/null

# アプリケーションのキャッシュを掃除
find /var/www/app/storage/framework/cache -type f -mtime +3 -delete 2>/dev/null

# 容量を記録
echo "$(date '+%Y-%m-%d %H:%M:%S') - $(df -h / | tail -1)" >> /var/log/disk-usage.log

Kapazitätslimits bei S3 und Cloud-Speicher

Auch bei der Verwendung von Cloud-Speicher ist es notwendig, auf Kapazitätsbeschränkungen und Kosten zu achten. AWS S3 selbst hat keine Kapazitätsobergrenze für Buckets, aber es ist notwendig, Kostenverwaltung und Lebenszyklusrichtlinien richtig zu konfigurieren.

# AWS CLI で S3 バケットのサイズを確認
aws s3 ls s3://my-bucket --recursive --summarize --human-readable | tail -2
# 出力例:
# Total Objects: 152345
# Total Size: 85.3 GiB

# CloudWatch メトリクスでバケットサイズを確認
aws cloudwatch get-metric-statistics \
    --namespace AWS/S3 \
    --metric-name BucketSizeBytes \
    --dimensions Name=BucketName,Value=my-bucket Name=StorageType,Value=StandardStorage \
    --start-time 2026-04-13T00:00:00Z \
    --end-time 2026-04-14T00:00:00Z \
    --period 86400 \
    --statistics Average
// S3 ライフサイクルポリシーの設定例
// 古いファイルを自動的にアーカイブ・削除
{
    "Rules": [
        {
            "ID": "archive-old-uploads",
            "Status": "Enabled",
            "Filter": {
                "Prefix": "uploads/"
            },
            "Transitions": [
                {
                    "Days": 90,
                    "StorageClass": "STANDARD_IA"
                },
                {
                    "Days": 365,
                    "StorageClass": "GLACIER"
                }
            ]
        },
        {
            "ID": "delete-temp-files",
            "Status": "Enabled",
            "Filter": {
                "Prefix": "tmp/"
            },
            "Expiration": {
                "Days": 7
            }
        },
        {
            "ID": "cleanup-incomplete-uploads",
            "Status": "Enabled",
            "Filter": {
                "Prefix": ""
            },
            "AbortIncompleteMultipartUpload": {
                "DaysAfterInitiation": 3
            }
        }
    ]
}
Cloud-Service Kapazitätslimit Limit für 1 Datei Wichtige Punkte
AWS S3 Unbegrenzt 5TB Kostenverwaltung und Einstellung von Lebenszyklusrichtlinien sind wichtig
Google Cloud Storage Unbegrenzt 5TB Beachten Sie die Kostensteigerung, wenn Object Versioning aktiviert ist
Azure Blob Storage Unbegrenzt Etwa 4,75 TB (Block Blob) Bandbreiten- und IOPS-Limits pro Konto vorhanden
DigitalOcean Spaces 250GB (je nach Plan) 5GB Beachten Sie die Kapazitätsobergrenze des Plans

Überwachungskonfiguration (Schwellenwert-Alarme)

Die Prävention ist am wichtigsten für 507-Fehler. Richten Sie die Überwachung ein, um Warnungen zu senden, wenn die Festplattenauslastung einen bestimmten Schwellenwert überschreitet.

#!/bin/bash
# /usr/local/bin/disk-alert.sh
# ディスク使用率監視スクリプト

THRESHOLD=80  # 警告しきい値(%)
CRITICAL=90   # 危険しきい値(%)
MAILTO="admin@example.com"

df -h --output=pcent,target | tail -n +2 | while read usage mount; do
    # パーセント記号を除去
    usage_num=$(echo "$usage" | tr -d '%')

    if [ "$usage_num" -ge "$CRITICAL" ]; then
        echo "CRITICAL: ${mount} のディスク使用率が ${usage}% です" | \
            mail -s "[CRITICAL] ディスク容量警告 - $(hostname)" "$MAILTO"
    elif [ "$usage_num" -ge "$THRESHOLD" ]; then
        echo "WARNING: ${mount} のディスク使用率が ${usage}% です" | \
            mail -s "[WARNING] ディスク容量警告 - $(hostname)" "$MAILTO"
    fi
done

# crontab に登録(5分ごとに実行)
# */5 * * * * /usr/local/bin/disk-alert.sh
# Prometheus + node_exporter でのアラート設定例
# /etc/prometheus/alerts/disk.yml

groups:
  - name: disk_alerts
    rules:
      - alert: DiskSpaceWarning
        expr: (1 - node_filesystem_avail_bytes / node_filesystem_size_bytes) * 100 > 80
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "ディスク使用率が80%を超えています"
          description: "{{ $labels.instance }} の {{ $labels.mountpoint }} の使用率が {{ $value }}% です。"

      - alert: DiskSpaceCritical
        expr: (1 - node_filesystem_avail_bytes / node_filesystem_size_bytes) * 100 > 90
        for: 2m
        labels:
          severity: critical
        annotations:
          summary: "ディスク使用率が90%を超えています - 即時対応が必要"
          description: "{{ $labels.instance }} の {{ $labels.mountpoint }} の使用率が {{ $value }}% です。"

      - alert: DiskInodeWarning
        expr: (1 - node_filesystem_files_free / node_filesystem_files) * 100 > 80
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "inode使用率が80%を超えています"
# Python での簡易ディスク監視スクリプト
import shutil
import smtplib
from email.mime.text import MIMEText

def check_disk_usage(path='/', warning_threshold=80, critical_threshold=90):
    """ディスク使用率を確認してアラートを送信"""
    total, used, free = shutil.disk_usage(path)

    usage_percent = (used / total) * 100
    free_gb = free / (1024 ** 3)

    print(f"パス: {path}")
    print(f"使用率: {usage_percent:.1f}%")
    print(f"空き容量: {free_gb:.1f} GB")

    if usage_percent >= critical_threshold:
        send_alert(
            level="CRITICAL",
            message=f"{path} の使用率が {usage_percent:.1f}% です。"
                    f"空き容量: {free_gb:.1f} GB"
        )
    elif usage_percent >= warning_threshold:
        send_alert(
            level="WARNING",
            message=f"{path} の使用率が {usage_percent:.1f}% です。"
                    f"空き容量: {free_gb:.1f} GB"
        )

    return usage_percent

def send_alert(level, message):
    """メールアラートを送信"""
    msg = MIMEText(message)
    msg['Subject'] = f"[{level}] ディスク容量アラート"
    msg['From'] = "monitor@example.com"
    msg['To'] = "admin@example.com"

    with smtplib.SMTP('localhost') as server:
        server.send_message(msg)

if __name__ == '__main__':
    check_disk_usage('/')
    check_disk_usage('/data')

Verfahren zur Kapazitätssicherung im Notfall

Wenn ein 507-Fehler auftritt und der Dienst ausfällt, führen Sie die folgenden Schritte durch, um schnell Speicherplatz freizugeben.

# 1. まず現状を把握
df -h
du -h --max-depth=1 / | sort -rh | head -10

# 2. 即座に削除できるファイル
# 古いログファイル(圧縮済み)
rm -f /var/log/nginx/*.gz
rm -f /var/log/syslog.*.gz

# パッケージマネージャーのキャッシュ
apt-get clean          # Debian/Ubuntu
yum clean all          # CentOS/RHEL

# 古いカーネル(Ubuntu)
apt-get autoremove --purge

# 3. 大きな不要ファイルを探して削除
find /var -type f -size +100M -mtime +30 -ls
find /tmp -type f -mtime +1 -delete

# 4. ログの即時ローテーション
logrotate -f /etc/logrotate.conf

# 5. journalctl のログを圧縮(systemd環境)
journalctl --vacuum-size=100M
journalctl --vacuum-time=7d

# 6. 削除後の確認
df -h

Testdatei zur Verwendung in diesem Artikel (kostenlos)

  • → <a href="/ja/files/threshold/png/50mb/" class="text-primary-600 dark:text-primary-400 hover:underline">PNG Grenzwerttest 50MB</a> — Zur Überprüfung des Verhaltens beim Hochladen großer Dateien
  • → <a href="/ja/files/threshold/png/10mb/" class="text-primary-600 dark:text-primary-400 hover:underline">PNG Grenzwerttest 10MB</a> — Für grundlegende Speicherschreibtests
  • → <a href="/ja/files/threshold/" class="text-primary-600 dark:text-primary-400 hover:underline">Liste von Grenzwert-Testdateien</a> — Testdateien verschiedener Größen
  • → <a href="/ja/files/images/" class="text-primary-600 dark:text-primary-400 hover:underline">Liste der Testbilder</a> — Zur Überprüfung der Upload-Funktionalität

Verwandte Artikel

  • → <a href="/ja/blog/http-413-error/" class="text-primary-600 dark:text-primary-400 hover:underline">Ursachen und Lösungen für den Fehler 413 Request Entity Too Large</a>
  • → <a href="/ja/blog/http-422-error/" class="text-primary-600 dark:text-primary-400 hover:underline">Ursachen und Lösungen für den Fehler 422 Unprocessable Entity</a>
  • → <a href="/ja/blog/nginx-upload-config/" class="text-primary-600 dark:text-primary-400 hover:underline">Nginx Datei-Upload-Konfigurationsleitfaden</a>
  • → <a href="/ja/blog/s3-upload-limit/" class="text-primary-600 dark:text-primary-400 hover:underline">Zusammenfassung der Datei-Upload-Limits von AWS S3 und CloudFront</a>