Налаштування резервного копіювання 1С-Бітрікс
Налаштування резервного копіювання 1С-Бітрікс
Резервна копія, про яку згадують лише в момент аварії, — це не резервна копія. Це ілюзія безпеки. У 1С-Бітрікс є кілька механізмів створення резервних копій, і вибір між ними безпосередньо впливає на те, за скільки часу ви відновите сайт після падіння сервера.
Вбудовані інструменти резервного копіювання
Модуль резервного копіювання (bitrix.backup). Штатний інструмент платформи. Створює архів сайту (файли + дамп бази даних) у папці /bitrix/backup/. Запускається вручну або за розкладом через агенти (CAgent).
Обмеження вбудованого модуля:
- Архів зберігається на тому ж сервері, що й сайт. При відмові диска втрачається все.
- На великих сайтах (від 10–20 ГБ) процес архівування може перериватися через timeout PHP або обмеження пам'яті.
- Немає вбудованої ротації — потрібно налаштовувати вручну або через агент очищення.
Резервне копіювання через BitrixEnv/BitrixVM. Якщо сервер розгорнуто на офіційному образі BitrixEnv, доступний скрипт /root/restore.sh і можливість налаштування через меню menu.sh. Цей варіант працює на рівні ОС, не залежить від обмежень PHP.
Правильна архітектура бекапів
Надійна схема резервного копіювання будується на правилі 3-2-1:
- 3 копії даних
- 2 різних носіїв/сховища
- 1 копія offsite (за межами основного сервера)
Для Бітрікс-сайтів це реалізується так:
Рівень 1 — локальний бекап. Щоденний дамп бази через mysqldump + архів /bitrix/, /upload/, призначених користувачем папок. Зберігання: 7 днів на сервері.
Рівень 2 — віддалене сховище. Синхронізація архівів на S3-сумісне сховище (Яндекс Object Storage, AWS S3, Selectel). Через s3cmd, rclone або AWS CLI, що запускається кронтабом після створення локального архіву.
Рівень 3 — снапшоти сервера. Якщо хостинг підтримує снапшоти VM (Yandex Cloud, Hetzner, DigitalOcean) — щоденні снапшоти всього диска. Це швидке відновлення при системній аварії.
Налаштування кронтабу для бекапів
Приклад мінімального cron-скрипту для сервера на BitrixEnv:
# Дамп бази даних
0 3 * * * mysqldump -u bitrix -p'pass' sitedb | gzip > /home/bitrix/backup/db_$(date +\%Y\%m\%d).sql.gz
# Архів файлів сайту (без кешу і логів)
30 3 * * * tar -czf /home/bitrix/backup/files_$(date +\%Y\%m\%d).tar.gz \
--exclude='/home/bitrix/www/bitrix/cache' \
--exclude='/home/bitrix/www/bitrix/managed_cache' \
--exclude='/home/bitrix/www/bitrix/stack_cache' \
/home/bitrix/www/
# Відправка в S3
0 5 * * * rclone sync /home/bitrix/backup/ s3remote:bucket-name/backups/
# Видалення локальних копій старше 7 днів
0 6 * * * find /home/bitrix/backup/ -name "*.gz" -mtime +7 -delete
Важливо: виключати з архіву файлів директорії кешу (/bitrix/cache/, /bitrix/managed_cache/, /bitrix/stack_cache/). Вони можуть займати гігабайти і абсолютно не потрібні в бекапі — кеш відновлюється сам.
Перевірка цілісності бекапів
Створити бекап — половина роботи. Друга половина — переконатися, що він відновлюється. Мінімум раз на місяць: розгортаємо архів на тестовому сервері, перевіряємо доступність сайту і коректність даних.
Автоматизувати перевірку можна через скрипт, який розгортає останній бекап у тестове оточення і робить HTTP-запит до головної сторінки — якщо код відповіді не 200, відправляє алерт.
Терміни і склад роботи
Налаштування резервного копіювання з ротацією, вивантаженням в S3 і базовою перевіркою цілісності — 1–2 робочих дні: аудит поточної ситуації, налаштування кронтабів, налаштування віддаленого сховища, тестування.