WordPress заполняет весь диск резервными копиями: как найти и исправить

Диск заполнен: как понять, что место действительно заняли резервные копии WordPress

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

На VPS с SSH начните с файловых систем:

df -h

Смотрите на Size, Used, Avail и Use%. Например:

Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1        80G   77G  1.2G  99% /

Здесь почти заполнен корневой раздел. Но df не отвечает на следующий вопрос: кто именно съел 77 GB. Для этого понадобится du.

Отдельно проверьте inode:

df -i

Если IUse% близок к 100%, а по df -h гигабайты ещё свободны, причина другая: файлов стало слишком много. Такое бывает при огромном количестве кеша или временных файлов. Несколько многогигабайтных резервных архивов, наоборот, обычно упираются именно в объём.

Почему WordPress пишет Disk quota exceeded, хотя df показывает свободное место

Если df -h показывает заметный запас, а WordPress получает Disk quota exceeded, не нужно сразу искать огромный ZIP. Ограничение может действовать на конкретного пользователя или аккаунт хостинга, а не на файловую систему целиком.

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

Именно поэтому свободные 20 GB по df ещё не означают, что WordPress может ими воспользоваться.

Если на этом этапе непонятно, где ушло место, к плагинам WordPress пока рано переходить. Сначала локализуйте проблему на уровне диска или квоты.

Как быстро найти каталог, который занимает больше всего места

Самый быстрый способ найти источник заполнения диска — идти по дереву каталогов сверху вниз и на каждом уровне выбирать самый большой каталог. Не пытайтесь сразу угадать имя backup-папки: архивы могут находиться в wp-content, домашнем каталоге пользователя, системном хранилище панели или вообще вне document root сайта.

Если сайты находятся в /home, начните так:

du -h --max-depth=1 /home | sort -h

Например:

1.1G    /home/user1
4.8G    /home/user2
42G     /home/siteuser
48G     /home

Основной кандидат здесь — /home/siteuser. Проверяем его:

du -h --max-depth=1 /home/siteuser | sort -h

Если основной объём ушёл в сайт:

du -h --max-depth=1 /home/siteuser/public_html | sort -h

Так за несколько шагов можно перейти от заполненного 80-гигабайтного раздела к одному каталогу с архивами. Это быстрее, чем запускать хаотичный find по всему серверу.

Как не уйти на другую файловую систему

На сервере могут быть дополнительные диски, сетевые хранилища и отдельные mount points. В таком случае удобно ограничить du одной файловой системой:

du -xhd1 /home/siteuser | sort -h

Ключ -x не даст случайно включить в расчёт отдельно смонтированное хранилище и исказить картину.

Почему df и du могут показывать разные цифры

df смотрит на использование файловой системы, а du суммирует видимые файлы и каталоги. Поэтому небольшая разница нормальна. Но если df показывает занятыми 75 GB, а du удаётся найти только 40–45 GB, WordPress пока можно не трогать — сначала нужно разобраться с расхождением.

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

Удалили большой архив, но свободное место не появилось

Представим обычную ситуацию: удалили backup.tar.gz на 15 GB, повторили df -h, а использование диска почти не изменилось. Проверить открытые удалённые файлы можно так:

lsof +L1

В выводе ищите крупные файлы с пометкой deleted, PID процесса и путь. Если удалённый архив всё ещё открыт PHP-процессом, backup-скриптом или другой службой, место освободится только после корректного закрытия файла процессом.

Другие причины заметного расхождения df и du — reserved blocks и отдельные mount points. Но если lsof +L1 показывает многогигабайтный удалённый файл, источник обычно уже найден.

Где WordPress и плагины резервного копирования обычно хранят архивы

У WordPress нет единого стандартного каталога для резервных копий. Место хранения определяет backup-плагин, панель управления или пользовательский скрипт. Поэтому искать только папку с названием backup недостаточно.

Среди часто встречающихся вариантов внутри сайта можно увидеть wp-content/updraft, wp-content/ai1wm-backups, каталоги BackWPup, Duplicator, WPvivid или собственные директории администратора. Конкретный путь зависит от инструмента и его настроек.

Если каталог сайта уже известен, найдите крупные файлы. Например, всё больше 500 MB:

find /path/to/site -type f -size +500M -print

Чтобы сразу видеть размеры:

find /path/to/site -type f -size +500M -exec ls -lh {} \;

