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

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

Сервер умер в 2:30 ночи. База данных последний раз бекапировалась в 23:00. Сайт недоступен. Когда всё поднимется — неизвестно: никто не проверял, работает ли вообще резервное копирование. Это типичная ситуация на проектах, где DR существует «на бумаге», но ни разу не тестировался.

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

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

1. Код приложения — /var/www/bitrix/ (ядро) и /local/ (кастомизации). Код хранится в git — это должен быть стандарт, не исключение.
2. База данных — PostgreSQL или MySQL. Для Битрикс с нагрузкой — primary/replica схема, снапшоты реплики.
3. Загруженные файлы — /upload/, /bitrix/backup/. Объём растёт непрерывно, часто игнорируется при настройке бекапов.
4. Конфигурационные файлы — /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 ГБ) он таймаутится, занимает много места на том же сервере, и не даёт репликации на внешние хранилища из коробки.

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

Уровень 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 для типового проекта

• RPO (допустимые потери данных): при потоковой репликации — секунды. При почасовых снапшотах — до 1 часа.
• RTO (время восстановления): зависит от размера БД. PostgreSQL с WAL PITR восстанавливает 10 ГБ базы за 15–30 минут. Развёртывание приложения из git + восстановление конфигов — 5–10 минут.

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

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

# Проверка целостности дампа БД
pg_restore --list /backup/site.dump | tail -20

# Проверка, что сайт поднимается из бекапа
# Тест: оформить заказ, зайти в административную часть

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

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

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