Skip to content

Causas e soluções do erro 507 Insufficient Storage | Capacidade de disco, S3, ambiente em nuvem

Categoria:Servidor · Infraestrutura
Este artigo está disponível atualmente apenas em japonês. As versões traduzidas serão publicadas sequencialmente.

Pode ocorrer o erro 「507 Insufficient Storage」 durante uploads de arquivo ou processamento de grande volume de dados. Esse erro indica que o servidor não tem espaço de armazenamento suficiente para processar a requisição. Este artigo explica sistematicamente desde as causas do erro 507, métodos de verificação de capacidade de disco, medidas de mitigação de inchaço de logs, gerenciamento de capacidade em armazenamento em nuvem, até a configuração de monitoramento.

Da falta de espaço em disco até o erro 507 Espaço de armazenamento insuficiente → Fluxo de geração de HTTP 507 Causa Log bloat (no logrotate) Temp files in /tmp DB data growth S3 bucket quota inode exhaustion df -h: 100% Disco cheio HTTP 507 Insufficient Storage Medidas: logrotate / limpeza de tmp / monitoramento (Prometheus node_exporter)
Figura 1: Fluxo típico da insuficiência de capacidade de armazenamento até a ocorrência do erro 507

O que é um erro 507

HTTP 507 Insufficient Storage é um código de status definido em RFC 4918 (extensão WebDAV). É retornado quando o servidor não consegue alocar o espaço de armazenamento necessário para completar a solicitação. Originalmente era um código de status para o protocolo WebDAV, mas atualmente também é usado como erro genérico relacionado ao armazenamento de arquivos.

Este erro costuma ser uma anomalia de estado temporária e será resolvido liberando espaço em disco. No entanto, se deixado sem tratamento, pode levar a falhas graves, como falhas de gravação em banco de dados, parada de saída de log e queda de toda a aplicação.

Status relacionado Nome Diferenças
413 Content Too Large O tamanho da solicitação excede o limite configurado (a capacidade do servidor não é relevante)
507 Insufficient Storage Capacidade de armazenamento física/lógica insuficiente no servidor
503 Service Unavailable Interrupção temporária de serviço(pode ser causada por falta de capacidade)

Como verificar o espaço em disco do servidor

Se um erro 507 ocorrer, primeiro verifique a capacidade de disco do servidor. Use os comandos a seguir apropriadamente para identificar onde a capacidade está sendo consumida.

# ファイルシステムごとの使用量を確認
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

Medidas contra aumento de tamanho de arquivo de log(logrotate)

Uma das causas mais comuns de falta de espaço em disco é o inchaço de arquivos de log. Não é raro que logs de acesso, logs de erro e logs de aplicação inchem para vários GB. Configure adequadamente o <code>logrotate</code> do Linux para realizar rotação automática de logs.

# /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

Limpeza do diretório tmp

Também é frequente o caso de arquivos temporários durante upload, arquivos de sessão e arquivos de cache se acumularem no diretório <code>/tmp</code> e pressionarem a capacidade.

# /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

Limites de capacidade em S3 e armazenamento em nuvem

Mesmo ao usar armazenamento em nuvem, é necessário estar atento a limitações de capacidade e custos. O AWS S3 em si não tem limite de capacidade de bucket, mas é necessário configurar adequadamente o gerenciamento de custos e as políticas de ciclo de vida.

# 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
            }
        }
    ]
}
Serviço em nuvem Limite de capacidade Limite de 1 arquivo Pontos de atenção
AWS S3 Ilimitado 5TB Gerenciamento de custo e configuração de políticas de ciclo de vida são importantes
Google Cloud Storage Ilimitado 5TB Atenção ao aumento de custos quando versionamento de objetos está habilitado
Azure Blob Storage Ilimitado Aproximadamente 4,75 TB (Block Blob) Há limites de largura de banda e IOPS por conta
DigitalOcean Spaces 250GB (dependendo do plano) 5GB Tenha cuidado com o limite de capacidade do plano

Configuração de Monitoramento (Alertas de Limite)

A prevenção é o mais importante para o erro 507. Configure o monitoramento para enviar alertas quando a taxa de uso do disco exceder um limite determinado.

#!/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')

Procedimento de garantia de capacidade em emergências

Quando ocorre um erro 507 e o serviço fica indisponível, siga os passos abaixo para liberar espaço rapidamente.

# 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

Arquivo de teste disponível para usar neste artigo (gratuito)

  • → <a href="/ja/files/threshold/png/50mb/" class="text-primary-600 dark:text-primary-400 hover:underline">PNG teste de valores limite 50MB</a> — Para verificação de comportamento de upload de arquivo grande
  • → <a href="/ja/files/threshold/png/10mb/" class="text-primary-600 dark:text-primary-400 hover:underline">PNG teste de valores limite 10MB</a> — Para teste básico de escrita em armazenamento
  • → <a href="/ja/files/threshold/" class="text-primary-600 dark:text-primary-400 hover:underline">Lista de arquivos de teste de valores limite</a> — Arquivos de teste de vários tamanhos
  • → <a href="/ja/files/images/" class="text-primary-600 dark:text-primary-400 hover:underline">Lista de imagens de teste</a> — Para verificação do funcionamento da funcionalidade de upload

Artigos relacionados

  • → <a href="/ja/blog/http-413-error/" class="text-primary-600 dark:text-primary-400 hover:underline">Causas e soluções do erro 413 Request Entity Too Large</a>
  • → <a href="/ja/blog/http-422-error/" class="text-primary-600 dark:text-primary-400 hover:underline">Causas e soluções do erro 422 Unprocessable Entity</a>
  • → <a href="/ja/blog/nginx-upload-config/" class="text-primary-600 dark:text-primary-400 hover:underline">Guia de Configuração de Upload de Arquivos Nginx</a>
  • → <a href="/ja/blog/s3-upload-limit/" class="text-primary-600 dark:text-primary-400 hover:underline">Resumo dos limites de upload de arquivos do AWS S3 e CloudFront</a>