Бэкап Битрикса: как настроить резервное копирование сайта и базы и восстановить проект

Бэкап Битрикса: что именно нужно сохранять и где это лежит

К нам чаще всего приходят с одной из трёх ситуаций: сайт упал после обновления, клиент переезжает на новый хостинг, или релиз новой версии шаблона сломал прод и нужно откатиться. Во всех трёх случаях вопрос звучит одинаково — «а бэкап у вас есть?». И вот тут выясняется, что у половины проектов «бэкап» — это либо только дамп MySQL, снятый полгода назад, либо только архив файлов без базы. Ни то, ни другое не разворачивается в рабочий сайт.

У нас на проектах бэкап Битрикса — это не один файл, а набор из нескольких независимых частей. Ядро ( /bitrix/ ) и публичная часть содержат код, шаблоны, компоненты. База MySQL хранит контент, настройки, пользователей, свойства инфоблоков. Конфиг /bitrix/php_interface/dbconn.php держит доступы к БД и параметры соединения. Плюс .htaccess с правилами ЧПУ и редиректами — без него сайт откроется, но все URL поедут.

Ограничиться только дампом MySQL нельзя по простой причине: кастомный код в /local/ и /bitrix/php_interface/ в базе не лежит. Восстановите БД на чистой установке — получите данные без логики, которая их обрабатывает. Симметрично, архив файлов без базы даст вам «мёртвый» сайт: шаблоны на месте, а товаров и настроек нет. Обе части нужно снимать синхронно, иначе получите рассинхрон версий.

Что обязательно входит в бэкап:

• Файлы сайта: /bitrix/, /local/, /upload/, .htaccess в корне
• Дамп базы MySQL — целиком, со всеми таблицами и триггерами
• Конфиг /bitrix/php_interface/dbconn.php — отдельно, потому что в нём пароли
• Кастомные модули в /local/modules/ — они не восстанавливаются из обновлений ядра
• Настройки cron и агентов: файл crontab и записи в таблице b_agent

Резервное копирование Битрикс: локально, в облако 1С-Битрикс или в сторонний S3

По официальной документации у резервных копий Битрикса есть три места хранения: локально на сервере, в облаке «1С-Битрикс» и в сторонних облачных хранилищах. Выбор между ними — не «вкусовщина», а три компромисса между стоимостью, скоростью восстановления и доступностью архива в момент, когда сервер уже лёг.

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

Облако «1С-Битрикс» встроено в платформу: настроил раз, дальше копии уезжают по расписанию без внешних скриптов. Минусы — платная подписка и обязательное шифрование. Сторонний S3 (CLO, Timeweb и подобные) — золотая середина: файлы лежат вне сервера, тарифы обычно ниже, но бакет нужно создать самому и прописать в параметрах размещения. На практике мы комбинируем: свежий локальный бэкап за последние сутки плюс недельный в S3. Так есть и быстрое откатывание, и защита от потери сервера.

Настройка одинаковая для всех трёх вариантов. Разница только на шаге выбора хранилища.

1. Открыть Настройки > Инструменты > Резервное копирование > Список резервных копий и убедиться, что модуль main активен — без него раздел не откроется.
2. Перейти в настройки размещения копий и выбрать хранилище: локальное, облако «1С-Битрикс» или сторонний S3.
3. Для стороннего S3 создать бакет (CLO, Timeweb и т.п.) и указать его реквизиты в параметрах размещения резервной копии.
4. Проверить доступность: Настройки > Облако 1С-Битрикс > Резервные копии — там виден список копий, уже загруженных в облако.

Автоматический бэкап Битрикс: cron, BitrixVM и расписание агентов

Распространённая ошибка: сайт полгода живёт на ручных бэкапах «когда вспомним». Пока всё работает — кажется, что этого достаточно. В момент аварии выясняется, что последняя копия сделана месяц назад, а между ней и текущим состоянием — сотни заказов, новые разделы каталога и правки контент-менеджеров. Ручное копирование раз в месяц не защищает, а создаёт иллюзию защиты.

