Настройка disaster recovery для 1С-Битрикс

Настройка disaster recovery для 1С-Битрикс

Сервер упал в 2:30 ночи. База данных последний раз бекапировалась в 23:00. Сайт недоступен, менеджеры не видят заказы, клиенты уходят к конкурентам. Восстановительный план существует только в голове администратора — скрипты не обновлялись год, а репликация базы даже не настроена. Типичная ситуация на проектах, где disaster recovery (DR) описан в договоре, но ни разу не тестировался. Стоимость простоя интернет-магазина на 1С-Битрикс может составлять около $9–13 в час — за сутки потери достигают миллионов. Мы — команда инженеров с 10-летним опытом восстановления Битрикс-проектов — видели десятки таких аварий. В этой статье разберём, как построить DR, который действительно работает, а не просто пылится в документации.

Согласно официальной документации 1С-Битрикс, настройка резервного копирования — обязательный шаг для проектов в production.

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

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

Компоненты, которые нужно восстанавливать

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

• Код приложения — /var/www/bitrix/ (ядро) и /local/ (кастомизации). Код хранится в git — это должен быть стандарт, не исключение.
• База данных — PostgreSQL или MySQL. Для Битрикс с нагрузкой — primary/replica схема, снапшоты реплики.
• Загруженные файлы — /upload/, /bitrix/backup/. Объём растёт непрерывно, часто игнорируется при настройке бекапов.
• Конфигурационные файлы — /bitrix/.settings.php, /bitrix/php_interface/dbconn.php, конфиги nginx/php-fpm.

Встроенный механизм резервного копирования

Битрикс имеет встроенный инструмент бекапа (/bitrix/admin/backup.php). Он создаёт архивы в /bitrix/backup/ через агент CBackupAgent. Параметры хранятся в b_option, модуль main:

• backup_auto — включить автоматический бекап
• backup_period — период в часах
• backup_keep_count — количество хранимых копий

Встроенный бекап работает, но имеет ограничения: при больших проектах (база > 5 ГБ, /upload/ > 20 ГБ) он таймаутится, занимает много места на том же сервере, и не даёт репликации на внешние хранилища из коробки.

Почему встроенный бекап не подходит для крупных проектов?

При нагрузке более 1000 заказов в день база растёт быстро, и полный дамп перестаёт успевать завершиться за ночное окно. Кроме того, архив хранится на том же диске, что и сайт — при отказе диска вы теряете всё. Для production-проектов мы рекомендуем отказаться от встроенного бекапа в пользу внешних инструментов.

Стратегия: три уровня защиты

Уровень 1 — БД в реальном времени. PostgreSQL streaming replication или MySQL GTID-репликация. Реплика принимает WAL/binlog и отстаёт на секунды. При падении primary — ручной или автоматический failover на реплику. Настройка в postgresql.conf:

wal_level = replica max_wal_senders = 3 wal_keep_size = 1GB 

Уровень 2 — ежечасные снапшоты БД. pg_dump или xtrabackup через cron, результат — во внешнее хранилище (S3, rsync на offsite-сервер). Для PostgreSQL предпочтителен pg_basebackup для физического бекапа — быстрее восстановление.

Уровень 3 — файловые бекапы. /upload/ растёт линейно, полный бекап каждые сутки нецелесообразен. Инкрементальный rsync или Restic:

restic -r s3:s3.amazonaws.com/bucket/upload \ backup /var/www/site/upload \ --exclude /var/www/site/upload/resize_cache 

resize_cache исключается — он восстанавливается автоматически при обращении к изображениям.

Какой RTO и RPO можно гарантировать?

Для типового интернет-магазина с базой до 10 ГБ и посещаемостью до 10 000 уникальных посетителей в сутки мы гарантируем: RPO не более 1 минуты при наличии репликации, RTO — не более 30 минут. Достигается это за счёт автоматизированного скрипта восстановления и регулярного тестирования. Если ваш проект крупнее — считаем индивидуально.

Тестирование DR — обязательный шаг

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

# Проверка целостности дампа БД pg_restore --list /backup/site.dump | tail -20 # Проверка, что сайт поднимается из бекапа # Тест: оформить заказ, зайти в административную часть 

Фиксируем реальное время восстановления. Если оно превышает заявленный RTO — оптимизируем процедуру.

Что входит в настройку DR

В результате вы получаете: настроенную репликацию БД, ежечасные снапшоты, инкрементальный бекап upload, скрипт восстановления с пошаговой инструкцией, регламент тестирования и алерты при сбоях.

Что настраиваем

• Streaming replication PostgreSQL/MySQL с мониторингом отставания реплики
• Ежечасный pg_dump или pg_basebackup во внешнее хранилище
• Инкрементальный бекап /upload/ через Restic или rsync с исключением resize_cache
• Скрипт восстановления с задокументированным порядком действий
• Регламент ежеквартального тестирования с замером реального RTO
• Алерты при сбое бекапа (отсутствие файла за последние X часов)

Наш опыт — 10+ лет в Битрикс, более 50 восстановленных проектов. Гарантируем, что после настройки disaster recovery ваш сайт будет подниматься за регламентное время. Свяжитесь с нами для аудита вашей текущей схемы бекапов — оценим проект и предложим оптимальное решение. Получите консультацию по настройке disaster recovery для вашего 1С-Битрикс проекта. Экономия от правильно настроенного DR может измеряться миллионами долларов при аварии.