Разработка плана аварийного восстановления 1С-Битрикс

Разработка плана аварийного восстановления 1С-Битрикс

Сайт упал в пятницу вечером. Нет понимания, что делать: бекап есть, но непонятно, куда его разворачивать, в каком порядке, кто за что отвечает. Через два часа паники восстанавливают что-то похожее на рабочее состояние — но данные за последние 6 часов потеряны, и ещё три дня разгребают последствия. Disaster Recovery Plan (DRP) — это не бюрократический документ, а пошаговая инструкция с конкретными командами, проверенная в условиях реального отказа.

Что должен содержать DRP для Битрикс

Хороший план не описывает теорию — он описывает конкретные действия конкретного человека. Минимальный состав:

• Матрица ролей: кто что делает при аварии (DevOps, разработчик, менеджер, служба поддержки)
• RTO (Recovery Time Objective) и RPO (Recovery Point Objective) — согласованные с бизнесом: «восстановить за 2 часа, потеря данных не более 1 часа»
• Контакты: хостинг, 1С-партнёр, ответственный разработчик, резервный разработчик
• Схема бекапов с указанием мест хранения и способов доступа
• Пошаговые сценарии восстановления для каждого типа отказа

Типы отказов и сценарии

Сценарий 1: Падение веб-сервера (nginx/apache)

# Диагностика
systemctl status nginx
journalctl -xe -u nginx --since "10 minutes ago"
nginx -t  # Проверка конфига

# Быстрый откат конфига
cp /etc/nginx/nginx.conf.bak /etc/nginx/nginx.conf
systemctl restart nginx

Сценарий 2: Повреждение файловой системы Битрикс

# Остановить php-fpm, чтобы не затирало восстанавливаемые файлы
systemctl stop php8.1-fpm

# Восстановление из резервной копии (rsync с backup-сервера)
rsync -az --delete backup-server:/backups/bitrix/latest/ /var/www/bitrix/

# Восстановить права
chown -R www-data:www-data /var/www/bitrix/
find /var/www/bitrix/ -type d -exec chmod 755 {} \;
find /var/www/bitrix/ -type f -exec chmod 644 {} \;

systemctl start php8.1-fpm

Сценарий 3: Повреждение или потеря базы данных

Самый критичный сценарий для интернет-магазина. Таблицы b_sale_order, b_sale_basket, b_catalog_price — данные, которые нельзя потерять.

# Восстановление из mysqldump
mysql -u root -p < /backups/db/bitrix_$(date +%Y%m%d).sql

# Если дамп частичный — восстановление отдельных таблиц
mysql -u root -p bitrix_db < /backups/db/b_sale_order_$(date +%Y%m%d).sql
mysql -u root -p bitrix_db < /backups/db/b_catalog_price_$(date +%Y%m%d).sql

При использовании MySQL репликации — переключение на реплику:

# На реплике
STOP SLAVE;
RESET SLAVE ALL;
# Меняем dbconn.php на IP реплики
# Реплика становится мастером

Сценарий 4: Взлом и заражение

Восстановление из бекапа до момента взлома — но сначала нужно понять, когда это произошло. Битрикс пишет лог в /bitrix/php_interface/error.log и в таблицу b_event_log. Анализируем access-лог nginx:

# Найти первые признаки аномалии
grep -E "(POST|eval|base64_decode|system\()" /var/log/nginx/access.log | \
    awk '{print $1}' | sort | uniq -c | sort -rn | head -20

# После восстановления — смена всех паролей
# /bitrix/.settings.php — пароль БД
# /bitrix/php_interface/dbconn.php
# Пароли всех администраторов через b_user

Структура бекапов под DRP

Стандартная схема, которую мы закладываем в план:

Бекап БД каждые 4 часа при RPO = 1 час — недостаточно. В этом случае добавляем непрерывную репликацию бинлога: она позволяет восстановить состояние на любой момент времени через mysqlbinlog.

Битрикс-специфика: что теряется при стандартном бекапе

Стандартный инструмент «Резервное копирование» в административной панели (Настройки → Инструменты → Резервное копирование) создаёт архив сайта. Но он не включает:

• Кэш Bitrix (/bitrix/cache/, /bitrix/managed_cache/) — не нужен при восстановлении, его нужно пересоздать
• Временные файлы сессий — нужно очистить после восстановления: \Bitrix\Main\Application::getInstance()->getSession()->destroy()
• Данные из внешних сервисов (1С, CRM) — нужна отдельная процедура ресинхронизации
• SSL-сертификаты — хранятся отдельно от файлов сайта

После восстановления из бекапа обязательный чеклист:

1. Сбросить кэш: BXClearCache(true) или через bitrix/admin/cache.php
2. Перестроить фасетный индекс каталога
3. Проверить агентов Битрикс (/bitrix/admin/agent_list.php)
4. Проверить cron-задачи
5. Запустить тестовый заказ в магазине

RTO по типам отказов

RTO «4 часа» без тестирования — это оптимистичная оценка. Реальный RTO устанавливается после первого drill: прогона восстановления в тестовой среде с измерением времени.

Тестирование плана

DRP, который ни разу не проверялся — не работает. Минимум раз в квартал проводим drill:

• Восстанавливаем последний бекап на тестовую среду
• Засекаем время каждого шага
• Проверяем корректность данных (заказы, товары, пользователи)
• Фиксируем расхождения с планом и обновляем документ

Сроки разработки