Налаштування disaster recovery для 1С-Бітрікс

Налаштування disaster recovery для 1С-Bitrix

Сервер умер о 2:30 ночі. База даних останній раз бекапувалась о 23:00. Сайт недоступний. Коли всё подніметься — невідомо: ніхто не перевіряв, чи взагалі працює резервне копіювання. Це типова ситуація на проектах, де DR існує «на папері», але ніколи не тестувався.

Компоненти, які потрібно відновлювати

Bitrix-проект складається з кількох незалежних шарів, кожен вимагає окремої стратегії резервного копіювання:

1. Код програми — /var/www/bitrix/ (ядро) та /local/ (кастомізації). Код зберігається в git — це повинен бути стандарт, не виняток.
2. База даних — PostgreSQL або MySQL. Для Bitrix під навантаженням — primary/replica схема, снимки реплики.
3. Завантажені файли — /upload/, /bitrix/backup/. Обсяг зростає постійно, часто ігнорується при налаштуванні бекапів.
4. Конфігураційні файли — /bitrix/.settings.php, /bitrix/php_interface/dbconn.php, конфіги nginx/php-fpm.

Вбудований механізм резервного копіювання

Bitrix має вбудований інструмент бекапу (/bitrix/admin/backup.php). Він створює архіви в /bitrix/backup/ через агент CBackupAgent. Параметри зберігаються в b_option, модуль main:

• backup_auto — включити автоматичний бекап
• backup_period — період в годинах
• backup_keep_count — кількість зберіганих копій

Вбудований бекап працює, але має обмеження: при великих проектах (база > 5 ГБ, /upload/ > 20 ГБ) він таймаутиться, займає багато місця на тому ж сервері, та не дає репліцирування на зовнішні сховища з коробки.

Стратегія: рівні захисту

Рівень 1 — БД в реальному часі. PostgreSQL streaming replication або MySQL GTID-репліцирування. Реплика приймає WAL/binlog та відстає на секунди. При падінні primary — ручний або автоматичний failover на реплику. Налаштування в postgresql.conf:

wal_level = replica
max_wal_senders = 3
wal_keep_size = 1GB

Рівень 2 — щогодинні снимки БД. pg_dump або xtrabackup через cron, результат — у зовнішне сховище (S3, rsync на offsite-сервер). Для PostgreSQL переважний pg_basebackup для фізичного бекапу — швидше відновлення.

Рівень 3 — файлові бекапи. /upload/ зростає лінійно, повний бекап щодня нецілісний. Інкрементальний rsync або Restic:

restic -r s3:s3.amazonaws.com/bucket/upload \
    backup /var/www/site/upload \
    --exclude /var/www/site/upload/resize_cache

resize_cache виключається — він відновлюється автоматично при зверненні до зображень.

RTO/RPO для типового проекту

• RPO (допустимі втрати даних): при потоковій репліціруванні — секунди. При щогодинних снимках — до 1 години.
• RTO (час відновлення): залежить від розміру БД. PostgreSQL з WAL PITR відновлює 10 ГБ базу за 15–30 хвилин. Розгортання програми з git + відновлення конфігів — 5–10 хвилин.

Тестування DR — обов'язковий крок

DR без регулярного тестування — хибна впевненість. Раз на квартал: беремо останній бекап, піднімаємо на ізольованому стенді, перевіряємо:

# Перевірка цілісності дампу БД
pg_restore --list /backup/site.dump | tail -20

# Перевірка, що сайт піднімається з бекапу
# Тест: оформити замовлення, зайти в адміністративну частину

Фіксуємо реальний час відновлення. Якщо він перевищує заявлений RTO — оптимізуємо процедуру.

Що налаштовуємо

• Streaming replication PostgreSQL/MySQL з моніторингом відставання реплики
• Щогодинний pg_dump або pg_basebackup у зовнішне сховище
• Інкрементальний бекап /upload/ через Restic або rsync з виключенням resize_cache
• Скрипт відновлення з задокументованим порядком дій
• Регламент щоквартального тестування з замером реального RTO
• Алерти при збої бекапу (відсутність файлу за останні X годин)