Можно дополнительно проверить типичные расширения архивов:

find /path/to/site -type f \( -name "*.zip" -o -name "*.tar.gz" -o -name "*.wpress" \)

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

Чтобы не зависеть от имени и расширения, выведите крупнейшие файлы вообще:

find /path/to/site -type f -printf '%s %p\n' | sort -n | tail

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

Как определить, какой плагин или процесс создаёт резервные копии

Удаление архивов устраняет только симптом. Если файлы появились снова, генератор всё ещё работает. Причём резервное копирование может запускаться не только WordPress-плагином, но и WP-Cron, системным cron, root-задачей, systemd timer, панелью VPS или отдельным shell/PHP-скриптом.

Начните с времени изменения файлов:

ls -lt /path/to/backups

Если новые архивы появляются почти каждый день в одно время, это уже ориентир для поиска расписания.

Как проверить WordPress Cron

При установленном WP-CLI список событий можно получить командой:

wp cron event list

Если WordPress работает в FASTPANEL и системный cron запускает PHP CLI вручную, полезно отдельно проверить правильный путь к PHP CLI для Cron WordPress: неверный бинарник или путь может менять фактическое поведение задания.

Ищите события установленного backup-плагина и сравнивайте время следующего запуска с временем создания архивов.

Заодно посмотрите активные плагины:

wp plugin list

Сценарий, который легко пропустить: плагин резервного копирования отключили, но ночью новый ZIP всё равно появился. Это прямой сигнал, что нужно искать второй источник — другое расписание, серверный скрипт или задание панели.

Почему время архива может не совпадать с расписанием WordPress

Не делайте вывод по одной цифре времени. WordPress, PHP и операционная система могут использовать разные timezone. Если в настройках WordPress указано 02:00, а файл появляется около 03:00, сначала сравните часовой пояс CMS и сервера.

Кроме того, WP-Cron не работает как классический системный cron: выполнение события связано с запуском механизма WordPress. Поэтому фактический старт задачи может отличаться от ожидаемого времени.

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

Как проверить системный cron VPS

crontab -l показывает только задания текущего пользователя:

crontab -l

Пустой вывод не означает, что cron-задач на сервере нет. При наличии прав администратора проверьте root:

sudo crontab -l

Затем системные задания:

cat /etc/crontab
ls -la /etc/cron.d/

Поиск по характерному слову иногда ускоряет работу:

grep -R "backup" /etc/cron* 2>/dev/null

Но скрипт может называться site-copy.sh, archive.php или вообще не содержать слова backup. Поэтому поиск по имени — вспомогательная проверка, а не доказательство.

Если cron пустой: проверьте systemd timers и панель

На некоторых VPS периодические задания запускаются через systemd:

systemctl list-timers --all

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

Отдельно проверьте, не установлены ли два плагина с резервным копированием. Когда один создаёт архив ночью, а второй запускается через несколько часов, владелец сайта часто воспринимает это как сломанную ротацию одного инструмента.

Почему старые резервные копии WordPress не удаляются автоматически

Если число архивов постоянно растёт, проблема обычно либо в политике хранения, либо в том, что задача не доходит до этапа очистки. Настройка «хранить 3 копии» на экране сама по себе ничего не доказывает.

Сначала посмотрите даты, размеры и общий объём каталога:

ls -lh /path/to/backups
ls -lt /path/to/backups
du -sh /path/to/backups

Для конкретного файла:

stat filename.zip

Причин накопления несколько:

• политика хранения не настроена или включено хранение всех архивов;
• работают два независимых расписания;
• локальный архив не удаляется после успешной отправки наружу;
• путь хранения менялся, и старый каталог больше не участвует в очистке;
• новые и старые файлы принадлежат разным Unix-пользователям;
• backup завершается ошибкой раньше этапа ротации;
• диск заканчивается ещё во время создания новой копии.

Как проверить права на каталог резервных копий

Если новые архивы создаются, но старые не удаляются, посмотрите владельца и права:

ls -ld /path/to/backups
ls -l /path/to/backups
stat /path/to/backups

Характерный случай: старые архивы созданы от root, а текущий backup-процесс работает от пользователя сайта или PHP. Новый файл записать он может, а удалить старый, принадлежащий другому владельцу, — уже нет.

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

Что искать в журнале резервного копирования

Слово «логи» бесполезно без конкретного критерия. В журнале последнего задания ищите финальный статус и сообщения вокруг этапов очистки или выгрузки. Типичные формулировки могут выглядеть так:

