Переполнение диска на хостинге приводит к более серьёзным последствиям, чем кажется. На первый взгляд всё просто: место закончилось, удалили лишнее — сайт снова работает. На практике в момент переполнения файлы, которые сайт как раз записывал, обрываются на середине. Поэтому даже после освобождения места сайт продолжает отдавать ошибку 500: важные файлы к этому моменту уже испорчены. Разберём типичные последствия заполненного диска и порядок их устранения.
Что происходит, когда диск заполнен
Чтобы записать файл, программа открывает его, очищает старое содержимое и начинает писать новое. Если квота заканчивается посреди этого процесса, файл остаётся пустым или недописанным. WordPress перезаписывает .htaccess при сохранении постоянных ссылок, а также при работе плагинов кеширования и безопасности. Если в этот момент места нет, файл обрывается, Apache не может его разобрать и отдаёт 500 на весь сайт.
Страдает и база данных. Если MySQL не может записать данные в таблицу, запрос завершается ошибкой, а иногда таблица помечается как повреждённая. Посетитель видит Error establishing a database connection или пустую белую страницу. Кроме того, PHP не может сохранить файлы сессий, почта не принимается, а файлы кеша остаются нулевого размера.
Шаг первый: диагностика и освобождение места
Сначала убедитесь, что проблема действительно в диске. В панели хостинга показан занятый объём и лимит, а в журнале ошибок сайта обычно встречаются записи No space left on device или Disk quota exceeded. Клиенты sayt.uz открывают ISPmanager из личного кабинета и видят эти данные в разделе ресурсов пользователя.
Затем освободите место. Быстрее всего помогают старые архивы резервных копий, большие журналы и папки кеша. Через SSH самые объёмные каталоги можно найти так:
du -xh -d 2 ~ 2>/dev/null | sort -h | tail -15Плагины резервного копирования, например UpdraftPlus, обычно хранят архивы внутри wp-content, и они легко занимают несколько гигабайт. Скачайте нужный архив на компьютер, остальные удалите. Журналы безопаснее не удалять, а обнулять, потому что некоторые программы продолжают писать в открытый файл:
: > ~/www/example.uz/wp-content/debug.logШаг второй: повреждённый .htaccess
Если после освобождения места ошибка 500 осталась, первым под подозрение попадает .htaccess. Откройте его и посмотрите конец: если файл обрывается на полуслове, блок <IfModule> не закрыт или файл вообще пуст, он испорчен при переполнении. В журнале ошибок Apache в таком случае видны сообщения вроде RewriteRule: bad argument line или Invalid command.
Для сайта на WordPress самое быстрое решение — сохранить копию файла и заменить его стандартным содержимым:
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPressЕсли в файле были правила плагина безопасности, кеширования или редиректы, восстановите их из резервной копии или повторно сохранив настройки соответствующего плагина. Открыть в админке WordPress страницу «Настройки — Постоянные ссылки» и нажать «Сохранить» тоже перезапишет стандартные правила, но для этого админка должна открываться.
Поиск PHP-файлов нулевого размера
Если в момент переполнения обновлялся плагин или ядро, пустыми могут оказаться и PHP-файлы. Они ломают отдельные страницы или весь сайт. Пустые файлы, изменённые за последние сутки, находятся так:
find ~/www/example.uz -type f -name '*.php' -size 0 -mmin -1440Верните найденные файлы из резервной копии или переустановите плагин. Если пусты файлы ядра WordPress, можно заменить каталоги wp-admin и wp-includes из официального архива той же версии, не трогая wp-content и wp-config.php.
Шаг третий: проверка базы данных
Для проверки базы отметьте таблицы в phpMyAdmin и выполните Check table или воспользуйтесь mysqlcheck по SSH:
mysqlcheck -u baza_user -p --check baza_nomiНапротив каждой таблицы должно стоять OK. Повреждённые таблицы MyISAM можно восстановить:
mysqlcheck -u baza_user -p --auto-repair --check baza_nomiСовременный WordPress и большинство актуальных систем используют InnoDB. Для InnoDB команда REPAIR TABLE не работает, но этот движок транзакционный и гораздо лучше защищён от недописанных записей. Если таблица InnoDB действительно повреждена, надёжнее всего восстановить базу из резервной копии. Самостоятельно включать серверные режимы восстановления не стоит — обратитесь в техническую поддержку.
Пример: как восстанавливали сайт клиники
Сайт частной клиники в Ташкенте на example.uz работает на WordPress и принимает онлайн-записи на приём. Ночью плагин резервного копирования начал создавать полный архив и заполнил квоту. Утром сайт отдавал 500. Администратор удалил старые архивы, но ошибка не ушла. Открыв .htaccess, он увидел, что файл оборвался посреди правил плагина безопасности. После замены на стандартное содержимое сайт открылся, но форма записи не работала.
mysqlcheck показал, что повреждена таблица плагина, хранящего заявки из формы. Это была старая таблица MyISAM, поэтому помог --auto-repair. После этого настройки плагина безопасности сохранили повторно, его правила вернулись в .htaccess, а плагин резервного копирования перенастроили на отправку архивов за пределы хостинга.
Как не допустить повторения
Диск редко заполняется внезапно — обычно место уходит постепенно, неделями. Поэтому хотя бы раз в месяц смотрите на занятый объём в панели. В плагинах резервного копирования ограничьте число хранимых копий и отправляйте их во внешнее хранилище. Включайте debug.log только на время поиска ошибки, а затем отключайте WP_DEBUG_LOG. Если сайт растёт естественным образом, увеличить объём тарифа заранее можно через кабинет sayt.uz или техническую поддержку.