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

Сайт впав у п'ятницю ввечері. Бекап є, але незрозуміло, куди розгортати і в якому порядку. Через дві години паніки відновлюють щось схоже на робочий стан, але дані за останні 6 годин втрачені. Ще три дні йде на розбір наслідків. Кожна година простою обходиться інтернет-магазину в $1000, а без плану відновлення затягується на 3–6 годин. Ми стикалися з такими ситуаціями на десятках проектів і знаємо, як їх уникнути.

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

Які розділи включає DRP?

Хороший план не описує теорію — він описує конкретні дії конкретної людини. Мінімальний склад:

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

Чому DRP важливий для інтернет-магазину?

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

Типи відмов та сценарії

Сценарій 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 місяць

Строки та вартість

Вартість розраховується індивідуально, залежно від масштабу проекту. Орієнтовна вартість — від $1500. Замовте розробку DRP — ми оцінимо ваш проект за 2 дні та запропонуємо оптимальне рішення. Зв'яжіться з нами, щоб отримати консультацію.