Как организовать резервный дата-центр для 1С-Битрикс с нулевым RPO
Допустим, ваш интернет-магазин на Битрикс приносит 100 заказов в час. В пик нагрузки основной сервер выходит из строя из-за сбоя дискового массива. Без резервного ДЦ вы теряете каждый заказ до подъёма дампа — это часы простоя и миллионные убытки. Даже если есть бекап, его разворот занимает 2-3 часа, а данные за последние часы пропадают. Мы настраиваем резервный дата-центр, который перехватывает трафик за минуты, а потери данных не превышают секунды. Используем проверенные техники: GTID-репликацию MySQL, непрерывную синхронизацию файлов и автоматический failover DNS. Наш опыт — 50+ проектов от интернет-магазинов до корпоративных порталов. Каждый случай уникален, но мы выработали стандартный подход, который гарантирует RPO < 1 минуты и RTO < 5 минут.
Почему обычный бекап не подходит?
Резервное копирование не гарантирует быстрого восстановления, а копия на том же диске бесполезна при пожаре в ДЦ. Настоящая отказоустойчивость требует активной репликации базы и синхронизации файлов на вторую площадку. Наш стек — Percona Server 8.0, Lsyncd, Ansible — проверен на 50+ проектах.
Как настроить резервный ДЦ для 1С-Битрикс?
Есть три критичных компонента: репликация MySQL/MariaDB, синхронизация файлов и автоматический failover DNS. Разберём каждый.
Репликация базы данных
Используем GTID-репликацию — она проще в обслуживании и исключает рассинхрон при смене мастера. GTID автоматически отслеживает все транзакции, поэтому при promote реплики не нужно искать позицию в логах. Конфиг реплики:
[mysqld] server-id = 10 gtid_mode = ON enforce_gtid_consistency = ON read_only = ON log_slave_updates = ON Для мониторинга используем Prometheus + mysqld_exporter. Лаг репликации в секундах: Seconds_Behind_Master. Если видите 300 — проблема с сетью или нагрузкой.
Синхронизация файлов
Каталог upload/ синхронизируем непрерывно через inotifywait + rsync. Этот тандем ловит каждое изменение (create, modify, delete) и мгновенно передаёт diff на резервную площадку. Пример скрипта:
inotifywait -m -r -e create,modify,delete /var/www/bitrix/upload/ | while read path action file; do rsync -az /var/www/bitrix/upload/ backup-dc:/var/www/bitrix/upload/ & done Для больших проектов с тысячами файлов лучше использовать Lsyncd — он агрегирует события и снижает нагрузку на сеть. А вот конфиги (bitrix/.settings.php, dbconn.php) храним в Git и разворачиваем через Ansible. Это даёт версионирование и быстрый откат.
Готовый веб-стек на резервной площадке
На втором сервере должен стоять nginx, php-fpm, Redis с теми же версиями. Файлы ядра Битрикс (bitrix/, local/) копируем раз в сутки или после каждого деплоя. Это ускоряет активацию — не нужно качать гигабайты в момент аварии.
Что лучше: ручное переключение или автоматический failover?
Сравним в таблице:
| Критерий | Ручное переключение | Автоматический failover |
|---|---|---|
| Время реакции | 15-60 минут | 1-2 минуты |
| Риск ошибки | Высокий (человеческий фактор) | Низкий (скрипты проверены) |
| TTL DNS | 60-300 секунд (можно снизить) | 60 секунд (обязательно) |
| Стоимость настройки | Ниже (только скрипт) | Выше (плюс мониторинг) |
Автоматический failover снижает время восстановления в 10 раз по сравнению с ручным. Пример healthcheck-скрипта для Cloudflare:
#!/bin/bash MAIN_IP="185.10.1.100" BACKUP_IP="195.20.2.100" DOMAIN="your-site.ru" if ! curl -sf --max-time 10 "https://$DOMAIN/health" > /dev/null; then curl -X PATCH \ "https://api.cloudflare.com/client/v4/zones/$CF_ZONE_ID/dns_records/$CF_RECORD_ID" \ -H "Authorization: Bearer $CF_TOKEN" \ -H "Content-Type: application/json" \ --data '{"content":"'"$BACKUP_IP"'","ttl":60}' fi Как автоматизировать переключение через Ansible?
Когда failover сработал, на резервной площадке нужно выполнить последовательность действий?
Без автоматизации каждый шаг вручную — потеря времени и риск ошибки. Мы используем Ansible playbook, который за минуту:
- Повышает реплику до мастера:
STOP SLAVE; RESET SLAVE ALL; - Обновляет
bitrix/.settings.php— заменяет IP БД на127.0.0.1 - Убеждается, что Redis запущен, сессии доступны
- Проверяет агенты на странице
/bitrix/admin/agent_list.php - Выполняет тестовый заказ
- Уведомляет команду через Telegram/Slack
Пример playbook:
- name: Promote MySQL replica to master mysql_replication: mode: stopreplica - name: Update Bitrix DB config template: src: settings.php.j2 dest: /var/www/bitrix/bitrix/.settings.php vars: db_host: "127.0.0.1" - name: Restart php-fpm service: name: php8.1-fpm state: restarted Сравнение инструментов синхронизации
| Инструмент | Скорость | Нагрузка на IO | Подходит для |
|---|---|---|---|
| rsync + inotify | Высокая | Средняя | Маленькие каталоги (< 50 тыс. файлов) |
| Lsyncd | Средняя | Низкая | Большие каталоги с частыми изменениями |
| Unison | Низкая | Низкая | Двусторонняя синхронизация |
Для upload/ рекомендуем Lsyncd, если файлов больше 50 000.
Что входит в настройку резервного ДЦ под ключ
- Аудит текущей инфраструктуры
- Настройка GTID-репликации MySQL/MariaDB
- Установка и конфигурация Lsyncd/rsync для синхронизации файлов
- Настройка healthcheck-скрипта и автоматического обновления DNS
- Ansible playbook для failover
- Документация по процедуре переключения
- Обучение вашей команды (1 час, онлайн)
- Тестовое переключение с замерами RPO и RTO
Сроки настройки
От 5 до 8 рабочих дней, включая тестирование. Стоимость рассчитывается индивидуально — зависит от объёма данных, количества серверов и сложности интеграций.
Хотите такой же уровень защиты? Получите консультацию — наши инженеры бесплатно оценят ваш проект. Мы специализируемся на Битрикс более десяти лет, реализовали 50+ отказоустойчивых решений. Предоставляем гарантию на выполненные работы.