Налаштування резервного копіювання 1С-Бітрікс під ключ
Резервна копія, про яку згадують лише в момент аварії — це не резервна копія. У нашій практиці кожен другий проект приходить уже після збою з втратою даних. Наприклад, нещодавно клієнт втратив каталог із 10 000 товарів через збій RAID-масиву — відновити вдалося тільки через тиждень, і то не повністю. Ми налаштовуємо резервне копіювання 1С-Бітрікс під ключ, щоб ви спали спокійно. Правильна архітектура бекапу — це не просто скрипт, а система, що гарантує відновлення за годину. Зв'яжіться з нами — обговоримо вашу інфраструктуру та підберемо оптимальну схему.
1С-Бітрікс пропонує кілька механізмів створення резервних копій. Їх грамотне комбінування з правилом 3-2-1 (три копії на двох носіях, одна офлайн) дає максимальну надійність. Розглянемо кожен рівень і як їх налаштувати.
Вбудовані інструменти та їх обмеження
Модуль резервного копіювання (bitrix.backup). Штатний інструмент створює архів сайту (файли + дамп бази) у папці /bitrix/backup/. Запускається вручну або за розкладом через агенти CAgent.
Обмеження:
- Архів на тому ж сервері — при відмові диска все втрачається.
- На великих сайтах (від 10–20 ГБ) процес може перериватися через таймаут PHP.
- Немає вбудованої ротації — потрібне ручне налаштування.
BitrixEnv/BitrixVM. На офіційному образі доступний скрипт /root/restore.sh і налаштування через menu.sh. Це працює на рівні ОС і не залежить від PHP.
Чому правило 3-2-1 критичне для Бітрікса?
Правило 3-2-1 — стандарт індустрії. Для Бітрікс-сайтів реалізується так:
Рівень 1 — локальний бекап. Щоденний дамп бази через mysqldump + архів /bitrix/, /upload/, користувацьких папок. Зберігання: 7 днів на сервері.
Рівень 2 — віддалене сховище. Синхронізація архівів на S3-сумісне сховище (Яндекс Object Storage, AWS S3, Selectel) через rclone або s3cmd, що запускаються cron.
Рівень 3 — снапшоти сервера. Якщо хостинг підтримує снапшоти VM (Yandex Cloud, Hetzner, DigitalOcean) — щодобові снапшоти всього диска. Це дає відновлення за хвилини при системній аварії.
| Метод | Час відновлення | Вартість | Надійність |
|---|---|---|---|
| Тільки вбудований модуль | Від 4 годин | Безкоштовно (входить у ліцензію) | Низька (один диск) |
| Локальний + S3 | 1–2 години | рассчитывается индивидуально | Висока (два носії) |
| Локальний + S3 + снапшоти | 10–30 хвилин | рассчитывается индивидуально | Максимальна (3 копії) |
Порівняння показує: комбінація локального бекапу з S3 і снапшотами в 5 разів швидше відновлює сайт, ніж тільки вбудований модуль.
Типові помилки при налаштуванні бекапів та їх вирішення
| Помилка | Наслідки | Вирішення |
|---|---|---|
| Бекап на тому ж диску | Втрата при збої диска | Зберігати копії на різних носіях |
| Виключення кешу не налаштоване | Архів роздутий у 2-3 рази | Додати виключення в tar |
| Відсутність перевірки бекапів | Відновити не вдається | Щомісячний тест на тестовому сервері |
Як перевірити працездатність бекапу?
Створити бекап — половина роботи. Друга — переконатися, що він відновлюється. Щонайменше раз на місяць розгортайте архів на тестовому сервері та перевіряйте доступність сайту.
Автоматизуйте перевірку через скрипт, який завантажує останній бекап у тестове середовище та робить HTTP-запит до головної сторінки. Якщо код відповіді не 200 — надсилайте алерт у Telegram або Slack.
Налаштування cron для бекапів
Приклад мінімального 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/. Вони займають гігабайти і не потрібні в бекапі — кеш відновлюється автоматично.
Що входить у налаштування під ключ
Ми пропонуємо комплексну послугу, яка включає:
- Аудит поточної схеми резервного копіювання та інфраструктури.
- Проектування архітектури за правилом 3-2-1.
- Налаштування cron-скриптів для локальних бекапів.
- Підключення віддаленого S3-сховища та налаштування синхронізації.
- Налаштування снапшотів (якщо хостинг підтримує).
- Тестування відновлення: розгортання бекапу на тестовому сервері з перевіркою 200-відповіді.
- Документацію щодо процедури відновлення.
- Гарантію працездатності схеми протягом 30 днів.
Досвід наших спеціалістів — понад 10 років роботи з Бітріксом, понад 100 реалізованих бекап-рішень. Ми знаємо типові помилки та вміємо їх уникати.
Що робити, якщо відновлення не вдається?
Якщо після розгортання бекапу сайт не відкривається, перевірте права доступу до файлів і папок, а також коректність дампа бази даних. Найчастіше проблема в неповному архіві або невідповідності версій PHP. Ми налаштовуємо так, що процес відновлення проходить без сюрпризів. Замовте налаштування під ключ — отримайте готову схему з документацією.
Строки та як замовити
Налаштування резервного копіювання з ротацією, вивантаженням у S3 та базовою перевіркою цілісності займає 1–2 робочих дні. Зв'яжіться з нами — ми оцінимо ваш проект і запропонуємо оптимальне рішення. Отримайте консультацію без зобов'язань.
Джерело: Wikipedia — Backup rotation scheme