Моніторинг та тестування disaster recovery 1С-Бітрікс

Моніторинг і тестування disaster recovery 1С-Бітрікс

Написаний план відновлення без регулярних перевірок — не працює. Команда не знає реального RTO, бекапи можуть бути пошкоджені, конфігурація prod змінилась з моменту останнього drill. Моніторинг DR — це не лише спостереження за поточним станом, а й регулярне підтвердження того, що план відновлення можна виконати в заявлені терміни.

Що моніторити в контексті 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 — через zabbix_get з MySQL-агентом або кастомний UserParameter:

# zabbix_agentd.conf
UserParameter=mysql.slave.lag,mysql -u monitor -pXXX -e "SHOW SLAVE STATUS\G" 2>/dev/null | grep "Seconds_Behind_Master" | awk '{print $2}'

Вільне місце на backup-сервері

# Попередження при <20% вільного місця
df -h /backups | awk 'NR==2 {gsub(/%/,""); if ($5 > 80) print "WARNING: disk " $5 "% used"}'

Доступність 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]);

Регулярні DR drill: методологія

Quarterly drill (щоквартально) — повне відновлення на ізольований тест-стенд:

1. Беремо останній бекап БД і файлів
2. Розгортаємо на чистому сервері
3. Засікаємо час кожного етапу
4. Після відновлення — автоматизований 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"

Monthly drill (щомісяця) — відновлення лише БД. Перевіряємо актуальність дампу: відновлюємо на тест-сервер, робимо запити до b_sale_order, b_iblock_element, b_catalog_price — дивимося, що дані актуальні (останні записи не старіші за RPO).

-- Перевіряємо свіжість даних після відновлення
SELECT MAX(DATE_INSERT) as latest_order FROM b_sale_order;
-- Має бути не старіше RPO (наприклад, не старіше 4 годин)

SELECT COUNT(*) FROM b_iblock_element WHERE ACTIVE = 'Y';
-- Порівнюємо з очікуваною кількістю активних товарів

Метрики DR та SLA

Звітність по DR

Після кожного drill фіксуємо:

• Дата і час drill
• Версія плану (номер ревізії)
• Час кожного етапу відновлення
• Фактичний RTO vs плановий
• Проблеми, виявлені в ході drill
• Оновлення плану за підсумками

Цей журнал — не формальність. Він показує динаміку: чи погіршується RTO з часом (сайт зростає, бекап стає більшим, процедура не оновлюється).

Терміни налаштування моніторингу DR

Налаштування моніторингу бекапів, реплікації та healthcheck-ендпоінтів з інтеграцією в Zabbix/Prometheus + перший drill з автоматизованим smoke-тестом — 3–5 робочих днів.