Completed successfully
Failed
Permission denied
No space left on device
Unable to delete old backup
Failed to prune backups
Upload failed
Cleanup failed

Точный текст зависит от плагина или серверной системы, но логика одинакова. Если создание архива прошло успешно, а ошибка появилась на pruning/cleanup, причина найдена: backup работает, ротация — нет.

Если лог обрывается на No space left on device, до очистки старых копий задача могла вообще не дойти.

Почему нехватка места может сама ломать ротацию

Допустим, свободно 4 GB, а для нового задания требуется больше. Система начинает формировать SQL-дамп, временные файлы или архив, заполняет оставшееся место и падает. Очистка старой копии планировалась позже — она уже не выполняется.

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

Для диагностики старые файлы можно только вывести:

find /path/to/backups -type f -mtime +30 -print

После исправления причины нужен реальный контрольный запуск. Новая копия должна создаться, а лишняя старая — исчезнуть по заданной политике.

Что делать, если диск VPS уже заполнен на 100%

Если df -h показывает 100%, первая задача — вернуть серверу рабочее пространство. Не запускайте ещё одну полную копию: на полностью забитом разделе ей негде создавать архив, SQL-дамп и временные данные.

В таком состоянии WordPress может перестать загружать медиа и обновляться, PHP — записывать временные файлы, а MySQL и другие службы — нормально работать с данными. Если админка уже не открывается, диагностику нужно продолжать через SSH или панель сервера.

Безопасный порядок:

1. Проверить df -h и определить заполненный раздел.
2. Проверить df -i, чтобы не перепутать объём с inode.
3. Через du найти крупнейший каталог.
4. Найти самые большие backup-файлы.
5. Проверить их даты, размеры и назначение.
6. Убедиться, что остаётся хотя бы одна пригодная копия.
7. Удалить или перенести несколько подтверждённо лишних архивов.
8. Повторить df -h.
9. Только после появления запаса разбираться с cron, логами и ротацией.

Сколько места нужно освободить сначала

Универсальной цифры нет. Цель аварийной очистки — не получить красивый процент в панели, а вернуть системе возможность записывать данные и проводить диагностику.

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

Удалили backup, но место не вернулось

Такое поведение особенно сбивает с толку: файл исчез из каталога, а df -h всё ещё показывает 100%. Проверьте открытые удалённые файлы:

lsof +L1

Если большой архив отмечен как deleted и всё ещё связан с процессом, файловая система продолжает учитывать занятые блоки. Сначала определите PID и процесс. Здесь проблема уже не в WordPress-плагине как таковом.

Что делать, если df свободен, а WordPress пишет Disk quota exceeded

Этот сценарий нельзя лечить удалением случайных файлов на всём VPS. Если filesystem свободен, проверьте лимит конкретного аккаунта или Unix-пользователя. На обычном хостинге это обычно видно в панели использования диска; на VPS причина может быть в настроенной пользовательской квоте.

После аварийной очистки повторите минимум три проверки:

df -h
df -i
du -sh /path/to/backups

Если диск вышел из состояния 100%, inode свободны, а каталог backup уменьшился до ожидаемого размера, серверу уже есть чем дышать. Теперь нужно устранить генератор проблемы, иначе место закончится снова.

Какие резервные копии можно удалить, а какие лучше оставить

Дата файла сама по себе не показывает, можно ли удалить backup. Один плагин создаёт единственный ZIP, другой — несколько архивов с файлами сайта, отдельный SQL-дамп и служебные метаданные. Здесь легко удалить не тот набор.

Перед очисткой выясните тип копии:

• полная резервная копия;
• только база данных;
• только файлы WordPress;
• incremental backup;
• несколько частей одного набора;
• архив плюс metadata/config;
• незавершённый файл после ошибки.

Архив на диске ещё не означает рабочий backup. Лучший тест — восстановление на staging или другом тестовом окружении.

Если тестового восстановления нет, минимальный набор признаков такой: задание завершилось успешно, размер не выглядит аномальным, присутствуют все части комплекта, а внешняя копия действительно доступна.

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

Как настроить ротацию резервных копий, чтобы WordPress снова не заполнил диск

Политику хранения нужно рассчитывать по реальному размеру backup и доступному месту, а не выбирать количество копий наугад. Если одна полная копия занимает 8 GB, семь локальных копий потребуют около 56 GB ещё до учёта сайта, базы, логов и временных данных.

