Резервное копирование сайта на Битрикс: живой пример

У интернет-магазина на 1С-Битрикс резервная копия должна возвращать не только файлы сайта, но и базу данных, загруженные изображения, настройки подключения и ключи интеграций. На живом примере магазина с каталогом, заказами и обменом с 1С разберём три подхода к бэкапу, их цену и проверку восстановления. Схема рассчитана на 1С-Битрикс: Управление сайтом 24.x–25.x; названия пунктов меню могут отличаться в зависимости от редакции и обновлений.

Исходные данные: магазин, который нельзя восстановить «примерно»

Представим интернет-магазин на виртуальном сервере. В нём около 18 ГБ файлов, 2,5 ГБ базы данных, каталог товаров, личные кабинеты, заказы, платежный модуль и обмен с учётной системой. Сайт работает в стандартной структуре Битрикс: ядро находится в /bitrix, пользовательские загрузки — в /upload, а код проекта и настройки размещены в корне сайта.

Копировать только каталог сайта недостаточно. В нём останутся шаблоны, модули и изображения, но не будет заказов, пользователей, настроек инфоблоков и статусов оплат. Копия только базы тоже бесполезна: после восстановления вы получите данные без файлов, изображений и части настроек окружения.

Резервная копия считается рабочей не тогда, когда архив появился на диске, а когда из него удалось поднять сайт в отдельном окружении.

Сноска. Снимок сервера — это сохранённое состояние виртуальной машины или диска на уровне хостинга. В отличие от архива Битрикс, он обычно содержит всю файловую систему и настройки сервера, а не только данные сайта.

Три подхода и их реальная цена

Для Битрикс обычно используют встроенный механизм резервного копирования, отдельный экспорт базы с копированием файлов или снимки сервера. Они решают разные задачи, поэтому выбирать один вариант «на все случаи» рискованно.

Практичная схема для магазина — сочетать варианты. Перед обновлением Битрикс или модуля достаточно сделать встроенную копию и снимок сервера. Для постоянной защиты нужна отдельная копия базы и файлов за пределами основного сервера. Точные ограничения по размеру, сроку хранения и стоимости снимков зависят от хостинга.

Разбор на примере: копия перед обновлением

1. Проверяем, что именно будем сохранять

Перед запуском откройте административную панель и проверьте свободное место на диске. Архив может потребовать больше места, чем ожидается: на сервере одновременно лежат исходные файлы, временный архив и уже созданные копии.

• Посмотрите размер каталога сайта, особенно /upload.
• Уточните размер базы данных в панели хостинга или СУБД.
• Проверьте, что в копию входят база, ядро, модули, шаблоны, пользовательские файлы и конфигурация.
• Запишите версии PHP, MySQL или MariaDB и самого продукта Битрикс.
• Сохраните отдельно список внешних зависимостей: сертификаты, задания cron, настройки веб-сервера и данные интеграций.

Конкретное содержимое архива зависит от выбранных параметров встроенного инструмента. Не полагайтесь на название копии: откройте настройки задания и проверьте состав данных вручную.

2. Создаём встроенную копию в Битрикс

В административной панели откройте раздел резервного копирования. В разных версиях и редакциях путь может называться «Настройки», «Проактивная защита» или «Резервное копирование». Если пункт не найден, используйте поиск по меню панели или документацию своей версии.

Создайте новую копию и включите базу данных и файлы сайта. Для первого полного бэкапа не исключайте /upload: именно там часто находятся фотографии товаров, документы и пользовательские вложения. Кэш можно не хранить, если инструмент позволяет исключить его, но после восстановления сайт должен уметь создать кэш заново.

Перед стартом остановите публикацию изменений в админке и предупредите коллег. Если в этот момент оформляют заказ или меняют карточку товара, состояние базы и файлов может оказаться снятым в разные моменты.

Проверка: в списке резервных копий появляется завершённая запись с датой, размером и статусом без ошибки. Файл копии физически существует, а не только отображается в интерфейсе.

3. Уносим архив с рабочего сервера

