Резервная копия сайта Битрикс - единственное, что реально спасает после кривого обновления модуля, случайного DROP TABLE в phpMyAdmin или дыры в устаревшем компоненте. У меня было минимум три случая, когда штатный бэкап из админки лежал недельной давности, а клиент терял заказы за последние дни - потому что резервное копирование настроили один раз при запуске сайта и забыли проверять. Разберу, что умеет модуль «Резервное копирование» из коробки, где он упирается в лимиты хостинга на живом проекте и как я собираю свою схему на cron и mysqldump для магазинов покрупнее.
Штатный модуль резервного копирования в Битриксе
В админке модуль лежит по пути Настройки → Инструменты → Резервное копирование. Там три режима: полная копия (файлы плюс база), только файлы, только база данных. Можно исключить из архива папки upload или bitrix/cache - на магазине с большим каталогом это экономит гигабайты и время, потому что кэш всё равно пересоберётся после восстановления.
Архив Битрикс режет на части - файлы с расширением .tar.00N, если размер превышает лимит, заданный в настройках модуля (по умолчанию 1 ГБ на часть). Восстановление идёт либо через тот же раздел админки, либо скриптом restore.php, который кладут в корень и открывают из браузера, если панель управления недоступна из-за поломанного сайта.
Для небольшого сайта-визитки или лендинга на Битриксе этого хватает: раз в неделю зашёл, нажал «Создать резервную копию», скачал архив на локальный диск. Проблемы начинаются, когда база разрастается за 3-5 ГБ и хостинг ограничивает время выполнения скрипта.
Автоматический бэкап по расписанию через агенты и cron
Вручную кликать в админке раз в неделю - так себе стратегия, я обычно ставлю автоматизацию сразу при запуске проекта. В Битриксе для этого два пути: агент модуля (функция CBackup, которая запускается по расписанию через хиты на сайт) и вызов backup.php из консоли по cron.
Агенты через хиты ненадёжны на низкопосещаемом сайте - если ночью никто не зашёл, агент не сработает вовремя. Поэтому я ставлю задачу в cron напрямую на сервере, обычно на 3-4 утра, когда нагрузка минимальная:
0 3 * * * /usr/bin/php -f /home/bitrix/www/bitrix/modules/main/tools/backup.php >> /var/log/bitrix_backup.log 2>&1Это убирает зависимость от посетителей сайта, но не снимает главное ограничение - скрипт всё равно выполняется в контексте PHP с его лимитами по памяти и времени.
Где штатный бэкап подводит на боевом проекте
На шаред-хостинге таймаут выполнения PHP-скрипта обычно 30-60 секунд, и для базы за 5-8 ГБ этого мало даже через консольный вызов - процесс просто обрывается на середине архивации. На VPS ограничение снимается, но там всплывает другая проблема: полный бэкап крупного интернет-магазина занимает 40-60 минут и в это время таблицы InnoDB блокируются для записи, заказы на сайте зависают.
Ещё три вещи, которые штатный модуль не умеет:
- Инкрементальные копии - каждый раз архивируется всё целиком, даже если поменялось 200 строк в таблице заказов
- Ротация старых архивов - без своего скрипта диск на сервере рано или поздно забивается копиями за полгода
- Уведомление об ошибке - если бэкап упал ночью, узнаёшь об этом только когда он реально понадобился
И последнее - архив хранится на том же сервере, где лежит сайт. Если сервер скомпрометирован или диск умер физически, резервная копия умирает вместе с ним.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Своя схема бэкапа: mysqldump, rsync и ротация по cron
На проектах, где база больше 2-3 ГБ или клиент прямо просит гарантии восстановления, я собираю бэкап руками из трёх частей: дамп базы через mysqldump с флагом - single-transaction (чтобы не блокировать InnoDB-таблицы), архив файлов с исключением кэша и временных папок, и выгрузка обоих архивов во внешнее хранилище.
Пример скрипта для cron
#!/bin/bash
DATE=$(date +%F)
BACKUP_DIR=/backup/bitrix
mysqldump --single-transaction -u backup_user -p'PASSWORD' sitedb | gzip > $BACKUP_DIR/db_$DATE.sql.gz
tar --exclude='bitrix/cache'
--exclude='bitrix/managed_cache'
--exclude='upload/resize_cache'
-czf $BACKUP_DIR/files_$DATE.tar.gz /home/bitrix/www
s3cmd put $BACKUP_DIR/db_$DATE.sql.gz s3://backups-ru/bitrix/
s3cmd put $BACKUP_DIR/files_$DATE.tar.gz s3://backups-ru/bitrix/
find $BACKUP_DIR -type f -mtime +30 -deleteПоследняя строка - ротация: держу локально копии за 30 дней, а в S3 настраиваю политику жизненного цикла отдельно, обычно 7 ежедневных плюс 4 еженедельные копии. Для картинок и файлов в upload, которые редко меняются целиком, вместо полного tar каждую ночь ставлю rsync с - link-dest - это экономит место и время на больших каталогах товаров.
Хранение копий и уведомления о падении бэкапа
Архив должен лежать не на том сервере, где сайт - это правило номер один. Я использую S3-совместимое хранилище у российского провайдера (Selectel, VK Cloud, Timeweb), особенно если в базе Битрикса хранятся персональные данные клиентов - телефоны, адреса, история заказов. Зарубежные облака вроде Google Drive или Dropbox для таких данных не подходят по требованиям 152-ФЗ о локализации ПДн, даже если технически туда что-то залить можно.
Отдельно ставлю проверку, что бэкап реально создался и весит адекватно - это спасало не раз, когда mysqldump падал молча из-за истёкшего пароля пользователя БД. Проще всего собрать это через n8n: сценарий раз в сутки проверяет дату и размер последнего файла в хранилище и, если файла нет или он подозрительно маленький, шлёт сообщение в Telegram через бота. Готовый скрипт под такую проверку и настройку ротации можно взять в библиотеке готовых скриптов и адаптировать под свой сервер за вечер.
Как правильно восстановить сайт Битрикс из резервной копии
Восстановление проверяю на тестовом сервере минимум раз в квартал - бэкап, который никогда не разворачивали, с равной вероятностью может оказаться битым архивом. Порядок такой:
- Распаковываю архив базы и файлов отдельно, проверяю целостность (tar ‑tzf на файлы, gunzip ‑t на дамп)
- Разворачиваю базу первой: создаю пустую БД, импортирую дамп, проверяю кодировку таблиц (utf8mb4 или koi8‑r в старых проектах - это разные истории)
- Разворачиваю файлы поверх чистого окружения, проверяю права на upload и bitrix/cache
- Правлю /bitrix/.settings.php - логин, пароль и хост базы почти всегда отличаются на новом сервере
- Пересоздаю задачи cron и агенты - они не восстанавливаются автоматически из файлового архива
Версия PHP и MySQL на новом сервере должна быть не ниже той, что стояла на боевом - Битрикс на старой базе может не подняться на MySQL 8 без правки конфигурации, особенно если в проекте остались устаревшие компоненты.
Штатный модуль или своя схема - что выбрать
| Критерий | Штатный модуль Битрикс | Своя схема (cron + mysqldump) |
|---|---|---|
| Место хранения | тот же сервер | внешнее S3-хранилище в РФ |
| Время бэкапа базы 8 ГБ | 40-60 минут, блокировка таблиц | 10-15 минут с - single-transaction |
| Уведомление об ошибке | нет | есть, через Telegram-бота или n8n |
| Ротация старых копий | нет | настраивается скриптом |
| Подходит для | визитки, лендинги, небольшие каталоги | магазины, сервисы с базой от 2-3 ГБ |
Если настраивать всё это самостоятельно некогда, я беру такие задачи отдельно - разработку скрипта резервного копирования с выгрузкой во внешнее хранилище и уведомлениями об ошибках оцениваю от 20 000 ₽ в зависимости от того, сколько окружений и баз нужно охватить.
Чтобы сайт работал без сбоев
Техподдержка
от 15 000 ₽/мес
Подробнее →Частые вопросы
Как часто делать резервную копию сайта на Битрикс?
Для интернет-магазина с ежедневными заказами - раз в сутки, ночью, плюс отдельный дамп базы перед любым обновлением модулей или ядра. Для визитки, которая не меняется месяцами, хватает еженедельного бэкапа.
Где хранить бэкапы Битрикса, чтобы не потерять их при взломе сервера?
Вне сервера с сайтом - на отдельном S3-совместимом хранилище у российского провайдера. Если в базе есть персональные данные клиентов, зарубежные облака вроде Google Drive использовать нельзя по 152-ФЗ, нужен сервер или хранилище в РФ.
Можно ли восстановить сайт Битрикс из бэкапа на другом хостинге?
Можно, но версии PHP и MySQL на новом сервере должны быть не ниже исходных, а после разворачивания архива обязательно правится /bitrix/.settings.php с новыми данными подключения к базе и пересоздаются задачи cron - они из файлового архива не восстанавливаются.
Что делать, если штатный бэкап не создаётся из-за таймаута?
Это типично для баз от 3-5 ГБ на обычном хостинге с лимитом выполнения PHP-скрипта в 30-60 секунд. Переходите на консольный вызов mysqldump по cron с флагом - single-transaction - он не зависит от лимитов веб-сервера и на той же базе отрабатывает в разы быстрее.