Коротко. В бэкап сайта входят два обязательных компонента — файлы (движок, тема, загруженные медиа, конфиги) и база данных, отдельно бэкапить одно без другого бессмысленно. Копии хранят минимум в двух местах, ни одно из которых не совпадает с самим сервером — иначе при взломе или отказе диска пропадёт и сайт, и его резервная копия одновременно. Бэкап, который ни разу не разворачивали на тестовом окружении, нельзя считать рабочим: по опыту восстановления сайтов, у 20-30% копий на практике не хватает файлов, прав доступа или версии PHP, и это выясняется только в момент аварии.
Из чего состоит полноценный бэкап
Сайт — это не только файлы, которые видно в панели хостинга. Полная копия должна закрывать четыре слоя, и пропуск любого из них делает восстановление неполным или невозможным:
- Файлы движка и темы. Ядро CMS, активная тема или шаблон, установленные плагины и модули — без них сайт не соберётся, даже если база цела.
- База данных. Тексты страниц, товары, заказы, настройки — на WordPress это обычно MySQL-дамп, на 1С-Битрикс своя структура таблиц. Без базы файлы превращаются в пустой каркас без содержимого.
- Медиафайлы и загрузки. Папка uploads на WordPress, upload на Битрикс — фотографии товаров, документы, файлы из форм. Эти данные не хранятся в базе и требуют отдельного бэкапа файловой части.
- Конфигурационные файлы. wp-config.php, .env, файлы с ключами API и настройками подключения к базе. Без них восстановленный сайт не «увидит» свою базу данных и не подключится к внешним сервисам — платёжным системам, CRM, счётчикам аналитики.
Отдельно стоит SSL-сертификат — если он выпущен не через Let’s Encrypt с автопродлением, а куплен отдельно, его тоже стоит держать в архиве вместе с приватным ключом.
Полный и инкрементальный бэкап — когда какой нужен
Полный бэкап копирует весь сайт целиком — это самый надёжный вариант, но и самый тяжёлый по объёму и времени. Для сайта на WordPress с базой на 300-500 МБ и медиатекой в несколько гигабайт полный архив создаётся 10-40 минут в зависимости от мощности хостинга и занимает от 1 до 10 ГБ.
Инкрементальный бэкап сохраняет только изменения с прошлой копии — база данных при этом почти всегда копируется целиком заново (она меняется слишком часто и не позволяет собрать полную картину из фрагментов), а вот медиафайлы дозаписываются только новые. Такой подход экономит место при ежедневном расписании, но требует хранить всю цепочку копий, а не только последнюю: если промежуточное звено повредится, все следующие инкременты становятся бесполезны.
Практический ориентир: интернет-магазину с ежедневными заказами нужна ежедневная копия базы данных и полный бэкап файлов раз в неделю. Лендингу или сайту-визитке, который меняется раз в месяц, достаточно бэкапа перед каждым внесением правок плюс автоматической копии раз в неделю на случай технического сбоя хостинга.
Принцип 3-2-1 и куда фактически складывать копии
Правило резервного копирования, которое используют в инженерной практике: минимум 3 копии данных, на 2 разных типах носителей, и минимум 1 копия — вне основной площадки, физически на другом сервере или у другого провайдера.
Применительно к сайту это означает: одна копия может лежать на самом хостинге для быстрого отката, но она не считается защитой — при взломе через уязвимость плагина злоумышленник получает доступ и к бэкапам в той же директории, при отказе диска сервера пропадает всё одновременно. Вторая и третья копии должны уходить во внешнее хранилище — облако (Яндекс.Диск, Google Drive, S3-совместимое хранилище) или на выделенный FTP/SFTP-сервер, не связанный с хостингом сайта.
| Место хранения | Плюсы | Ограничения |
|---|---|---|
| Тот же сервер хостинга | Мгновенный доступ, быстрый откат | Не защищает от взлома сервера и отказа диска — это не резервная копия, а просто вторая папка |
| Облачное хранилище | Доступно из любой точки, автоматизируется плагинами и скриптами | Зависит от стабильности интернет-канала при восстановлении больших архивов |
| Отдельный физический сервер / VPS | Полная независимость от основного хостинга | Требует отдельной настройки и оплаты, есть смысл при высокой ценности сайта |
Стоимость облачного хранения для типового сайта — от 100 до 500 ₽ в месяц за 10-50 ГБ, что закрывает несколько недель истории копий с запасом.
Глубина хранения: сколько копий держать одновременно
Хранить только последнюю копию рискованно: если повреждение данных (например, вирус в файлах или битые записи в базе) произошло несколько дней назад и обнаружилось не сразу, последняя копия окажется такой же испорченной. Рабочая схема — «дед-отец-сын»: 7 ежедневных копий, 4 еженедельных, 3 ежемесячных. Это даёт возможность откатиться на конкретный день за последнюю неделю или на состояние сайта месячной давности, не раздувая объём хранилища бесконечно.
Отдельное правило — бэкап непосредственно перед любым рискованным действием: обновлением CMS, плагинов, темы или переносом на новый хостинг. Такая копия не входит в расписание, её делают вручную и хранят отдельно до подтверждения, что обновление прошло без сбоев.
Как проверять, что бэкап реально восстанавливается
Наличие файла бэкапа не равно работоспособности бэкапа. Проверка должна быть практической, а не визуальной:
- Разверните копию на отдельном тестовом окружении — субдомен, staging-версия хостинга или локальный сервер, не боевой сайт.
- Дождитесь полного восстановления файлов и импорта базы данных, включая соответствие версии PHP и MySQL той, что использовалась при создании копии.
- Откройте сайт и пройдите по ключевым сценариям: главная страница, карточка товара, оформление заказа или отправка формы, вход в админ-панель.
- Сверьте дату последней записи в базе — если восстановленный сайт показывает контент недельной давности вместо вчерашнего, значит расписание бэкапов работает не так, как предполагалось.
Такую проверку стоит проводить не после настройки бэкапов один раз, а регулярно — раз в квартал минимум, потому что обновления CMS и хостинга со временем могут сломать процесс автоматического бэкапирования незаметно для владельца сайта, и об этом узнают только в момент, когда копия действительно нужна.
Инструменты для автоматизации
На WordPress бэкап чаще всего настраивают через плагины — UpdraftPlus и All-in-One WP Migration закрывают базовый сценарий: расписание, выгрузка во внешнее облако, восстановление в один клик. Бесплатных версий обычно достаточно для сайтов с базой до 1-2 ГБ, для больших магазинов есть смысл в платных тарифах с инкрементальным копированием.
На 1С-Битрикс есть встроенный модуль резервного копирования в панели управления, который умеет как полный, так и частичный бэкап с расписанием. Дополнительно многие хостинг-провайдеры предлагают собственные ежедневные снапшоты серверов — это удобная страховка, но её нельзя считать заменой независимого бэкапа: снапшот хостинга исчезает вместе с аккаунтом, если, например, произошла блокировка или окончание оплаты.
Если сайт технически сложный или требует переноса на новый хостинг, настройка бэкапов — часть работ, которые закрывает техническая поддержка сайта: расписание, внешнее хранилище и регулярная проверка восстановления настраиваются один раз и дальше не требуют ручного контроля.
Частые вопросы
Сколько времени занимает восстановление сайта из бэкапа?
Для типового сайта на WordPress с базой до 1 ГБ — от 20 минут до 2 часов, в зависимости от того, разворачивается копия на том же хостинге или переносится на новый сервер. Крупный интернет-магазин с базой в несколько гигабайт и множеством медиафайлов может занять 4-8 часов, особенно при переносе между провайдерами.
Можно ли обойтись бэкапом только базы данных без файлов?
Нет, если сайт использует нестандартную тему, кастомные плагины или загруженные пользователями файлы — без них база восстановит тексты и заказы, но сайт физически не соберётся или потеряет весь визуальный вид и вложения. Бэкап только базы годится разве что как экстренная копия контента между полными архивами.
Как часто нужно делать бэкап, если сайт почти не меняется?
Даже для статичного сайта-визитки нужна копия минимум раз в месяц — риск не в правках контента, а во внешних факторах: взлом, сбой хостинга, повреждение базы из-за атаки ботов. Расписание раз в месяц плюс ручной бэкап перед любым обновлением CMS закрывает большинство сценариев.
Что делать, если бэкап настроен, но никогда не проверялся?
Провести тестовое восстановление в ближайшее время, не дожидаясь аварии. На практике значительная часть бэкапов, которые никогда не разворачивали, оказываются неполными — не хватает прав доступа, части файлов или совместимой версии PHP на момент восстановления.
Нужен ли отдельный бэкап перед обновлением плагинов или CMS?
Да, это отдельное правило, не входящее в обычное расписание. Автоматическое обновление плагина иногда ломает сайт из-за конфликта версий — если это произошло, откат к точке «перед обновлением» занимает минуты, а поиск проблемы без свежего бэкапа может растянуться на часы.
Настроить бэкапы, которые реально работают в момент аварии
Проверим, что уже настроено на сайте, донастроим расписание и внешнее хранилище, проведём тестовое восстановление — чтобы копия сработала, когда она понадобится, а не осталась файлом на диске.