Копия в той же файловой системе защищает от неудачного обновления, но не от поломки диска, удаления аккаунта или компрометации сервера. После создания скачайте архив на отдельное хранилище с ограниченным доступом. Для магазина разумно иметь как минимум две независимые точки хранения: рабочий сервер и внешний носитель или отдельное облачное хранилище.

Не оставляйте резервные архивы доступными из публичного каталога сайта. В архиве могут быть пароли подключения к базе, ключи интеграций и персональные данные. Доступ к папке с копиями должен быть закрыт через настройки веб-сервера и права файловой системы.

Проверка: архив открывается на отдельной машине или в тестовом хранилище, его размер совпадает с ожидаемым, а дата создания соответствует окну перед обновлением.

4. Проверяем восстановление, а не только скачивание

Для проверки создайте отдельный тестовый сайт. Это может быть временный виртуальный сервер или копия окружения на хостинге. Не восстанавливайте архив поверх рабочего магазина: ошибка на этом шаге способна удалить актуальные заказы.

1. Подготовьте окружение с совместимыми версиями PHP, базы данных и веб-сервера.
2. Восстановите файлы и базу из архива по инструкции для вашей версии Битрикс.
3. Проверьте подключение к базе и права на каталоги, в которые сайт пишет кэш и загруженные файлы.
4. Отключите отправку писем, платёжные уведомления и обмен с внешними системами на тестовом домене.
5. Откройте главную страницу, каталог, карточку товара, корзину и административную панель.
6. Проверьте несколько старых заказов, изображения из /upload, поиск и фоновые задания.

Проверка: тестовый сайт открывается без ошибок, изображения загружаются, заказ виден в панели, а в журнале веб-сервера и Битрикс нет новых критических сообщений.

Что ломается в типичных бэкапах

Архив создался, но места на диске не хватило

При упаковке временные файлы и итоговый архив могут существовать одновременно. Если свободное место заканчивается, копия останется неполной или процесс завершится ошибкой. Перед запуском удалите устаревшие локальные копии, но сначала убедитесь, что они уже перенесены во внешнее хранилище.

Восстановили сайт, но пропали изображения

Чаще всего в архив не попал /upload или его скопировали не полностью. Проверьте состав копии до восстановления, а после него сравните несколько файлов из старых товаров и документов.

Админка открывается, а сайт выдаёт ошибку подключения к базе

Проверьте параметры подключения в конфигурации и права пользователя базы. На новом сервере имя базы, пользователь, хост и пароль могут отличаться. Не переносите рабочие секреты в публичные инструкции и не храните их в открытых тикетах.

После восстановления начали уходить письма и обмены

Тестовая копия может сохранить задания cron, SMTP-настройки, вебхуки и параметры интеграций. Перед запуском теста отключите внешние отправки. Иначе восстановленный магазин способен отправить клиентам повторные письма или создать дубли заказов в учётной системе.

Когда какой способ выбирать

Встроенный бэкап Битрикс подходит для контрольной точки перед обновлением ядра, модуля или шаблона. Он удобен, когда нужно быстро вернуть сайт в состояние час назад, но не решает задачу хранения копии вне сервера.

Раздельная копия базы и файлов лучше подходит для регулярного расписания и переноса сайта между окружениями. Такой вариант требует дисциплины: база, /upload, код проекта, конфигурация, cron и настройки веб-сервера должны попадать в план восстановления.

Снимок сервера выбирайте, если нужно быстро откатить всю виртуальную машину после неудачного обновления. Не используйте его как единственную защиту магазина: снимок может быть удалён вместе с сервером, а откат возвращает старое состояние всей машины, включая другие приложения.

Что делать дальше

Составьте короткий регламент: что копируется, куда уходит архив, сколько копий хранится, кто запускает восстановление и как часто проходит тест. Для интернет-магазина отдельно контролируйте свежесть базы: копия недельной давности может сохранить сайт, но не вернуть последние заказы.

Следующим шагом настройте автоматическое создание копий и уведомление об ошибке, затем проведите восстановление на тестовом домене. Измеряйте не только размер архива, но и время создания, время восстановления и возраст самой свежей успешной копии. Инвалидация старых резервных копий и настройка политики хранения — отдельная тема; здесь важнее сначала доказать, что одна копия действительно поднимает сайт.