Перевести копирование на расписание в Битриксе можно двумя путями: через агенты модуля main (работает на любом хостинге, где есть cron) и через настройки BitrixVM/BitrixEnv (для виртуальных машин от 1С-Битрикс, где всё уже собрано в меню). Оба варианта опираются на один и тот же механизм — агенты, которые запускаются по расписанию, а само расписание копирования задаётся отдельно в настройках модуля. Разберём оба.

# crontab -u bitrix -e
# Запуск агентов Битрикса каждую минуту от пользователя сайта
* * * * * /usr/bin/php -f /home/bitrix/www/bitrix/modules/main/tools/cron_events.php >> /home/bitrix/www/bitrix/modules/main/tools/cron_events.log 2>&1

Ключевой момент, который часто упускают: cron_events.php сам бэкап не делает. Скрипт лишь проверяет расписание агентов и запускает те задачи, время которых уже наступило. Именно поэтому его ставят на каждую минуту — чтобы момент срабатывания агента не «плыл» на десятки минут. Само расписание копирования задаётся отдельно — в настройках модуля main (Настройки → Инструменты → Резервное копирование), где указывается периодичность, время запуска и место хранения: локально, в облаке «1С-Битрикс» или в стороннем S3.

Если проект крутится на BitrixVM, отдельный crontab не нужен — там всё уже настроено. Расписание копирования меняется через меню:

1. В консоли BitrixVM выбрать пункт 6. Configure pool sites.
2. Затем 6. Change backup settings on site.
3. Указать периодичность копирования и место хранения (локально или в облако).

Бэкап базы Битрикс: дамп MySQL отдельно от файлов

Самый частый запрос на эту тему — «нужно быстро снять базу, файлы не трогаем». Сценариев три: перед миграцией на новый сервер (файлы перельём отдельно, а базу удобнее тащить дампом), перед массовой правкой каталога (загружаем новый прайс, меняем цены, переиндексируем — и хотим откатиться только по данным, не трогая код), и при выгрузке на dev-стенд (там нужна свежая копия контента, а ядро и upload уже свои).

Дамп делают отдельно от файлов потому, что база и файловая часть меняются с разной скоростью и живут по разным правилам. Штатный бэкап Битрикса упаковывает всё вместе — ядро, публичку, upload и дамп БД — в один архив. Это правильно для катастрофы, но избыточно, когда нужно откатить только данные: разворачивать 20 ГБ upload ради отката таблиц b_catalog_price никто не хочет.

Поэтому в проектах с активным импортом мы держим оба контура: полный архив по расписанию (об этом — в разделе про автоматизацию выше) и отдельный дамп базы по требованию.

mysqldump \
--single-transaction \
--routines \
--triggers \
--default-character-set=utf8mb4 \
--set-gtid-purged=OFF \
-h localhost -u bitrix_user -p \
bitrix_db > /backup/bitrix_db_$(date +%F_%H-%M).sql

Разбираем флаги по порядку, потому что каждый закрывает свою граблю. --single-transaction — ключевой: для InnoDB-таблиц (а Битрикс в актуальных версиях работает именно на них) он открывает транзакцию с уровнем REPEATABLE READ и снимает консистентный снимок без LOCK TABLES. Сайт продолжает принимать заказы и писать в корзину — дамп просто видит базу на момент старта транзакции. --routines сохраняет хранимые процедуры и функции: если у вас есть кастомные обработчики, без этого флага они в дамп не попадут и после восстановления «отвалятся» молча. --triggers — по той же причине для триггеров. --default-character-set=utf8mb4 обязателен: без него кириллица в дампе уедет в кракозябры, и вы узнаете об этом только после восстановления, когда уже поздно.

Восстановление — обратной командой, тоже без сюрпризов:

mysql -h localhost -u bitrix_user -p \
--default-character-set=utf8mb4 \
bitrix_db < /backup/bitrix_db_2025-01-15_03-00.sql