Первый ориентир:

объём хранимых backup ≈ средний размер одной копии × количество копий

Допустим:

• сайт занимает около 8 GB;
• готовая полная копия тоже близка к 8 GB;
• свободно 30 GB.

Семь копий физически не поместятся. Даже три займут около 24 GB и оставят слишком маленький запас.

Почему размера готового архива недостаточно для расчёта

Самая частая ошибка в такой арифметике — считать только финальный ZIP или TAR. Во время backup место может одновременно понадобиться для SQL-дампа, временных файлов, промежуточного архива и новой копии, которая создаётся до удаления старой.

Например, готовый архив весит 5 GB. Это не означает, что запуску достаточно ровно 5 GB свободного места. Пиковое потребление может быть выше.

В расчёте нужно оставить запас на:

• временный дамп базы данных;
• промежуточные файлы упаковки;
• новую копию до удаления старой;
• рост самого сайта;
• логи и рабочие файлы PHP/MySQL.

Если политика хранения «сходится» только при условии, что свободного места останется почти ноль, она не сходится.

Как оценить допустимое число локальных копий

Измерьте реальный каталог:

du -sh /path/to/backups

Посмотрите размеры нескольких последних успешных наборов, а не одного самого маленького. Сайт растёт, поэтому сегодняшние 4 GB через несколько месяцев могут превратиться в 6–7 GB.

После этого определите предел локальной истории так, чтобы следующий backup мог создаться без аварийного заполнения диска.

Нужно ли хранить все ежедневные копии локально

Не всегда. Для быстрого восстановления удобно держать несколько свежих точек на VPS, а длинную историю — вне него.

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

Проверяется настройка только на следующем автоматическом цикле. Если политика говорит «3 локальные копии», после создания новой лишний старый набор должен уйти. Если число файлов продолжает расти — ротация не работает.

Почему резервные копии лучше не хранить только на том же VPS

Для проблемы с переполненным диском главное преимущество внешнего хранилища простое: длинную историю backup не приходится держать рядом с рабочим WordPress. Локально можно оставить несколько свежих точек, а остальные копии вынести с VPS.

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

Remote backup работает, а локальный каталог всё равно растёт

Проверьте четыре вещи:

• появилась ли свежая копия во внешнем хранилище;
• совпадает ли её время с последним запуском;
• успешно ли завершилась отправка по журналу;
• есть ли после upload отдельный этап удаления или pruning локального архива.

Если журнал говорит Upload successful, но число локальных копий увеличилось с пяти до шести, проблема не в передаче файла. Нужно искать настройку локального retention или ошибку cleanup.

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

После настройки скачайте или хотя бы проверьте доступность свежего набора независимо от VPS. Если удалённый файл существует только «по сообщению плагина», это ещё слабое подтверждение.

Как проверить, что WordPress больше не накапливает резервные копии

Проверка закончена только после реального автоматического цикла. Ручная очистка каталога и сохранённая настройка retention ещё не показывают, как система поведёт себя ночью.

Зафиксируйте состояние до следующего backup

Снимите контрольные показатели:

df -h
du -sh /path/to/backups
ls -lt /path/to/backups
find /path/to/backups -maxdepth 1 -type f | wc -l

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

Допустим, каталог занимает 14 GB, в нём три полных набора, а политика хранения тоже ограничена тремя. Дождитесь следующего автоматического запуска и повторите те же команды.

Что должно произойти после контрольного запуска

• новая резервная копия успешно создаётся;
• журнал заканчивается успешным статусом;
• при внешнем хранении новая копия появляется и там;
• лишний старый набор удаляется согласно политике хранения;
• общий объём каталога остаётся в прогнозируемом диапазоне;
• свободное место не уменьшается после каждого запуска без возврата;
• не появляется второй независимый набор от другого cron или плагина.

Если было три набора, после следующего запуска стало четыре, а затем пять, настройка хранения не работает. Возвращайтесь к журналу и проверяйте, на каком этапе обрывается очистка.

Если копии появляются дважды

Сравните время новых файлов с:

wp cron event list
crontab -l
sudo crontab -l
systemctl list-timers --all

Не забудьте о timezone. Если два задания выглядят разнесёнными на час, сначала убедитесь, что WordPress и сервер показывают время в одной системе.

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