Розробка плану аварійного відновлення 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.

Специфіка 1С-Бітрікс: що втрачається при стандартному бекапі

Стандартний інструмент «Резервне копіювання» в адміністративній панелі (Налаштування → Інструменти → Резервне копіювання) створює архів сайту. Але він не включає:

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

Обов'язковий чеклист після відновлення з бекапу:

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

RTO за типами збоїв

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

Тестування плану

DRP, який жодного разу не перевірявся — не працює. Мінімум раз на квартал проводимо drill:

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

Терміни розробки