Бэкапы Битрикс — это не техническая формальность, а страховка бизнеса. Большинство интернет-магазинов делают резервное копирование неправильно: не то копируют, хранят не там и никогда не проверяют, работают ли копии вообще. Это руководство по бэкапам сайта на Битрикс — что настроить, где хранить и как убедиться, что из копии реально можно восстановить магазин.
Звонят нам в пятницу вечером. Интернет-магазин на Битрикс, торгует строительными материалами. Голос у владельца — как у человека, который только что узнал плохую новость. «Сайт не открывается. Три дня уже. Хостинг говорит, что диск умер».
Бэкапы у него были. Каждый день, автоматически. Но хранились они на том же сервере, что и сайт. Диск умер — бэкапы тоже умерли. Вместе с базой заказов за последние три дня. 47 необработанных заказов на 380 000 рублей ушли в никуда.
Это не исключение. Это типичная история.
Зачем нужны бэкапы, если «у нас всё ок»
Большинство владельцев магазинов думают о бэкапах примерно так: «Хостинг делает копии, я видел это в панели управления». Проблема в том, что хостинговые бэкапы — это не ваши бэкапы. Это бэкапы хостинга. Хранятся они по его правилам, удаляются по его расписанию и восстанавливаются за его деньги.
Вот три сценария, при которых бэкапы нужны прямо сейчас, даже если сайт работает нормально:
- Взлом и заражение вирусом. Злоумышленник внедряет вредоносный код. Поисковики замечают это через 3–7 дней и выбрасывают сайт из выдачи. Если бэкапа нет — приходится чистить вручную, и никто не гарантирует полный результат.
- Ошибочное удаление данных. Менеджер случайно удаляет категорию товаров. Разработчик накатывает обновление, которое ломает половину функционала. Без свежего бэкапа откатиться невозможно.
- Аппаратный сбой. Именно то, что случилось с клиентом из истории выше. Диски ломаются. Серверы падают. Это вопрос не «если», а «когда».
Среднее время восстановления магазина без бэкапа — от 3 до 14 дней. За это время вы теряете не только прямую выручку, но и позиции в поиске: Яндекс пессимизирует сайты с длительным даунтаймом.
Что конкретно копировать: файлы и база данных
Битрикс — это не один файл, который можно просто скопировать. Полноценный бэкап состоит из двух независимых частей, и если вы копируете только одну из них — считайте, что бэкапа нет.
Файлы сайта
Это всё, что лежит на сервере в папке с вашим сайтом: PHP-код Битрикс, шаблоны, изображения товаров, документы, загруженные пользователями, конфигурационные файлы. Объём — от нескольких гигабайт до десятков, в зависимости от размера каталога.
Если вы потеряете только файлы — базу данных удастся восстановить. Но вы лишитесь всех изображений, кастомных шаблонов и настроек, которые делались вручную.
База данных MySQL
Здесь хранится всё, что меняется каждый день: заказы, клиенты, остатки товаров, цены, сессии, логи. База данных — самая ценная часть магазина. Без неё файлы бесполезны: сайт запустится, но будет пустым.
Размер базы на среднем магазине — от 200 МБ до 3–5 ГБ. Она растёт каждый день.
Что ещё стоит включить
- Конфигурационные файлы сервера (nginx.conf, php.ini) — если их нет, восстановленный сайт может не запуститься
- Файл .htaccess — в нём часто прописаны редиректы и правила безопасности
- SSL-сертификаты — если используете не Let's Encrypt, а платный сертификат
Хорошее правило: полный бэкап = файлы + база данных + конфиги сервера. Всё три части, всегда.
Встроенные инструменты Битрикс: что умеют и где подводят
В Битриксе есть встроенный модуль резервного копирования. Путь в админке: Настройки → Инструменты → Резервное копирование. Он умеет делать бэкапы по расписанию, выбирать, что включать в архив, и сохранять копии в разные места.
Для небольших магазинов до 5 ГБ это рабочий вариант. Но у него есть несколько ограничений, о которых стоит знать заранее.
Проблема первая: время выполнения. Встроенный инструмент работает через браузер. Если PHP-скрипт не успевает завершить бэкап за отведённое время (обычно 30–60 секунд на хостинге), он падает с ошибкой. На больших магазинах это происходит регулярно.
Проблема вторая: место хранения. По умолчанию бэкапы сохраняются в папку на том же сервере, где стоит сайт. Это бессмысленно: если сервер выходит из строя, бэкапы уходят вместе с ним. Именно так произошло в истории выше.
Проблема третья: нагрузка на сервер. Во время создания бэкапа сервер работает интенсивнее обычного. Если запустить его в пиковое время — сайт будет тормозить. Планируйте бэкапы на ночь, когда трафик минимален.
Вывод: встроенный модуль подходит для старта, но требует правильной настройки хранилища. Для серьёзной защиты лучше использовать серверные инструменты (о них ниже).
Где хранить бэкапы: три варианта
Место хранения — самый важный вопрос в резервном копировании. Не расписание, не формат, не инструмент. Именно место. Если бэкап хранится там же, где сайт, — его нет.
Вариант 1: облачное хранилище
Яндекс Диск, S3-совместимые хранилища (Яндекс Object Storage, VK Cloud, Selectel), Google Drive. Подходит для большинства магазинов. Плюсы: доступно из любого места, не зависит от состояния сервера. Минус: нужно настраивать выгрузку и платить за объём.
Битрикс умеет выгружать бэкапы на Яндекс Диск через стандартный модуль. Для S3 потребуется дополнительная настройка или сторонние модули.
Вариант 2: отдельный сервер (резервный)
Самый надёжный вариант. Бэкапы складываются на отдельный сервер в другом дата-центре. Если основной сервер сгорит вместе с дата-центром — резервный сервер в другом городе останется нетронутым. Именно этот подход используем мы в абонентском обслуживании.
Стоимость простого резервного сервера — от 500 до 1 500 рублей в месяц. Это цена страховки от потери всего бизнеса.
Вариант 3: комбинированный (правило 3-2-1)
Золотой стандарт: три копии данных, на двух разных носителях, одна из которых хранится удалённо. Применительно к Битриксу это выглядит так: ежедневные бэкапы на облако + еженедельный бэкап на отдельный сервер + ежемесячный архив на внешний диск или холодное хранилище.
Для интернет-магазина с оборотом от 1 млн рублей в месяц это не опция, а минимальная необходимость.
Как проверить, что бэкап рабочий
Самая распространённая ошибка: настроить бэкапы и забыть о них. Через полгода выясняется, что они не создавались три месяца — скрипт упал с ошибкой, а никто не следил.
Второй вариант: бэкапы создавались, но архив повреждён. Это обнаруживается только при попытке восстановиться — в самый неподходящий момент.
Что нужно делать:
- Раз в неделю — проверять, что бэкап создался и файл не нулевого размера. Это занимает 2 минуты.
- Раз в месяц — делать тестовое восстановление на отдельном сервере или в тестовой среде. Разворачивать сайт из бэкапа, проверять, что он открывается, заказы на месте, каталог работает.
- После каждого крупного обновления Битрикс — делать внеплановый бэкап вручную, до обновления. Если обновление сломает что-то нестандартное — есть точка отката.
У нас был клиент, который три года думал, что у него работают бэкапы. Когда понадобилось восстановить магазин после взлома, выяснилось: скрипт бэкапа падал из-за нехватки места на сервере, и последняя рабочая копия датировалась 11 месяцами ранее. Потери оказались колоссальными.
Проверка бэкапов — это не паранойя. Это обязательная часть обслуживания сайта.
Что сделать прямо сейчас: три шага
Не откладывайте это на потом. Вот три конкретных шага, которые можно сделать сегодня.
Шаг 1. Проверьте, есть ли бэкапы вообще.
Зайдите в Битрикс: Настройки → Инструменты → Резервное копирование. Посмотрите дату
последнего бэкапа и где он хранится. Если последний бэкап старше 7 дней или хранится в папке на том же сервере — у
вас нет рабочей защиты.
Шаг 2. Настройте расписание и внешнее хранилище.
Там же, в модуле резервного копирования, задайте расписание: минимум раз в сутки, в ночное время. Добавьте внешнее
хранилище: Яндекс Диск подключается за 10 минут через стандартный интерфейс Битрикс. Это бесплатно до 10 ГБ.
Шаг 3. Сделайте первый бэкап вручную и скачайте архив.
Запустите бэкап прямо сейчас через кнопку «Создать резервную копию». Дождитесь завершения. Скачайте архив локально.
Проверьте его размер: он должен соответствовать реальному объёму сайта. Нулевой или подозрительно маленький архив —
сигнал, что что-то пошло не так.
Это минимум, который закроет 80% рисков. Для полноценной защиты нужно больше: мониторинг успешности бэкапов, внешнее хранилище, тестовые восстановления, серверные инструменты вместо браузерных. Это уже выходит за пределы того, что можно настроить самостоятельно за вечер.
Если хотите убедиться, что бэкапы у вас настроены правильно — мы проверим это бесплатно. Технический аудит сервера занимает 24 часа: смотрим расписание бэкапов, место хранения, последнюю успешную копию и настройки сервера. Заявка на support.orangecode.ru — ответим в течение рабочего дня.