Если база не пустая и вы восстанавливаете поверх — сначала убедитесь, что в дампе есть DROP TABLE IF EXISTS (mysqldump добавляет его по умолчанию), иначе получите ошибки на существующих таблицах. Для переноса на dev-стенд удобнее залить дамп в чистую базу и один раз прогнать /bitrix/modules/main/tools/restore_db.php — но это уже сценарий полного восстановления, о нём ниже.

Восстановление Битрикс из бэкапа: меню админки или restore.php

В источниках про восстановление царит путаница: одни статьи настаивают на меню действий в списке копий, другие — на обязательном restore.php с ручной загрузкой архива. Противоречия тут нет. Это два разных сценария, и выбираются они по одной развилке: восстанавливаете вы на том же сервере или переезжаете на другой. Когда сайт лежит после неудачного обновления и хостинг тот же, хватит админки. Когда переезжаете на новую площадку, поднимаете копию для тестирования или старый сервер уже недоступен — без скрипта не обойтись.

В нашей практике оба варианта встречаются примерно поровну. Разница принципиальная: админка восстанавливает поверх уже установленной системы и работает только пока живы файлы и БД. restore.php — это самораспаковывающийся установщик, который поднимает систему с нуля на чистом хостинге. По официальной документации, если архив содержит полную копию (ядро и публичную часть), предварительная установка «1С-Битрикс» на новом сервере не требуется. Именно поэтому при переносе скрипт незаменим, а при локальном откате избыточен.

Восстановление на том же сервере через меню админки

Этот путь — для ситуации «сайт сломался, но сервер и хостинг те же». Заходим в Настройки → Инструменты → Резервное копирование → Список резервных копий. Если копии лежали в облаке, список смотрим в разделе Настройки → Облако 1С-Битрикс → Резервные копии — это два разных места, и копии из одного не видны в другом.

Дальше в строке нужного архива открываем меню действий и выбираем восстановление. Система распакует файлы поверх текущих и предложит подключить базу. Здесь важно понимать: операция затирает текущее состояние. Восстановите файлы, но оставьте «свежую» базу — получите рассинхрон версий ядра и данных. Для полного отката восстанавливайте и файлы, и дамп из одной и той же копии.

Способ хорош скоростью: ничего не нужно скачивать и заливать, всё происходит на сервере. Минус — он бесполезен, если файлы повреждены или сервер недоступен.

Перенос на новый хостинг через restore.php

Когда цель — поднять сайт на другой площадке, меню админки не поможет: старой системы на новом сервере просто нет. Здесь работает связка «скачать архив + скачать restore.php + залить оба на новый хостинг». Решение из обсуждения: скачать бэкап и restore.php из того же списка копий, залить на новый хостинг, открыть скрипт в браузере и пройти мастер.

Дальше пошагово.

1. Скачать архив и файл restore.php из списка резервных копий — оба лежат рядом в админке.
2. Залить архив и restore.php в корень нового сайта по FTP или SSH. Если архив многочастный — все части в одну папку.
3. Открыть restore.php в браузере и выбрать «Архив загружен в корневую папку сервера».
4. Пройти мастер «далее — далее — далее», указав параметры подключения к новой базе данных.

Почему бэкап не восстанавливается: FileZilla, пути и «файлы открываются только через Битрикс»

На ru.stackoverflow разбирали характерный случай: разработчику нужно было перенести сайт на другой сервер, чтобы сделать тестовую копию. Он подключился к продакшену по FileZilla, выкачал дерево файлов, залил на локальный хост — и сайт не поднялся. Пути сбились, а часть файлов, скачанных из админки через опцию резервного копирования, открывалась только через Битрикс. Симптомов много, причина одна.

Задача всплывает регулярно — при переезде на новый хостинг, при попытке развернуть стенд для доработок, при аварийном восстановлении «на глазок». И почти всегда ломается не на этапе копирования, а на этапе процедуры: файлы перенесли, а систему не восстановили. Ниже разберём, что именно пошло не так и как переносить правильно.

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

