Резервное копирование в BitrixVM

Резервное копирование в BitrixVM можно организовать на двух уровнях: штатным модулем 1С-Битрикс из админки и серверными инструментами (mysqldump, xtrabackup, tar, снапшоты). Первый удобен для небольших сайтов, второй обязателен для нагруженных проектов с большой базой. Разберём оба подхода и грамотную стратегию хранения.

Что именно нужно резервировать

Полноценная копия сайта на 1С-Битрикс состоит из двух несовместимых по природе частей, и терять из виду нельзя ни одну.

• База данных (MySQL/MariaDB) — структура и данные: инфоблоки, заказы, пользователи, настройки. Это самая ценная и быстро меняющаяся часть.
• Файлы — ядро /bitrix/, публичная часть, загруженные файлы /upload/, шаблоны и кастомный код.

Ключевой нюанс — согласованность: дамп базы и архив файлов должны относиться к одному моменту. Если между ними прошло время активных заказов, при восстановлении получите рассинхрон (например, запись о заказе есть, а прикреплённый файл ещё не появился).

Штатное резервное копирование Bitrix

В админке 1С-Битрикс есть модуль резервного копирования: Настройки → Инструменты → Резервное копирование. Он создаёт архив с файлами и дампом БД, разбивая его на части заданного размера, и умеет сразу выгружать копию в облако.

• Архивы по умолчанию складываются в /home/bitrix/www/bitrix/backup/.
• Поддерживается выгрузка в «1С-Битрикс: облачное хранение» и в S3-совместимые хранилища — так копия хранится вне сервера.
• Восстановление выполняется скриптом restore.php, положенным в пустой каталог, — он разворачивает архив и подхватывает настройки подключения к БД.

Плюс подхода — не нужен доступ к серверу по SSH, всё из браузера. Минусы проявляются на больших проектах:

Серверный бэкап: mysqldump и tar

Классическая связка для сайтов среднего размера — логический дамп базы и архив файлов. Дамп БД с ключами, важными для 1С-Битрикс:

mysqldump --single-transaction --quick --routines --triggers -u bitrix -p sitemanager | gzip > /backup/db_$(date +%F).sql.gz

Флаг --single-transaction даёт согласованный снимок InnoDB без блокировки таблиц — критично для работающего магазина. Архив файлов с исключением кеша:

tar --exclude='bitrix/cache' --exclude='bitrix/managed_cache' -czf /backup/files_$(date +%F).tar.gz -C /home/bitrix/www .

Обернём в скрипт и повесим на cron, например ежедневно ночью:

0 3 * * * /root/scripts/backup.sh >> /var/log/backup.log 2>&1

• Пароль к БД берите из .settings.php, а в скрипте используйте файл ~/.my.cnf с правами 600, чтобы не светить его в командной строке.
• Именуйте архивы с датой — упростит ротацию и поиск нужной точки.

Большие базы: xtrabackup и снапшоты

Когда база вырастает до десятков-сотен гигабайт, mysqldump становится медленным и тяжёлым для восстановления. Здесь применяют физический бэкап и снимки.

Percona XtraBackup копирует файлы InnoDB на горячую, без остановки базы, и позволяет разворачивать её за минуты. Для критичных проектов часто разворачивают реплику MySQL и снимают резервные копии именно с неё — так основной сервер не испытывает нагрузки от бэкапа.

Хранение и правило 3-2-1

Бэкап, лежащий на том же сервере, что и сайт, — это не бэкап: при отказе диска или компрометации сервера вы теряете всё сразу. Ориентир — правило 3-2-1.

• 3 копии данных;
• 2 разных носителя/хранилища;
• 1 копия — офсайт, физически вне основного сервера.

Практическая реализация для BitrixVM: локальная копия для быстрого отката + выгрузка в S3-совместимое хранилище или на отдельный backup-сервер по rsync/rclone. Настройте ротацию, чтобы копии не съели диск:

find /backup -name '*.gz' -mtime +14 -delete

Проверка восстановления

Непроверенный бэкап равносилен отсутствию бэкапа. Регулярно прогоняйте тестовое восстановление на отдельном стенде, а не в бою. Порядок для серверной копии:

1. Развернуть файлы: tar -xzf files_2026-07-01.tar.gz -C /home/bitrix/www_test.
2. Создать пустую БД и залить дамп: zcat db_2026-07-01.sql.gz | mysql -u root -p sitemanager_test.
3. Поправить параметры подключения в bitrix/.settings.php и bitrix/php_interface/dbconn.php под тестовую БД.
4. Открыть сайт на тестовом домене и проверить работу каталога, заказов, авторизации.

Итог

В BitrixVM резервное копирование выбирают по размеру и критичности проекта: небольшому сайту хватит штатного модуля Bitrix с выгрузкой в облако, среднему — cron-скрипт с mysqldump и tar, нагруженному — xtrabackup и бэкап с реплики. Обязательные условия для всех: согласованность копии файлов и БД, хранение офсайт по правилу 3-2-1, ротация и регулярная проверка восстановления.

Мы выстраиваем отказоустойчивую инфраструктуру и регламент резервного копирования для проектов на 1С-Битрикс в рамках DevOps и поддержки: настраиваем автоматические бэкапы, офсайт-хранилище, мониторинг успешности копий и отрабатываем сценарии восстановления, чтобы в критической ситуации сайт поднимался предсказуемо и в срок.