Сайты теряют не только из-за хакеров. Чаще — из-за неудачного обновления плагина, ошибки подрядчика, сбоя диска у хостера или неоплаченного вовремя счёта. Страховка от всех этих сценариев одна: рабочая резервная копия, которая лежит не там, где сам сайт, и которую хоть раз пробовали развернуть. Разбираем резервное копирование сайта глазами владельца: что входит в полный бэкап, как часто его делать, где хранить и что спросить у подрядчика до подписания договора поддержки.
В этой статье 7
Почему «хостинг сам делает бэкапы» — это не защита
На вопрос о резервных копиях владельцы обычно отвечают: «Хостинг что-то делает автоматически». Это опасная иллюзия. Бэкапы хостера — его сервис для его задач: полноту, глубину хранения и скорость восстановления он не гарантирует, а на дешёвых тарифах копии часто делаются раз в неделю. Главное — они лежат в той же инфраструктуре, что и сайт, и привязаны к тому же аккаунту: при сбое дисков, взломе или блокировке за неоплату вы теряете сайт и его «страховку» одновременно. Поэтому бэкапы хостера — полезное дополнение, но не система. Своя система — это копии, которые принадлежат вам, лежат вне хостинга и восстановление которых вы проверяли.
Что входит в полный бэкап сайта
Типичная ошибка — считать бэкапом архив с файлами. Для сайта на CMS этого мало: без базы данных архив файлов — это пустая оболочка. Полный бэкап состоит из трёх слоёв.
- Файлы сайта: код движка или сборки, темы, плагины и — главное — загруженные медиа: фотографии товаров, документы, картинки статей. Именно медиа сложнее всего восстановить из других источников.
- База данных: тексты страниц, товары, заказы, пользователи, настройки CMS. Для WordPress, 1С-Битрикс и любой классической CMS база — это и есть сайт; её дамп обязателен в каждой копии.
- Конфигурация окружения: настройки веб-сервера и редиректов (.htaccess, конфиги nginx), SSL-сертификаты, крон-задачи, ключи интеграций. Этот слой забывают чаще всего — и восстановленный сайт «работает», но с битыми редиректами и неработающими формами.
Правило 3-2-1: как хранить копии
Классическое правило резервного копирования — 3-2-1: три копии данных, на двух разных типах носителей, из них одна — вне основной площадки. Для сайта это переводится просто: первая копия — сам работающий сайт, вторая — автоматический бэкап на хостинге для быстрых откатов, третья — копия во внешнем независимом хранилище: S3-совместимое облако, отдельный сервер, в крайнем случае — регулярная выгрузка на ваш диск.
Ключевой элемент — именно третья, внешняя копия: она защищает от сценариев, когда гибнет вся площадка целиком — авария у хостера, взлом аккаунта, шифровальщик, блокировка. И создаваться она должна автоматически: ручные бэкапы «когда вспомню» перестают делаться через месяц.
Как часто делать бэкап сайта
Частота зависит от одного вопроса: сколько данных вы готовы потерять безвозвратно? Визитка меняется раз в квартал — недельная копия почти ничем не рискует. Магазин принимает заказы каждый час — сутки потерянных данных означают реальные деньги и клиентов. Ориентиры по типам сайтов:
Частота резервного копирования по типу сайта
- Тип сайта: Лендинг, сайт-визитка
- Файлы: Раз в неделю и перед правками
- База данных: Раз в неделю (если есть)
- Глубина хранения: 3–4 копии, месяц
- Тип сайта: Корпоративный сайт, блог
- Файлы: Раз в неделю
- База данных: Ежедневно
- Глубина хранения: 2–4 недели
- Тип сайта: Интернет-магазин
- Файлы: Ежедневно
- База данных: Каждые 1–6 часов
- Глубина хранения: 2–4 недели + месячные срезы
- Тип сайта: Портал, сервис с личными кабинетами
- Файлы: Ежедневно
- База данных: Непрерывно или почасово
- Глубина хранения: По регламенту, от месяца
Текст схемы и все данные
Частота резервного копирования по типу сайта
- Тип сайта: Лендинг, сайт-визитка
- Файлы: Раз в неделю и перед правками
- База данных: Раз в неделю (если есть)
- Глубина хранения: 3–4 копии, месяц
- Тип сайта: Корпоративный сайт, блог
- Файлы: Раз в неделю
- База данных: Ежедневно
- Глубина хранения: 2–4 недели
- Тип сайта: Интернет-магазин
- Файлы: Ежедневно
- База данных: Каждые 1–6 часов
- Глубина хранения: 2–4 недели + месячные срезы
- Тип сайта: Портал, сервис с личными кабинетами
- Файлы: Ежедневно
- База данных: Непрерывно или почасово
- Глубина хранения: По регламенту, от месяца
| Тип сайта | Файлы | База данных | Глубина хранения |
|---|---|---|---|
| Лендинг, сайт-визитка | Раз в неделю и перед правками | Раз в неделю (если есть) | 3–4 копии, месяц |
| Корпоративный сайт, блог | Раз в неделю | Ежедневно | 2–4 недели |
| Интернет-магазин | Ежедневно | Каждые 1–6 часов | 2–4 недели + месячные срезы |
| Портал, сервис с личными кабинетами | Ежедневно | Непрерывно или почасово | По регламенту, от месяца |
Обязательное дополнение к расписанию — внеплановая копия перед любым вмешательством: обновлением CMS и плагинов, работами подрядчика, переездом сайта. Большинство «катастроф» случается сразу после чьих-то действий — и точка отката, сделанная за пять минут до них, превращает аварию в мелкий эпизод.
Бэкап сайта: как сделать на практике
- Включите бэкапы на хостинге: в панели (ISPmanager, cPanel) проверьте, что копируются и файлы, и базы, и посмотрите реальную глубину хранения. Это ваш быстрый локальный откат.
- Настройте внешнюю копию: модуль CMS или скрипт на сервере, который по расписанию собирает архив файлов и дамп базы и отправляет их в независимое хранилище. Важно: оно оплачивается отдельно от хостинга, и доступы к нему другие.
- Зафиксируйте конфигурацию: настройки сервера, крон-задачи, редиректы, ключи интеграций — в тот же архив или отдельный защищённый документ.
- Включите уведомления об ошибках: бэкап, который молча перестал выполняться три месяца назад, хуже отсутствующего — он даёт ложное чувство защищённости.
- Запишите процедуру восстановления: короткий документ «что где лежит и в каком порядке разворачивать». В момент аварии думать будет некогда.
Бэкап сайта: как сделать на практике
- Включите бэкапы на хостинге: в панели (ISPmanager, cPanel) проверьте, что копируются и файлы, и базы, и посмотрите реальную глубину хранения. Это ваш быстрый локальный откат.
- Да
- Настройте внешнюю копию: модуль CMS или скрипт на сервере, который по расписанию собирает архив файлов и дамп базы и отправляет их в независимое хранилище. Важно: оно оплачивается отдельно от хостинга, и доступы к нему другие.
- Да
- Зафиксируйте конфигурацию: настройки сервера, крон-задачи, редиректы, ключи интеграций — в тот же архив или отдельный защищённый документ.
- Да
- Включите уведомления об ошибках: бэкап, который молча перестал выполняться три месяца назад, хуже отсутствующего — он даёт ложное чувство защищённости.
- Да
- Запишите процедуру восстановления: короткий документ «что где лежит и в каком порядке разворачивать». В момент аварии думать будет некогда.
- Да
Текст схемы и все данные
Бэкап сайта: как сделать на практике
- Включите бэкапы на хостинге: в панели (ISPmanager, cPanel) проверьте, что копируются и файлы, и базы, и посмотрите реальную глубину хранения. Это ваш быстрый локальный откат.
- Да
- Настройте внешнюю копию: модуль CMS или скрипт на сервере, который по расписанию собирает архив файлов и дамп базы и отправляет их в независимое хранилище. Важно: оно оплачивается отдельно от хостинга, и доступы к нему другие.
- Да
- Зафиксируйте конфигурацию: настройки сервера, крон-задачи, редиректы, ключи интеграций — в тот же архив или отдельный защищённый документ.
- Да
- Включите уведомления об ошибках: бэкап, который молча перестал выполняться три месяца назад, хуже отсутствующего — он даёт ложное чувство защищённости.
- Да
- Запишите процедуру восстановления: короткий документ «что где лежит и в каком порядке разворачивать». В момент аварии думать будет некогда.
- Да
Отдельно про современные статические сайты: у них задача проще по построению. Исходники и контент лежат в git-репозитории — это версионированная копия с полной историей изменений, а сайт восстанавливается пересборкой на любом хостинге. Мы в АОСА собираем сайты именно так — подробнее в статье про статические сайты для бизнеса. Бэкапить остаётся то, что живёт вне репозитория: базы заявок и настройки сервера.
Как восстановить сайт из бэкапа — и почему это надо репетировать
Непроверенный бэкап — не бэкап, а гипотеза. Архивы бывают битыми, дампы — неполными, а восстановление — невозможным без пароля, который знал один уволившийся администратор. Единственный способ убедиться в работоспособности копий — тестовое восстановление: хотя бы раз в квартал разверните сайт из свежей копии на тестовом поддомене и пройдитесь по ключевым сценариям.
- Разверните файлы и базу из копии на тестовой площадке, подключите конфигурацию.
- Проверьте главную, карточки товаров или страницы услуг, поиск по сайту, админку.
- Отправьте тестовую заявку через форму и убедитесь, что она дошла.
- Сверьте редиректы и SSL — то, что живёт в «третьем слое» бэкапа и теряется чаще всего.
- Засеките время: сколько заняло восстановление от «достали архив» до «сайт работает». Это ваш реальный срок простоя при аварии.
Как восстановить сайт из бэкапа — и почему это надо репетировать
- Разверните файлы и базу из копии на тестовой площадке, подключите конфигурацию.
- Да
- Проверьте главную, карточки товаров или страницы услуг, поиск по сайту, админку.
- Да
- Отправьте тестовую заявку через форму и убедитесь, что она дошла.
- Да
- Сверьте редиректы и SSL — то, что живёт в «третьем слое» бэкапа и теряется чаще всего.
- Да
- Засеките время: сколько заняло восстановление от «достали архив» до «сайт работает». Это ваш реальный срок простоя при аварии.
- Да
Текст схемы и все данные
Как восстановить сайт из бэкапа — и почему это надо репетировать
- Разверните файлы и базу из копии на тестовой площадке, подключите конфигурацию.
- Да
- Проверьте главную, карточки товаров или страницы услуг, поиск по сайту, админку.
- Да
- Отправьте тестовую заявку через форму и убедитесь, что она дошла.
- Да
- Сверьте редиректы и SSL — то, что живёт в «третьем слое» бэкапа и теряется чаще всего.
- Да
- Засеките время: сколько заняло восстановление от «достали архив» до «сайт работает». Это ваш реальный срок простоя при аварии.
- Да
Расчёт условный, для иллюстрации. Магазин с оборотом 900 000 ₽ в месяц теряет за сутки простоя около 30 000 ₽ выручки — плюс рекламный бюджет, уходящий на неоткрывающиеся страницы. Если восстановление из непроверенного бэкапа растягивается на три дня переписки с хостером, потери превышают годовую стоимость нормально настроенного копирования.
Собирательный пример на основе типовых проектов — не реальный клиент.
Что спросить у подрядчика о бэкапах до подписания договора
Если сайт обслуживает студия или частный специалист, резервное копирование надо зафиксировать письменно, а не подразумевать. Вопросы, которые стоит задать до подписания договора поддержки:
- Что именно копируется: файлы, база, конфигурация — или только часть? Попросите перечислить состав копии.
- Куда: остаются ли копии на том же хостинге или уходят во внешнее хранилище? Кто владеет этим хранилищем и оплачивает его?
- Как часто и сколько хранится: расписание и глубина хранения по типам данных.
- Кто и как проверяет восстановимость: делаются ли тестовые развёртывания и как часто?
- Каков целевой срок восстановления: за сколько часов сайт вернётся в строй после аварии?
- Что получает владелец: есть ли у вас собственный доступ к копиям и доступам, или всё замкнуто на подрядчика?
Внятные ответы на эти шесть вопросов — хороший маркер зрелости подрядчика в целом. В поддержке сайтов АОСА (от 15 000 ₽ в месяц) резервное копирование с внешним хранением и проверкой восстановимости входит в регламент по умолчанию — вместе с мониторингом, обновлениями и развитием сайта.
Я ни разу не видел, чтобы бизнес пострадал от «слишком частых» бэкапов, — и регулярно вижу обратное: сайт годами живёт без единой проверенной копии, пока не случается серьёзное обновление или смена подрядчика. Практический минимум для коммерческого сайта: ежедневная копия базы, еженедельная — файлов, внешнее хранилище с отдельными доступами и тестовое восстановление раз в квартал с секундомером. Это несколько часов настройки один раз — против недель восстановления сайта по кэшам поисковиков, если копий не оказалось.
Владимир БогдановОснователь и руководитель AOSA · эксперт по SEO и AEO, 12+ лет в поисковой оптимизации