Отдельно ломается конфиг. В bitrix/php_interface/dbconn.php прописаны параметры подключения к MySQL — на локальном хосте они другие. А в bitrix/.settings.php зашиты пути и настройки, указывающие на старый домен. Даже если файлы на месте и БД каким-то чудом поднялась, система продолжает искать себя по прежнему адресу.

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

Правильная процедура переноса выглядит так:

1. Скачать архив резервной копии и файл restore.php из админки Битрикса.
2. Залить оба файла в корень локального хоста (или нового сервера).
3. Открыть restore.php в браузере по адресу нового сайта.
4. Выбрать пункт «Архив загружен в корневую папку сервера».
5. Пройти мастер восстановления до конца — «далее — далее — далее».

Если архив разбит на несколько фрагментов, их все нужно скачать и положить в одну папку рядом с restore.php — иначе мастер не соберёт копию.

Что ломает бэкап Битрикса: лимит 2 ГБ, права и cron

Сколько раз вы видели, как бэкап «вроде бы есть», а при аварии выясняется, что он битый? У нас в практике это происходит по четырём причинам, которые повторяются из проекта в проект: архив обрывается на 2 ГБ, после распаковки сайт не открывается из-за прав, cron не крутится, а в облаке не отключается шифрование. Разберём каждую граблю — с причиной и способом обойти.

Лимит 2 ГБ — это не настройка Битрикса, а системное ограничение PHP: одна часть архива физически не может быть больше. Поэтому на больших каталогах штатный бэкап режет копию на фрагменты. И именно здесь ломается восстановление. Если скачать не все части и не положить их в одну папку рядом с restore.php, скрипт просто не соберёт архив. Проверьте, что все фрагменты на месте, прежде чем запускать восстановление.

Права после распаковки — вторая классика. Архив разворачивается от пользователя, отличного от владельца сайта, и файлы получают 644 вместо 755. Сайт открывается частично или не открывается вовсе, а загрузка файлов в /upload падает с ошибкой доступа. После восстановления мы всегда проверяем владельца каталогов и права на /upload и /bitrix. Это рутина, которую забывают.

С cron история проще: скрипт /bitrix/modules/main/tools/cron_events.php должен запускаться каждую минуту. Если задача не добавлена в расписание хостинга, агенты не отрабатывают, расписание бэкапов молчит, а в админке всё выглядит настроенным. Проверяется одной командой в консоли — и лучше сделать это до аварии, а не после.

Чек-лист: настроили бэкап Битрикса — проверьте эти пункты

Этот список мы прогоняем на каждом проекте после того, как настроили резервное копирование. Не потому что не доверяем себе, а потому что цена пропущенного пункта слишком высока. Бэкап, который «вроде делается», и бэкап, который действительно восстанавливается, — это две разные вещи. Разница выясняется ровно в тот момент, когда сайт уже лежит, клиент звонит, а у вас нет времени разбираться, почему архив битый или почему в нём не хватает половины файлов.

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

Семь пунктов. Каждый закрывает конкретную дыру, о которой мы уже писали выше.

• cron_events.php прописан в crontab и запускается каждую минуту — без этого агенты копирования просто не сработают по расписанию.
• Расписание копирования задано явно: час, периодичность, тип (полный или инкрементальный) — а не оставлено на дефолт.
• Место хранения доступно и проверено: локальный диск не переполнен, бакет S3 отвечает, облако «1С-Битрикс» активно по лицензии.
• Тестовое восстановление на dev-стенде прошло — вы лично открывали restore.php и дошли до рабочего сайта.
• Архив не бьётся на части по 2 ГБ без причины — если фрагментация есть, понимаете, что это лимит PHP, а не сбой.
• Права на /upload после распаковки корректны — иначе сайт откроется, но картинки и файлы не отдаст.
• Пароль от БД и ключи S3 не лежат в git — проверьте .gitignore и историю коммитов, а не только текущее состояние.

Читайте также: Невосстановимая ошибка СУБД 1С: причины и решение, Обмен с сайтом 1С Битрикс: пошаговая настройка узла и импорта.

Подробнее об услуге: поддержка и сопровождение сайтов на Битрикс.