Сайт небольшой, несколько сотен страниц, фотографии, обычный WordPress, никаких видеороликов и огромных файлов. Владелец уверен, что весь проект занимает два или три гигабайта. Потом однажды открывает панель хостинга и видит: из 20 ГБ свободно меньше гигабайта.
Первая реакция обычно вполне логичная: откуда взялись остальные гигабайты?
Иногда ответ находится за пять минут. В корневой папке лежит старый архив размером 8 ГБ, который сделали перед переносом сайта и благополучно забыли. Иногда расследование получается интереснее. Сам WordPress действительно занимает сравнительно немного, зато рядом годами копились резервные копии, почта, логи, кэш, временные файлы и несколько поколений изображений.
У дискового пространства есть неприятное свойство: оно заканчивается постепенно, а замечают это обычно внезапно.
Пока свободно 15 ГБ, никто не интересуется, что именно лежит на сервере. При 5 ГБ тоже вроде бы рано волноваться. А потом какой-нибудь плагин ночью создает очередной бэкап, свободное место сокращается почти до нуля, и сайт начинает вести себя странно. Не загружаются изображения, не создается резервная копия, не обновляется CMS, почта возвращает ошибки или база данных не может нормально выполнять операции.
В этот момент очень хочется открыть файловый менеджер, отсортировать папки по размеру и удалить все самое большое.
Вот этого как раз делать не стоит.
Сначала нужно выяснить, кто съел диск
Цифра «занято 18 ГБ» сама по себе почти ничего не объясняет. Нужно понять, из чего она складывается.
Начать проще всего со статистики дискового пространства в панели хостинга. Хорошая панель позволяет увидеть размеры каталогов, баз, почтовых ящиков или хотя бы общую разбивку по услугам. Если такой информации нет, файловый менеджер или инструменты анализа диска помогут определить самые тяжелые директории.
Но размер папки еще не отвечает на вопрос, можно ли ее удалять.
Представим, что обнаружена директория объемом 9 ГБ. Если это каталог с резервными копиями, часть старых архивов действительно может оказаться ненужной. Если это папка uploads рабочего WordPress, внутри находятся изображения сайта. Освободить 9 ГБ удалением каталога получится великолепно, только вместе с ними исчезнет значительная часть содержимого страниц.
Поэтому задача не «найти большие файлы», а «понять происхождение больших файлов».
Самый очевидный подозреваемый — резервные копии.
Бэкап способен занимать примерно столько же места, сколько данные, которые в него попали, хотя итоговый размер зависит от содержимого и способа создания архива. Если сайт разросся до нескольких гигабайт и каждый день создается новая полная копия, место заканчивается довольно быстро.
Особенно забавно это выглядит, когда резервированием занимаются сразу несколько систем. Хостер делает собственные копии. В WordPress установлен плагин, который тоже ежедневно архивирует сайт. А второй плагин когда-то добавил разработчик «на всякий случай».
В результате владелец уверен, что у него один сайт, а на диске фактически лежит сайт плюс несколько его прошлых жизней.
Есть и более неприятная ошибка. Архивы сохраняются внутри директории, которая затем снова попадает в следующий бэкап. Вчерашняя копия становится частью сегодняшней, сегодняшняя завтра тоже отправляется внутрь нового архива. Размер начинает расти совершенно не так, как ожидалось.
Поэтому каталоги с названиями backup, backups, archive, old, temp и похожими стоит проверить одними из первых. Но название ничего не гарантирует. Плагины могут использовать собственные директории, а человек способен назвать архив как угодно.
Еще один классический случай вообще не связан с автоматикой.
Перед переносом сайта администратор создает ZIP на 6 ГБ. Скачивает его на компьютер. Переезд проходит успешно. Архив остается в корне сайта, потому что удалить его никто не вспомнил.
Через год происходит следующий перенос. Создается новый архив, теперь уже на 8 ГБ. Его тоже скачивают и забывают.
Сам рабочий сайт занимает 8 ГБ. Но аккаунту требуется уже 22 ГБ, потому что рядом лежат две ненужные копии. Владелец смотрит на тариф и начинает думать о покупке дополнительного диска, хотя почти две трети занятого пространства не участвуют в работе сайта.
WordPress умеет размножать фотографии, а почта умеет хранить прошлое
Следующий подозреваемый часто находится в wp-content/uploads.
Пользователь загружает одну фотографию и видит в медиатеке одну фотографию. На сервере все может быть интереснее. WordPress создает дополнительные размеры изображений для разных задач. Тема и плагины способны регистрировать собственные варианты. В результате рядом с оригиналом появляются миниатюры и промежуточные размеры.
Само по себе это нормальная работа системы. Маленькой карточке товара не обязательно загружать огромную фотографию с камеры. Для разных мест интерфейса используются подходящие размеры.
Но сайт меняется. Устанавливается новая тема, потом другая. Плагины добавляются и удаляются. Требования к изображениям меняются, а старые сгенерированные файлы могут продолжать лежать на диске.
Если за годы было загружено много фотографий, объем uploads иногда оказывается неожиданно большим. Особенно на интернет-магазинах, фотосайтах, портфолио и новостных проектах.
Это не означает, что можно открыть uploads и удалить все файлы с дефисами в названиях. Часть миниатюр используется текущей темой, часть может быть нужна плагинам, а некоторые страницы способны ссылаться на конкретный размер.
Безопасная очистка изображений требует понимания того, какие размеры используются сейчас, и наличия резервной копии. Иногда проще сначала оптимизировать новые изображения и разобраться с ненужными размерами на тестовой копии сайта, чем устраивать массовое удаление на рабочем проекте.
Кроме картинок, в wp-content могут жить кэши, логи, временные файлы, архивы обновлений и данные плагинов. Некоторые каталоги очищаются автоматически, другие годами растут незаметно.
Но рекордсменом по способности удивлять владельца бывает почта.
Человек оценивает размер сайта по файлам WordPress и совершенно забывает, что на том же тарифе находятся ящики info@, manager@, order@ и еще несколько адресов сотрудников. Письма не исчезают после прочтения. Вложения тоже занимают место. Корзина и папка «Отправленные» могут храниться на сервере. Спам иногда копится месяцами.
Один старый почтовый ящик способен занимать больше места, чем небольшой корпоративный сайт.
Особенно если через него годами пересылали фотографии, PDF, прайс-листы, презентации и документы. Для пользователя это просто история переписки. Для сервера — тысячи файлов и гигабайты данных.
Поэтому при загадочной нехватке диска нужно смотреть не только файловый менеджер сайта, но и размеры почтовых ящиков.
Здесь тоже нельзя бездумно нажимать «удалить все». Деловая переписка может быть нужна компании. Сначала решается, что необходимо сохранить и где это будет храниться, а уже потом освобождается сервер.
Еще одно место, где незаметно растет история, — журналы.
Логи полезны, когда нужно понять, почему произошла ошибка, кто обращался к серверу или что делал определенный процесс. Но неправильно настроенный журнал способен расти очень долго. Особенно если сайт постоянно генерирует одну и ту же ошибку и записывает ее тысячи раз.
Иногда владелец обнаруживает многогигабайтный error_log и радуется: вот он, мусор, можно удалить. Удалить старый огромный лог после сохранения нужной информации действительно может быть разумно, но интереснее выяснить, почему он стал огромным.
Если приложение продолжает каждую секунду записывать новую ошибку, очищенный файл скоро вырастет снова.
То же самое относится к кэшу. Кэш создается для ускорения работы, поэтому его содержимое обычно можно пересоздать. Но механизмов кэширования бывает несколько: CMS, плагин, сервер, CDN. Удалять незнакомые каталоги вручную только потому, что в названии встречается cache, не стоит. Лучше использовать штатную функцию очистки конкретной системы.
Иногда на хостинге живет больше сайтов, чем помнит владелец
Есть особенно интересная категория находок: забытые проекты.
Несколько лет назад сайт переносили с Joomla на WordPress. Старую версию не удалили, а переименовали папку в site_old. Потом сделали еще одну копию перед редизайном и назвали old2. Позже разработчик создал test для экспериментов.
Все три директории остались на сервере.
Главный сайт занимает 4 ГБ, а его археологический музей еще 11.
С точки зрения диска не имеет значения, открывает кто-нибудь эти копии или нет. Файлы занимают место одинаково хорошо.
Кроме дискового пространства старые копии могут создавать проблему безопасности. Забытый WordPress с устаревшими плагинами не становится безопасным только потому, что владелец перестал на него заходить. Если копия доступна из интернета и код выполняется, она остается частью инфраструктуры.
Поэтому обнаруженный old-site лучше не просто воспринимать как несколько лишних гигабайт. Нужно понять, нужен ли он вообще, доступен ли извне и есть ли причина продолжать хранить его на рабочем сервере.
Похожая история происходит со staging-сайтами. Тестовая копия очень удобна для обновлений и разработки. Но это практически еще один сайт: файлы, база, изображения. Если staging автоматически клонирует production, расход диска может почти удвоиться.
Для серьезного проекта это нормальная цена безопасной разработки. Просто ее нужно учитывать при выборе тарифа. А вот пять старых staging-копий, каждая из которых создавалась для разовой задачи и больше никогда не использовалась, уже повод для уборки.
Не забываем и о базах данных.
На обычном WordPress база часто заметно меньше каталога изображений, но бывают исключения. Магазины, статистические плагины, журналы действий, очереди, сессии, старые ревизии и служебные таблицы способны разрастаться.
Особенно подозрительно выглядят таблицы от давно удаленных плагинов. Удаление самого плагина не всегда означает удаление всех созданных им данных. Иногда это сделано специально, чтобы настройки сохранились при повторной установке.
Но чистить базу вручную без понимания структуры гораздо опаснее, чем удалить забытый ZIP. Название таблицы не всегда очевидно говорит о ее назначении, а ошибочное удаление может повредить сайт.
Если база действительно стала необычно большой, сначала нужна ее резервная копия, затем анализ таблиц и только после этого очистка. Для новичка это тот случай, когда помощь специалиста дешевле восстановления после эксперимента.
Что действительно можно удалить, а к чему лучше не прикасаться
Универсального списка «эти папки удаляйте всегда» не существует. Один и тот же файл в одном проекте является ненужным архивом, а в другом участвует в рабочем процессе.
Но есть хороший принцип: безопаснее всего удалять то, происхождение и назначение чего вы точно установили.
Например, вы собственноручно создали backup-before-move.zip два года назад, скачали его на компьютер, проверили архив, а сайт после этого давно работает на новой площадке. Если этот файл все еще лежит в корне и больше нигде не используется, его назначение понятно.
Или в панели почты видно, что старый тестовый ящик занимает 4 ГБ и он точно больше не нужен. Это тоже понятная ситуация.
Или штатная функция плагина показывает кэш объемом 2 ГБ и предлагает кнопку его очистки. Здесь не требуется вручную угадывать, какие файлы принадлежат кэшу.
Совсем другое дело — незнакомая папка размером 7 ГБ внутри рабочего сайта. Удалять ее только ради красивой цифры свободного места нельзя.
Перед серьезной уборкой стоит сделать резервную копию. Звучит немного иронично: мы пытаемся освободить место от бэкапов и для этого создаем еще один. Но актуальная копия перед изменениями действительно нужна. Просто ее лучше сохранить за пределами очищаемого аккаунта.
После этого удобно идти от самого очевидного к менее очевидному.
Сначала старые ручные ZIP, TAR и другие архивы. Затем ненужные резервные копии, если точно известно, какой системой они созданы и какие версии необходимо оставить. Потом почтовые ящики, старые тестовые сайты и staging. Далее логи и кэш через штатные средства. И только после этого имеет смысл углубляться в изображения и базу данных.
Такой порядок хорош тем, что первые несколько находок нередко решают проблему полностью.
Владелец собирался оптимизировать базу, удалять миниатюры и покупать дополнительное место, а потом обнаружил в папке public_html три архива по 5 ГБ. На этом расследование можно закончить.
Есть еще одна полезная привычка: после удаления посмотреть, изменилось ли значение занятого пространства. Некоторые панели пересчитывают квоту не мгновенно. Корзина файлового менеджера тоже может продолжать занимать место, если удаленные данные фактически перемещаются в специальный каталог.
Если место освободилось, не обязательно останавливаться на цифре. Хорошо понять, почему оно закончилось. Иначе через полгода ситуация повторится.
Бэкапы копились без ограничения? Настройте количество хранимых версий. Почта занимает половину тарифа? Определите правила хранения. Лог вырос из-за постоянной ошибки? Исправьте ошибку. Плагин создает огромный кэш? Разберитесь с его настройками. Старые копии сайтов никто не удаляет? Добавьте очистку после завершения работ в обычный процесс.
Тогда освобождение места превращается не в разовую уборку, а в устранение причины.
И только если после такой проверки выясняется, что почти все пространство действительно занято нужными данными, пора признать очевидное: сайт вырос.
Это тоже нормальная ситуация. Фотографий стало больше, каталог расширился, почтовая история нужна, резервные копии организованы правильно, staging используется для разработки. В этом случае дополнительное дисковое пространство не является переплатой за мусор. Проект действительно требует больше места.
Но покупать новый объем лучше после расследования, а не до него.
Разница может быть впечатляющей. В одном аккаунте 20 ГБ заняты полезными данными и увеличение тарифа неизбежно. В другом из тех же 20 ГБ половина приходится на два старых архива, еще несколько гигабайт на забытый тестовый сайт, а остальное съедает почтовый ящик сотрудника, который уволился три года назад.
Панель хостинга в обоих случаях показывает одну и ту же цифру. Истории за ней совершенно разные.
Поэтому сообщение о заканчивающемся диске лучше воспринимать не как предложение срочно купить гигабайты, а как повод впервые за долгое время заглянуть в кладовку.
У сайтов тоже появляется цифровой чердак, туда складывают резервные копии на всякий случай, архив перед прошлогодним переносом, тестовую версию, старую тему, письма с огромными вложениями и логи, которые никто никогда не открывал. Пока места много, все это никому не мешает.
А потом свободными остаются последние 600 МБ, и выясняется, что самому сайту вовсе не было тесно. Просто за несколько лет вокруг него накопилось слишком много вещей, которые однажды собирались разобрать потом.
