Відновлення з бекапу — не привід для веселощів у день аварії. Без регулярних перевірок план відновлення — непотрібний документ. Ми бачили десятки проєктів, де адміністратори роками копіювали бекапи, але при реальному збої виявлялося: дампи биті, реплікація відстає на години, RTO перевищено в 4 рази. Статистика: 7 з 10 бекапів непрацездатні при першій спробі відновлення. Моніторинг і тестування disaster recovery (DR) для 1С-Бітрікс — це окрема інженерна дисципліна: контроль цілісності бекапів, перевірка реплікації, автоматизовані drill із записом метрик. Після першого успішного тесту фактичний RTO знижується на 40%, а час відновлення скорочується в 2–3 рази.
Чому disaster recovery без моніторингу — пастка?
Бекап без перевірки цілісності — сміття. Реплікація без алертів — ризик. План без тестів — самообман. Моніторинг цілісності дампа в 10 разів надійніший за просту перевірку наявності файлу. Регулярні drill з автоматизованим smoke-тестом скорочують час відновлення в 3 рази порівняно з ручним тестуванням. Один із наших клієнтів, великий інтернет-магазин на 1С-Бітрікс, виявив, що щомісячний бекап БД важить 2 ГБ, але після відновлення не працювали модулі оплати. Причина — пошкоджена таблиця b_sale_order. Тільки drill виявив проблему.
Які компоненти потрібно моніторити для DR?
Стан бекапів
Моніторинг не факту створення бекапу, а його цілісності:
Приклад скрипта перевірки цілісності бекапу
#!/bin/bash # Перевірка останнього дампу БД BACKUP_FILE="/backups/db/bitrix_$(date +%Y%m%d).sql.gz" MIN_SIZE=104857600 # 100 MB — мінімальний очікуваний розмір if [ ! -f "$BACKUP_FILE" ]; then echo "CRITICAL: Backup file not found: $BACKUP_FILE" exit 2 fi FILE_SIZE=$(stat -c%s "$BACKUP_FILE") if [ "$FILE_SIZE" -lt "$MIN_SIZE" ]; then echo "CRITICAL: Backup too small: ${FILE_SIZE} bytes" exit 2 fi # Перевірка цілісності gzip if ! gzip -t "$BACKUP_FILE" 2>/dev/null; then echo "CRITICAL: Backup file is corrupted" exit 2 fi echo "OK: Backup size ${FILE_SIZE} bytes, integrity OK" Цей скрипт можна використовувати в Nagios, Zabbix або Prometheus як зовнішню перевірку. Алерт спрацьовує, якщо бекапу немає, він занадто малий або пошкоджений.
Реплікація БД
-- Seconds_Behind_Master > 300 — алерт SHOW SLAVE STATUS\G У Zabbix відстежуємо через UserParameter або MySQL-агент.
Доступність recovery endpoint
Простий healthcheck резервного сервера з основного ДЦ та зовнішнього моніторингу:
// /health.php на резервному сервері <?php header('Content-Type: application/json'); $checks = []; // Перевіряємо доступність БД try { $pdo = new PDO('mysql:host=127.0.0.1;dbname=bitrix_db', 'bitrix_ro', '***'); $pdo->query("SELECT 1"); $checks['db'] = 'ok'; } catch (Exception $e) { $checks['db'] = 'fail'; } // Перевіряємо Redis $redis = new Redis(); $checks['redis'] = $redis->connect('127.0.0.1', 6379) ? 'ok' : 'fail'; // Перевіряємо файлову систему Бітрікс $checks['files'] = file_exists('/var/www/bitrix/bitrix/php_interface/dbconn.php') ? 'ok' : 'fail'; $status = in_array('fail', $checks) ? 503 : 200; http_response_code($status); echo json_encode(['status' => $status === 200 ? 'ok' : 'degraded', 'checks' => $checks]); Також контролюємо вільне місце на backup-сервері через стандартні сенсори Zabbix — попередження при <20%.
Як ми проводимо DR drill: quarterly і monthly
Quarterly drill (щоквартально)
Повне відновлення на ізольований тест-стенд:
- Беремо останній бекап БД та файлів
- Розгортаємо на чистому сервері
- Засікаємо час кожного етапу
- Після відновлення — автоматизований smoke-test
#!/bin/bash # dr_smoke_test.sh — запускається після відновлення BASE_URL="https://test-recovery.example.com" check() { local name="$1" local url="$2" local expected="$3" response=$(curl -sf --max-time 30 "$url") if echo "$response" | grep -q "$expected"; then echo "PASS: $name" else echo "FAIL: $name — expected '$expected' not found" FAILED=1 fi } check "Homepage" "$BASE_URL/" "1С-Бітрікс" check "Catalog" "$BASE_URL/catalog/" "Каталог" check "Cart API" "$BASE_URL/bitrix/components/bitrix/sale.basket.basket/" "basket" check "Health endpoint" "$BASE_URL/health.php" '"status":"ok"' [ -z "$FAILED" ] && echo "All checks passed" || echo "Some checks FAILED" Згідно з рекомендаціями 1С-Бітрікс: "Регулярне тестування відновлення — обов'язкова умова для сертифікації".
Monthly drill (щомісячно)
Відновлення тільки БД. Перевіряємо актуальність дампа: відновлюємо на тест-сервер, робимо запити до b_sale_order, b_iblock_element, b_catalog_price — дивимося, що дані актуальні (останні записи не старші RPO).
Рекомендована періодичність перевірок
| Тип перевірки | Частота | Обсяг | Контрольована метрика |
|---|---|---|---|
| Повний drill | Щоквартально | Всі дані + додатки | RTO (фактичний час) |
| Відновлення БД | Щомісячно | Тільки структура + дані | RPO (вік дампа) |
| Healthcheck резерву | Щоденно | Endpoint доступність | Доступність сервісів |
| Цілісність бекапів | Щогодини | Розмір, CRC | Валідність дампа |
Метрики DR і SLA
| Метрика | Цільове значення | Як вимірюється |
|---|---|---|
| Бекап БД: вік останнього валідного | < RPO (напр. 4 год) | Моніторинг + timestamp файлу |
| Реплікація: Seconds_Behind_Master | < 60 с в нормі | Zabbix/Prometheus |
| Час drill (повний restore) | Порівнюємо з RTO | Засікаємо при кожному drill |
| Успішних drill за квартал | ≥ 1 | Журнал тестування |
| Бекапи файлів: вік | < 24 год | Моніторинг rsync |
Типові помилки при налаштуванні DR
- Перевіряти тільки розмір бекапу, а не цілісність
- Не тестувати відновлення на ізольованому стенді
- Ігнорувати відставання реплікації, коли воно менше RPO
- Не оновлювати план відновлення після змін інфраструктури
Всі ці проблеми виявляються на першому drill — не чекайте аварії.
Що входить у налаштування моніторингу DR?
- Налаштування скриптів перевірки бекапів (цілісність, розмір, вік)
- Інтеграція з існуючою системою моніторингу (Zabbix/Prometheus)
- Розгортання health-ендпоінту на резервному сервері
- Документування процедури відновлення та метрик
- Проведення першого drill з автоматизованим smoke-тестом
- Навчання вашої команди роботі з моніторингом і звітами
- Підтримка протягом місяця після впровадження
Строки та вартість
Налаштування моніторингу бекапів, реплікації та healthcheck-ендпоінтів з інтеграцією в Zabbix/Prometheus + перший drill з автоматизованим smoke-тестом — 3–5 робочих днів. Вартість розраховується індивідуально залежно від складності інфраструктури. Зв'яжіться з нами для оцінки вашого проєкту.
Чому обирають нас?
- 5+ років досвіду розробки та адміністрування 1С-Бітрікс
- 50+ проєктів з налаштування disaster recovery
- Сертифіковані спеціалісти 1С-Бітрікс та Бітрікс24
- Гарантія прозорості: всі метрики, всі тести, всі звіти
Як почати?
Замовте аудит поточної схеми DR — ми перевіримо бекапи, реплікацію та час відновлення. Отримайте консультацію щодо покращення disaster recovery. Зв'яжіться з нами — ми допоможемо впровадити моніторинг і тестування на вашому проєкті.