Настройка резервного копирования 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 рабочих дня: аудит текущей ситуации, настройка кронтабов, настройка удалённого хранилища, тестирование.