Ошибка 507 Insufficient Storage: что делать владельцу сайта

Ошибка 507 Insufficient Storage означает, что сервер не смог сохранить данные, необходимые для выполнения запроса. Чаще всего нужно проверить не браузер пользователя, а свободное место, inode, квоту и тот каталог или хранилище, куда пишет приложение.

Не повторяйте загрузку или сохранение много раз подряд. Сначала зафиксируйте URL, время и действие, которое вызвало ошибку, затем найдите компонент, вернувший 507: веб-сервер, приложение, WebDAV, база данных или внешнее хранилище.

Что означает код 507

Код описан в RFC 4918 как ошибка WebDAV: сервер не может сохранить представление, необходимое для завершения метода. Стандарт считает состояние временным и отдельно предупреждает не повторять пользовательский запрос автоматически.

Причиной может быть исчерпанное физическое место или квота. RFC 4331 различает превышение выделенной квоты и нехватку физического пространства. На практике приложение или прокси может тем же кодом обозначить сбой своего пути записи, поэтому одной проверки общего объёма диска недостаточно.

507 относится к серверной стороне, но сам код не называет заполненный раздел. Например, корневой диск может иметь запас, а отдельный том с временными файлами, базой данных или пользовательскими загрузками — нет.

Диагностика ошибки 507 по порядку

1. Зафиксируйте запрос и границы сбоя

Запишите точный адрес без секретных параметров, время с часовым поясом, HTTP-метод и действие: загрузка файла, сохранение страницы, резервное копирование или обновление. В инструментах разработчика браузера посмотрите статус исходного запроса и заголовки ответа, но не переносите cookie и токены в заметки или команды.

Безопасный GET-запрос к публичному URL поможет проверить только доступность чтения:

curl -sS -D - -o /dev/null https://example.ru/problem-path

Если главная страница отвечает нормально, а 507 появляется только при загрузке, проблема локализована в ветке записи. Не воспроизводите POST на боевом сайте без понимания побочных эффектов: повтор может создать дубликат, временный файл или ещё одну задачу в очереди.

2. Определите, кто вернул ответ

Оформление страницы ошибки и заголовок Server дают подсказку, но не являются доказательством. Сопоставьте время запроса с журналами reverse proxy, веб-сервера, PHP или другого runtime, приложения и хранилища.

Если доступа к серверу нет, передайте хостингу точный URL, время, тип операции и идентификатор запроса из ответа, если он есть. Этого полезнее, чем сообщение «сайт иногда выдаёт 507».

3. Проверьте место, inode и квоты

На Linux начните с файловых систем, которые обслуживают сайт, временный каталог и базу данных. Пути зависят от конфигурации:

df -h /var/www /tmp /var/lib/mysql
df -i /var/www /tmp /var/lib/mysql

Первая команда показывает занятое место, вторая — доступные inode, то есть запас для создания новых файлов. Диск может иметь свободные гигабайты, но не позволять создать файл из-за исчерпанных inode.

Затем проверьте квоту пользователя или тарифа, лимит тома контейнера и ограничения подключённого объектного либо сетевого хранилища. На виртуальном хостинге эти данные обычно смотрят в панели или запрашивают у поддержки провайдера.

4. Найдите источник роста без поспешного удаления

Смотрите сначала тот раздел, который оказался заполнен. Например, обзор верхнего уровня одного файлового дерева можно начать так:

du -xhd1 /var/www 2>/dev/null | sort -h

На большом боевом томе такая проверка может быть тяжёлой, поэтому ограничивайте путь и запускайте её в подходящее время. Отдельно проверьте журналы, кэш, временные загрузки, незавершённые архивы, локальные резервные копии и каталоги, создаваемые фоновыми задачами.

Не удаляйте неизвестные файлы базы данных, активные журналы или единственную резервную копию. Сначала выясните владельца данных, срок хранения и безопасный способ очистки или ротации.

5. Проверьте всю цепочку записи

Свободное место не исключает 507. Убедитесь, что нужная файловая система не смонтирована только для чтения, каталог существует, процесс имеет право записи, а временный путь доступен.

Для операции с данными проверьте также хранилище базы, её временный каталог и журнал ошибок. Для загрузки файла цепочка может включать временный каталог runtime, буфер reverse proxy, каталог медиа CMS и удалённое хранилище. Сбой на любом участке способен прервать запрос.

Типовые сценарии

• Не загружаются файлы. Проверяйте временные каталоги, квоту аккаунта, каталог медиа и место назначения. Ошибка 413 означает ограничение размера запроса, а 507 указывает на невозможность сохранить данные.
• Не сохраняются формы, заказы или настройки. Сопоставьте запрос с журналом приложения и базы; публичные страницы при этом могут продолжать отвечать 200.
• Падает резервное копирование или обновление. Архиву и распаковке часто нужен отдельный временный запас. Проверьте, не остались ли незавершённые копии после предыдущего запуска.
• Ошибка приходит из WebDAV. Сначала проверяйте квоту ресурса и физическое место, потому что именно для этой ситуации код стандартизован.
• Все страницы отдают 507. Ищите общий заполненный или недоступный путь: журналы, сессии, кэш, база или том приложения. Сравнить этот случай с общим сбоем приложения поможет руководство про ошибку 500.

Как безопасно восстановить работу

1. Остановите задачу, которая быстро увеличивает объём данных, и отключите автоматические повторы проблемной операции.
2. Сохраните время ошибки и нужные фрагменты журналов до очистки.
3. Освободите только проверенные временные данные либо расширьте том или квоту. Сразу настройте ротацию и срок хранения, чтобы причина не вернулась.
4. Перезапускайте сервис только после устранения причины и лишь если он не восстановился сам: перезапуск не создаёт место.
5. Повторите исходное действие один раз как новую осознанную операцию. Проверьте, что запись завершилась, частичного результата или дубля нет, а журналы не показывают новую ошибку.
6. Возобновите фоновые задачи постепенно и наблюдайте за ростом хранилища.

Критерий восстановления — не только исчезнувшая страница 507. Должны успешно работать чтение и затронутая операция записи, а на нужном томе и по квоте должен оставаться контролируемый запас.

Как не пропустить повторение

Настройте предупреждения для места, inode и прикладных квот, ограничьте хранение временных файлов и вынесите резервные копии с рабочего тома. После изменений отдельно проверяйте операции загрузки, сохранения и резервного копирования.

Внешний контроль дополняет серверные метрики: Web-Puls может регулярно проверять публичный URL и помочь заметить 507, если его получает выбранная страница. Но обычный GET главной страницы не обнаружит отказ загрузки файла, пока она продолжает отвечать 200; для такой ветки нужен безопасный прикладной тест.

Если хостинг формально доступен, а сайт или запись данных нет, используйте порядок проверки приложения и инфраструктуры и сопоставьте его с внешними проверками и серверными метриками.

Когда передать диагностику специалисту

Если 507 возвращается после очистки, причина находится в базе или контейнерном хранилище либо у вас нет доступа к журналам, подготовьте URL без секретов, время, проблемное действие, ответ сервера и список недавних изменений. С этими данными можно отправить заявку на профессиональную поддержку: специалист начнёт с локализации источника ответа и безопасной проверки цепочки записи.