Налаштування disaster recovery для 1С-Бітрікс
Сервер упав о 2:30 ночі. База даних востаннє бекапилася о 23:00. Сайт недоступний, менеджери не бачать замовлення, клієнти йдуть до конкурентів. План відновлення існує тільки в голові адміністратора — скрипти не оновлювалися рік, а реплікація бази навіть не налаштована. Типова ситуація на проєктах, де disaster recovery (DR) описано в договорі, але ніколи не тестувався. Вартість простою інтернет-магазину на 1С-Бітрікс може становити тисячі гривень на годину — за добу збитки сягають мільйонів. Ми — команда інженерів із 10-річним досвідом відновлення Бітрікс-проєктів — бачили десятки таких аварій. У цій статті розберемо, як побудувати DR, який дійсно працює, а не просто пилиться в документації.
Згідно з офіційною документацією 1С-Бітрікс, налаштування резервного копіювання — обов'язковий крок для проєктів у production.
На практиці типовий проєкт стикається з трьома основними проблемами: бекапи виконуються на тому ж сервері, відсутня реплікація бази даних, і ніхто не перевіряє цілісність архівів. Усі ці ризики накопичуються і в момент збою перетворюються на втрату даних і репутації.
Побудова надійного DR починається з аудиту поточної інфраструктури та вибору відповідної стратегії. Нижче розберемо, які компоненти потребують захисту та які інструменти використовувати.
Компоненти, які потрібно відновлювати
Bitrix-проєкт складається з кількох незалежних шарів, кожен потребує окремої стратегії резервного копіювання:
- Код застосунку —
/var/www/bitrix/(ядро) та/local/(кастомізації). Код зберігається в git — це має бути стандарт, не виняток. - База даних — PostgreSQL або MySQL. Для Бітрікс із навантаженням — primary/replica схема, снапшоти репліки.
- Завантажені файли —
/upload/,/bitrix/backup/. Обсяг зростає безперервно, часто ігнорується при налаштуванні бекапів. - Конфігураційні файли —
/bitrix/.settings.php,/bitrix/php_interface/dbconn.php, конфіги nginx/php-fpm.
Вбудований механізм резервного копіювання
Бітрікс має вбудований інструмент бекапа (/bitrix/admin/backup.php). Він створює архіви в /bitrix/backup/ через агент CBackupAgent. Параметри зберігаються в b_option, модуль main:
-
backup_auto— увімкнути автоматичний бекап -
backup_period— період у годинах -
backup_keep_count— кількість копій, що зберігаються
Вбудований бекап працює, але має обмеження: при великих проєктах (база > 5 ГБ, /upload/ > 20 ГБ) він таймаутиться, займає багато місця на тому ж сервері та не дає реплікації на зовнішні сховища з коробки.
Чому вбудований бекап не підходить для великих проєктів?
При навантаженні понад 1000 замовлень на день база зростає швидко, і повний дамп перестає встигати завершитися за нічне вікно. Крім того, архів зберігається на тому ж диску, що й сайт — при відмові диска ви втрачаєте все. Для production-проєктів ми рекомендуємо відмовитися від вбудованого бекапа на користь зовнішніх інструментів.
Стратегія: три рівні захисту
| Рівень | Технологія | RPO | RTO |
|---|---|---|---|
| 1 — реплікація | PostgreSQL streaming replication / MySQL GTID | секунди | хвилини |
| 2 — снапшоти | pg_dump / pg_basebackup / xtrabackup | до 1 години | 15–30 хв |
| 3 — файловий бекап | Restic / rsync (інкрементальний) | до 24 годин | до 1 години |
Рівень 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 можна гарантувати?
Для типового інтернет-магазину з базою до 10 ГБ і відвідуваністю до 10 000 унікальних відвідувачів на добу ми гарантуємо: RPO не більше 1 хвилини за наявності реплікації, RTO — не більше 30 хвилин. Досягається це за рахунок автоматизованого скрипта відновлення та регулярного тестування. Якщо ваш проєкт більший — рахуємо індивідуально.
Тестування DR — обов'язковий крок
DR без регулярного тестування — хибна впевненість. Раз на квартал: беремо останній бекап, підіймаємо на ізольованому стенді, перевіряємо:
# Перевірка цілісності дампа БД pg_restore --list /backup/site.dump | tail -20 # Перевірка, що сайт підіймається з бекапа # Тест: оформити замовлення, зайти в адміністративну частину Фіксуємо реальний час відновлення. Якщо він перевищує заявлений RTO — оптимізуємо процедуру.
Що входить у налаштування DR
| Етап | Тривалість | Результат |
|---|---|---|
| Аудит поточної інфраструктури | 2–3 дні | Звіт із ризиками та рекомендаціями |
| Проєктування схеми DR | 1 день | Документ з архітектурою |
| Налаштування реплікації та бекапів | 3–5 днів | Працюючі скрипти та моніторинг |
| Тестування відновлення | 1 день | Протокол із вимірами RTO/RPO |
| Передача документації | 1 день | Регламент, скрипти, доступи |
У результаті ви отримуєте: налаштовану реплікацію БД, щогодинні снапшоти, інкрементальний бекап upload, скрипт відновлення з покроковою інструкцією, регламент тестування та алерти при збоях.
Що налаштовуємо
- Streaming replication PostgreSQL/MySQL із моніторингом відставання репліки
- Щогодинний
pg_dumpабоpg_basebackupу зовнішнє сховище - Інкрементальний бекап
/upload/через Restic або rsync із виключеннямresize_cache - Скрипт відновлення із задокументованим порядком дій
- Регламент щоквартального тестування з виміром реального RTO
- Алерти при збої бекапа (відсутність файлу за останні X годин)
Приблизний план тестування DR
Раз на квартал виконуйте повне відновлення на ізольованому стенді. Перевіряйте: цілісність бази, працездатність усіх модулів, коректність завантаження файлів. Протоколюйте фактичний час відновлення та порівнюйте з цільовим RTO.Наш досвід — 10+ років у Бітрікс, понад 50 відновлених проєктів. Гарантуємо, що після налаштування disaster recovery ваш сайт підійматиметься за регламентний час. Зв'яжіться з нами для аудиту вашої поточної схеми бекапів — оцінимо проєкт і запропонуємо оптимальне рішення. Отримайте консультацію з налаштування disaster recovery для вашого 1С-Бітрікс проєкту. Економія від правильно налаштованого DR може вимірюватися мільйонами гривень при аварії.