Многие владельцы сайтов думают так: ну база данных же есть — значит, бэкап тоже есть. И вот тут начинается самое неприятное. Потому что когда сайт падает, взламывается или после кривого апдейта все едет, одной базы часто тупо мало. Особенно если у вас не просто визитка, а магазин на WooCommerce с товарами, фото, заказами и письмами.
Смотрите, база — это важно. Но сайт не живет одной базой. У него есть файлы, загрузки, настройки, тема, плагины, иногда кастомный код, иногда платежные интеграции, иногда вообще полуручной костыль, про который все забыли. И когда этого нет в бэкапе, восстановление превращается в квест на 6-12 часов, а то и дольше.
Короче, давайте без мифов. Разберем, что реально надо сохранять, как часто это делать и где люди обычно косячат.
Почему одного бэкапа базы недостаточно
База данных хранит много важного: страницы, записи, настройки, заказы, юзеров, иногда часть настроек плагинов. Но картинки товаров, PDF, видео, файлы темы, скрипты, иконки, фавикон, шрифты — все это обычно лежит в файлах сайта. То есть вне базы.
Представьте ситуацию. У вас магазин одежды. База сохранилась, заказы вроде на месте. А папка uploads пропала. Что получаем? Карточки товаров есть, а фото нет. Баннеров нет. Документов нет. И магазин выглядит как недоделанный скелет.
А теперь еще веселее — если пропали файлы темы или кастомные правки, сайт может вообще не открыться. И да, это случается чаще чем кажется.
Что реально надо бэкапить
Вот нормальный минимум, без которого бэкап я бы вообще не называл бэкапом.
- Базу данных — страницы, посты, настройки, формы, заказы, клиенты.
- Папку wp-content/uploads — все изображения, PDF, медиафайлы, иногда импортированные прайсы.
- Тему сайта — особенно если шаблон дорабатывали руками.
- Плагины — не всегда критично, но лучше хранить. Иногда старая версия плагина нужна для нормального восстановления.
- wp-config.php и другие системные файлы — там доступы к базе, ключи безопасности и важные настройки.
- .htaccess или настройки сервера — редиректы, защита, правила кеша.
- Отдельные внешние интеграции — платежки, CRM, SMTP, склад, доставка. Не всегда они лежат в бэкапе целиком, но их настройки надо где-то хранить.
Если у вас интернет-магазин, я бы добавил еще экспорт заказов и клиентов раз в неделю отдельно. Да, это уже перестраховка. Но честно говоря, для бизнеса это нормальная перестраховка.
Что чаще всего забывают сохранять
На практике проблема не в том, что бэкапа нет. Проблема в том, что он «как бы есть», но неполный. Вот самые частые пробелы.
- Фото товаров — особенно после массового импорта.
- Файлы, загруженные через формы — брифы, документы, вложения.
- Кастомный код — куски в functions.php, snippets, ручные правки шаблона.
- Настройки почты — после восстановления письма с заказами могут просто перестать уходить.
- Редиректы и SEO-настройки — потом трафик проседает, а владелец не понимает почему.
- Лицензии и ключи плагинов — сайт восстановили, а половина функций отключилась.
Кстати, если вам кажется, что «ну это же можно потом заново настроить» — да, можно. Вопрос только во времени. Иногда «заново настроить» это 20 минут. А иногда — два дня переписки с техподдержкой сервисов и платежек.
Как часто делать бэкапы — без фанатизма, но с головой
Тут все зависит от типа сайта. Нет смысла делать одинаковый график для лендинга и для магазина с ежедневными заказами.
- Сайт-визитка или лендинг — обычно хватает раз в неделю + перед любыми изменениями.
- Корпоративный сайт с блогом — раз в день для базы, раз в неделю для файлов.
- Интернет-магазин — база хотя бы каждые 6-12 часов, файлы раз в день.
- Активный магазин с рекламой и постоянными заказами — база каждый час или каждые 2-4 часа.
И да — перед обновлением WordPress, плагинов или темы всегда делайте отдельный ручной бэкап. Если никогда этого не делали, очень советую прочитать статью Что будет, если никогда не обновлять WordPress. Там как раз про то, почему «потом обновлю» часто заканчивается поломками.
По времени это обычно недолго. Настроить автоматические копии можно за 30-60 минут. Если сайт простой. Если магазин с кучей интеграций — может уйти 2-3 часа, потому что надо еще проверить, что копируется все нужное, а не чо попало.
Где хранить бэкапы, чтобы от них был толк
Самая глупая ошибка — хранить резервные копии на том же хостинге, где лежит сайт. Если сервер умер, взломан или аккаунт заблокировали, вы теряете и сайт, и бэкап. Ну супер.
Нормальная схема такая:
- одна копия на хостинге для быстрого отката
- одна копия во внешнем облаке — Google Drive, Dropbox, S3 или другой сторедж
- для магазина — иногда еще локальная копия раз в месяц
Для малого бизнеса этого более чем хватит. Не надо строить enterprise-схему с тремя дата-центрами. Это уже оверкилл и лишние деньги. Но одна внешняя копия — обязательно, без нее вся идея резервирования полусырая.
Бэкап без проверки — почти бесполезен
Вот реально важный момент. Люди настраивают бэкапы, видят зеленую галочку и успокаиваются. А потом в день Х выясняется, что архив битый, база пустая или файл весит 12 КБ вместо 2 ГБ. Да-да, бывает и такк.
Что стоит делать хотя бы раз в месяц:
- проверить, что новые архивы вообще создаются
- посмотреть размер файлов — слишком маленький размер уже подозрителен
- убедиться, что копии уходят во внешнее хранилище
- сделать тестовое восстановление на отдельном стенде
Тестовое восстановление — это вообще золотой стандарт. Да, звучит скучно. Но зато потом не будет сюрприза в духе «бэкап был, но восстановить нельзя». Если не хотите возиться с этим сами, проще отдать это в поддержку и управление сайтом — там как раз такие рутинные штуки и закрываются нормально.
Что делать владельцу интернет-магазина отдельно
У магазина рисков больше, потому что там постоянно меняются данные. Заказы, остатки, клиенты, купоны, статусы доставки. Если вы потеряли данные за последние сутки — это уже не «ну ладно», это деньги.
Поэтому для магазина я советую такой базовый набор:
- частые бэкапы базы
- ежедневный бэкап файлов
- еженедельный экспорт заказов в CSV
- отдельно список товаров или экспорт каталога
- список всех интеграций и доступов в одном документе
Если магазин только планируете, лучше сразу строить его так, чтобы резервирование было продумано с первого дня. Это сильно проще, чем латать все потом. И да, нормальную структуру магазина обычно проще настроить сразу при разработке интернет-магазина, чем потом переделывать на живом проекте под заказы и рекламу.
Когда обычного бэкапа уже мало
Иногда проблема не просто в случайной поломке. Иногда сайт взломали, подменили файлы, вставили вирусный код или сделали скрытые редиректы. И тут восстановить архив мало — надо еще понять, чистый ли он.
Если у вас были странные пользователи в админке, всплывающие редиректы, предупреждение от Google или хостер прислал письмо про malware, почитайте еще Бэкапы — скучная штука, которая спасает бизнес. Там хорошо видно, почему резервные копии — это не формальность, а реально страховка.
А если сайт уже под атакой или после взлома, лучше не гадать и не тыкать все подряд. Тут уже нужна нормальная проверка и чистка безопасности сайта, иначе можно восстановить зараженный архив и снова получить ту же проблему через день.
Итог — что стоит сделать прямо сейчас
Если коротко: бэкапить надо не только базу, а весь рабочий набор сайта. База, файлы, загрузки, тема, плагины, конфиги, интеграции. И плюс проверять, что это все реально восстанавливается.
Прямо сегодня можно сделать вот что:
- посмотреть, что именно копирует ваш текущий плагин или хостинг
- проверить, есть ли в бэкапе uploads и файлы темы
- настроить внешнее хранение копий
- сделать тестовое восстановление
- если у вас магазин — добавить отдельный экспорт заказов
На самом деле это не какая-то космическая задача. Для простого сайта — вечер работы. Для магазина — полдня, иногда день. Но зато потом вы не сидите в панике, когда после апдейта или взлома все валится. А для малого бизнеса это уже огромная разница.