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

Сайт упал в пятницу вечером. Бекап есть, но непонятно, куда разворачивать и в каком порядке. Через два часа паники восстанавливают что-то похожее на рабочее состояние, но данные за последние 6 часов потеряны. Ещё три дня уходит на разбор последствий. Каждый час простоя обходится интернет-магазину в $140–200. убытка, а без плана восстановление затягивается на 3–6 часов. Мы сталкивались с такими ситуациями на десятках проектов и знаем, как их избежать.

Disaster Recovery Plan (DRP) решает эту проблему: это не бюрократический документ, а конкретная пошаговая инструкция с командами, проверенная в условиях реального отказа. Наша команда имеет 5+ лет опыта в восстановлении Битрикс-проектов и реализовала более 30 DRP. Автоматизированный DRP с Runbook сокращает время восстановления в 5 раз по сравнению с ad-hoc действиями, а регулярное тестирование снижает риск потери данных в 3 раза.

Какие разделы включает DRP?

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

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

Почему DRP важен для интернет-магазина?

При отказе базы данных теряются заказы и цены. Восстановление из дампа вручную без плана занимает 3–6 часов, а с DRP — 1–2 часа. RTO в 4 часа может оказаться критичным: каждый час простоя теряется конверсия и доверие клиентов. Средний убыток от часового простоя интернет-магазина — $140–200. Согласно документации Битрикс, стандартный бекап не включает кэш и временные файлы — после восстановления нужны дополнительные шаги.

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

Сценарий 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-сертификаты — хранятся отдельно от файлов сайта

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

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

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

DRP необходимо тестировать минимум раз в квартал. Проводится drill-восстановление на тестовой среде: разворачивается бекап, засекается время каждого шага, проверяется целостность данных. После теста план корректируется. Регулярное тестирование снижает риск длительного простоя в 3 раза по сравнению с ежегодным тестированием.

Как мы разрабатываем DRP?

Процесс состоит из пяти этапов:

1. Аудит текущей инфраструктуры — схема бекапов, точки отказа, роли (1-2 дня).
2. Определение RTO/RPO — согласование с бизнесом критичности данных и времени простоя.
3. Разработка сценариев и Runbook — 4-6 сценариев с конкретными командами (2-3 дня).
4. Настройка инфраструктуры бекапов — S3, репликация, мониторинг (2-5 дней).
5. Тестовый drill и корректировка — восстановление на тест-стенде, замер времени, обновление плана (1-2 дня).

После утверждения передаём документацию и проводим обучение команды.

Что входит в разработку DRP под ключ?

• Анализ инфраструктуры и точек отказа
• Согласование RTO и RPO
• Сценарии восстановления для 4+ типов отказов
• Настройка системы бекапов (S3, репликация, мониторинг)
• Написание Runbook с командами
• Проведение drill-тестирования
• Документация и обучение команды
• Пост-релизная поддержка 1 месяц

Сроки и стоимость

Стоимость рассчитывается индивидуально, в зависимости от масштаба проекта. Закажите разработку DRP — мы оценим ваш проект за 2 дня и предложим оптимальное решение. Свяжитесь с нами, чтобы получить консультацию.