Папка cache почти всегда раздувает архивы резервных копий и редко нужна для восстановления сайта в исходном виде. Но просто удалить её из бэкапа — не всегда безопасно: у разных плагинов кэш лежит в разных местах, а некоторые решения хранят там не только временные файлы, но и служебные данные. Ниже — рабочая схема, как понять, что именно можно исключить, и как проверить, что бэкап после этого остаётся пригодным для восстановления.
Когда cache действительно стоит исключать
Обычно речь идёт о временных файлах, которые WordPress и плагины пересоздают сами: HTML-кэш, минифицированные CSS/JS, фрагменты изображений, временные файлы оптимизации. Если вы храните такие данные в резервной копии, то получаете лишний объём и более долгую упаковку архива без заметной пользы.
Исключение папки cache особенно полезно, если:
- резервные копии стали заметно дольше создаваться;
- архивы занимают слишком много места в облаке или на диске;
- в бэкап попадают временные файлы плагинов кэширования и оптимизации;
- вы делаете частые бэкапы и хотите снизить нагрузку на диск.
Диагностика: что именно у вас лежит в cache
Перед настройкой исключения проверьте, не хранится ли в этой папке что-то критичное. В WordPress нет единого стандарта расположения кэша, поэтому сначала нужно найти источник.
Где обычно находится кэш
Чаще всего встречаются такие пути:
wp-content/cache/— общий каталог для кэша плагинов;wp-content/uploads/cache/— кэш внутри uploads;wp-content/litespeed/или похожие каталоги конкретных решений;- папки с именами плагинов, где кэш — только часть структуры.
Если вы работаете по SSH, быстро посмотреть содержимое можно так:
cd /path/to/wordpress/wp-content/cache
find . -maxdepth 2 -type f | head -n 30Если файлов очень много и они выглядят как временные, минифицированные или сгенерированные, их обычно можно исключать. Если внутри есть файлы, которые явно относятся к служебным данным плагина, сначала проверьте документацию этого плагина.
Что нельзя удалять без проверки
Не стоит автоматически исключать всё подряд, если в папке лежат:
- файлы очередей задач;
- временные данные миграции;
- служебные файлы плагинов, которые не пересоздаются без потерь;
- кэш, который используется как часть рабочего процесса, а не как временный слой.
Пошаговое решение: исключаем cache из бэкапа
Способ зависит от того, чем вы делаете резервное копирование. Логика одна: найти правило исключения папки и добавить туда путь к cache.
Вариант 1. Через настройки плагина резервного копирования
Если плагин умеет исключать каталоги по маске или пути, добавьте туда точный путь. Лучше исключать не абстрактное слово cache, а полный путь, например wp-content/cache. Так вы не заденете другие папки с похожим названием.
Если плагин принимает шаблоны, проверьте, как он обрабатывает слэши и относительные пути. Ошибка в одном символе часто приводит к тому, что папка всё равно попадает в архив.
Вариант 2. Через фильтр в коде
Если вы пишете собственную интеграцию или используете плагин с фильтром исключений, можно добавить путь программно. Ниже пример для сценария, где плагин отдаёт массив путей через фильтр. Название фильтра зависит от конкретного решения, поэтому используйте этот код только как шаблон логики, а не как готовую вставку без проверки документации.
<?php
add_filter( 'my_backup_exclude_paths', function( $paths ) {
$paths[] = WP_CONTENT_DIR . '/cache';
$paths[] = WP_CONTENT_DIR . '/uploads/cache';
return array_unique( $paths );
} );Если ваш плагин работает с относительными путями, используйте путь относительно корня WordPress:
<?php
add_filter( 'my_backup_exclude_paths', function( $paths ) {
$paths[] = 'wp-content/cache';
$paths[] = 'wp-content/uploads/cache';
return array_values( array_unique( $paths ) );
} );Смысл один: исключать нужно именно каталог, а не отдельные файлы внутри него, иначе кэш будет продолжать разрастаться и попадать в архив частично.
Вариант 3. Если бэкап делается через WP-CLI или shell-скрипт
Когда резервное копирование запускается из скрипта, проще всего добавить исключение на уровне архивации. Для tar это выглядит так:
tar --exclude='wp-content/cache' --exclude='wp-content/uploads/cache' -czf backup.tar.gz /path/to/wordpressДля rsync можно использовать файл исключений:
wp-content/cache/
wp-content/uploads/cache/И запуск:
rsync -a --exclude-from=/path/to/excludes.txt /path/to/wordpress/ /backup/wordpress/Этот подход удобен, если вы хотите держать правила исключения в одном месте и не зависеть от интерфейса плагина.
Сравнение подходов
| Подход | Когда подходит | Плюс | Минус |
|---|---|---|---|
| Настройка в плагине | Обычный сайт без кастомной логики | Быстро и без кода | Зависит от возможностей плагина |
| Фильтр в коде | Есть своя интеграция или тема/плагин с хуками | Гибко и повторяемо | Нужно знать точный фильтр |
| Исключение на уровне tar/rsync | Бэкап делается скриптом | Независимо от WordPress | Нужно поддерживать скрипт отдельно |
Проверка результата после внедрения
После настройки не ограничивайтесь тем, что архив стал меньше. Нужно убедиться, что исключение сработало и восстановление не сломалось.
- Сделайте новый бэкап.
- Откройте список файлов в архиве или журнал создания копии.
- Проверьте, что
wp-content/cacheи другие исключённые каталоги отсутствуют. - Сравните размер архива с предыдущей копией.
- Если есть тестовый стенд, восстановите копию туда и проверьте фронтенд и админку.
Для архива tar.gz можно быстро посмотреть содержимое так:
tar -tzf backup.tar.gz | grep 'wp-content/cache'Если команда ничего не выводит, каталог не попал в архив. Но это ещё не финальная проверка: после восстановления откройте сайт и убедитесь, что кэш пересоздаётся автоматически, а не вызывает ошибки плагина.
Частые ошибки и как их исправить
Исключили не ту папку
Ошибка типичная: в настройках написали просто cache, а плагин исключил всё, что содержит это слово, или наоборот не исключил ничего. Используйте полный путь, а не общее имя.
Удалили кэш, который нужен плагину для работы
Некоторые плагины используют кэш как рабочее хранилище. Если после восстановления сайт начал выдавать ошибки или долго пересоздаёт данные, верните папку в бэкап и проверьте документацию конкретного плагина.
Проверили только размер архива
Меньший архив не гарантирует корректный бэкап. Обязательно делайте тестовое восстановление хотя бы на staging-сайте. Иначе можно обнаружить проблему уже в момент инцидента.
Забыли про несколько мест хранения кэша
На одном сайте кэш может лежать в wp-content/cache, а на другом — ещё и в папке плагина оптимизации. Если исключить только один каталог, экономия будет частичной. Сначала соберите список всех путей, потом добавляйте их в правила.
Практические советы по безопасности и производительности
Если кэш исключён из резервной копии, это не значит, что его можно оставлять без контроля. Важно следить за тем, чтобы он не разрастался бесконечно и не забивал диск.
- очищайте кэш по расписанию средствами плагина, а не вручную через FTP;
- не храните кэш в каталоге, который попадает под публичную индексацию;
- проверяйте права доступа к папкам, чтобы временные файлы не стали точкой утечки;
- если бэкап идёт по расписанию, не запускайте очистку кэша одновременно с созданием архива.
Если у вас WooCommerce, особенно аккуратно относитесь к кэшу страниц корзины, оформления заказа и личного кабинета. Их обычно не исключают из бэкапа как данные, но кэш этих страниц должен быть настроен так, чтобы не ломать динамические элементы при работе сайта.
Когда нужен более широкий контроль над дублями, кэшем и лишними служебными файлами, удобно сочетать резервное копирование с инструментами очистки сайта. Например, в Clearfy Pro есть функции, которые помогают убрать часть технического мусора и снизить объём лишних данных на сайте: https://wpshop.ru/plugins/clearfy.
Мини-чек-лист перед включением исключения
- Папка cache найдена и проверена вручную.
- Понятно, какой плагин её создаёт.
- Известно, можно ли пересоздать содержимое без потерь.
- Правило исключения задано полным путём.
- Сделан тестовый бэкап.
- Проверено восстановление на staging или локальной копии.
Если после этого архив стал компактнее, а сайт после восстановления работает как раньше, значит исключение настроено правильно. Если же кэш продолжает попадать в копию или сайт после восстановления ведёт себя иначе, возвращайтесь к диагностике путей и конкретного плагина, который создаёт эти файлы.