Мониторинг и тестирование 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 рабочих дней.