Налаштування резервного копіювання Бітрікс24 On-Premise
Резервне копіювання — єдине, що встане між вами і катастрофою, коли диск помре або хтось випадково видалить 10 000 клієнтських записів. У практиці On-Premise-адміністрування саме «у нас є бекап» відрізняє серйозні компанії від тих, хто відновлює дані за гроші або не відновлює взагалі.
Що потрібно бекапити
Бітрікс24 On-Premise складається з кількох компонентів, кожен із яких вимагає окремої стратегії:
| Компонент | Розташування | Метод | Частота |
|---|---|---|---|
| База даних | MySQL/MariaDB | mysqldump / Percona XtraBackup | Щогодини (інкремент) / раз на добу (повний) |
| Файли сайту | /home/bitrix/www |
rsync / tar | Раз на добу |
| Завантажені файли | /home/bitrix/www/upload |
rsync | Кожні 4 години |
| Конфігурація | nginx, php.ini, .env | git або rsync | При змінах |
| Диск Бітрікс24 | /home/bitrix/www/bitrix/managed_cache + upload |
rsync | Раз на добу |
Налаштування вбудованого бекапу
Бітрікс24 має вбудований модуль резервного копіювання: Налаштування → Резервне копіювання. Він створює архіви файлів і дамп БД, але має критичні обмеження:
- Повільніше за професійні інструменти (mysqldump через PHP)
- Створює архів на тому самому диску — при відмові диска втрачається разом із даними
- Немає інкрементального копіювання — кожного разу повний бекап
Для production вбудований бекап використовуйте лише як доповнення, а не як основу.
Професійне налаштування через cron
База даних із Percona XtraBackup (для баз >10 ГБ):
#!/bin/bash
# /usr/local/bin/bitrix-backup-db.sh
BACKUP_DIR="/backup/bitrix/db"
DATE=$(date +%Y%m%d_%H%M)
# Повний бекап щонеділі
if [ $(date +%u) -eq 7 ]; then
xtrabackup --backup --target-dir=$BACKUP_DIR/full_$DATE \
--user=bitrix --password=$DB_PASS
else
# Інкрементальний бекап в інші дні
xtrabackup --backup --target-dir=$BACKUP_DIR/inc_$DATE \
--incremental-basedir=$BACKUP_DIR/latest_full \
--user=bitrix --password=$DB_PASS
fi
Файли через rsync із ротацією:
#!/bin/bash
# Щоденний бекап файлів із зберіганням 30 днів
rsync -avz --delete \
/home/bitrix/www/upload/ \
backup-server:/backups/bitrix-upload/$(date +%Y%m%d)/
# Видалення бекапів старших за 30 днів
find /backups/bitrix-upload/ -maxdepth 1 -type d -mtime +30 -exec rm -rf {} \;
Зовнішнє сховище бекапів
Бекап на тому самому сервері — не бекап. Налаштуйте реплікацію на зовнішні сховища:
Варіант 1: S3-сумісне сховище (AWS S3, Wasabi, Backblaze B2):
aws s3 sync /backup/bitrix/ s3://your-bucket/bitrix-backups/ \
--endpoint-url https://s3.amazonaws.com
Варіант 2: Offsite-сервер по rsync/SSH: налаштуйте SSH-ключі та автоматичну синхронізацію в cron на резервний сервер в іншому датацентрі.
Варіант 3: NAS у локальній мережі як проміжне сховище + реплікація в хмару.
Тестування відновлення
Бекап, який ніколи не тестувався на відновлення, — це ілюзія безпеки. Мінімум раз на квартал проводьте навчання:
- Розгорніть тестовий сервер
- Відновіть останній бекап БД:
xtrabackup --prepare && xtrabackup --copy-back - Відновіть файли
- Перевірте працездатність: авторизація, відкриття CRM, перевірка останніх записів
- Зафіксуйте час відновлення (RTO) — для більшості клієнтів прийнятно 2–4 години
Цільові показники для On-Premise Бітрікс24:
- RPO (допустима втрата даних): не більше 1 години → погодинні інкрементальні бекапи БД
- RTO (час відновлення): не більше 4 годин → задокументована процедура, протестована заздалегідь
Якщо бекап не тестувався — він не працює. Це аксіома.