Резервная копия 1С-Битрикс: что должно быть в рабочем бэкапе

Резервная копия 1С-Битрикс должна позволять восстановить сайт, а не просто создавать ощущение безопасности. Для Битрикс-сайта мало сохранить только базу или только файлы. Нужны база, upload, local, настройки подключения, обработчики, cron, информация о PHP и понимание порядка восстановления.

Проверенный бэкап особенно важен перед обновлениями, переносом, изменением обмена с 1С и крупными правками каталога.

Что обязательно сохранять

Минимальный набор для восстановления:

• дамп базы данных;
• папка upload;
• папка local;
• bitrix/php_interface;
• bitrix/.settings.php;
• bitrix/php_interface/dbconn.php, если используется;
• шаблоны сайта;
• cron-задачи;
• информация о версии PHP и расширениях.

Папку bitrix целиком часто тоже сохраняют, особенно перед обновлениями. Но для регулярных копий нужно учитывать размер и способ восстановления.

Дамп базы

Для MySQL или MariaDB можно использовать mysqldump. Для InnoDB обычно применяют --single-transaction, чтобы сделать копию без длительной блокировки таблиц.

mysqldump --single-transaction --routines --triggers \
    -u user -p database | gzip > bitrix-db.sql.gz

После создания нужно проверить, что файл не пустой.

ls -lh bitrix-db.sql.gz

Файлы сайта

upload содержит пользовательские файлы: изображения, документы, файлы инфоблоков, картинки товаров. Потеря upload часто критичнее потери кода, потому что код можно восстановить из репозитория, а загруженные файлы — только из копии.

tar -czf bitrix-files.tar.gz upload local bitrix/php_interface bitrix/.settings.php

Если upload большой, для регулярного копирования удобнее rsync.

rsync -av upload/ backup@example:/backups/site/upload/

Конфиги и секреты

Файлы настроек могут содержать пароли базы, ключи, параметры подключения к сервисам. Их нужно сохранять, но хранить в защищённом месте.

Не стоит класть архив с конфигами в публичную директорию сайта. Файлы backup.zip, dump.sql и site.tar.gz в корне сайта — типовая опасная ошибка.

Cron и агенты

Если агенты, обмены или рассылки запускаются через cron, нужно сохранить расписание.

crontab -l > crontab.txt

Также полезно сохранить список systemd-сервисов или supervisor-конфиги, если они используются.

Проверка восстановления

Бэкап считается рабочим только после тестового восстановления. Хотя бы периодически нужно разворачивать копию на тестовом домене или локальном сервере.

1. Создать новую базу.
2. Импортировать дамп.
3. Развернуть файлы.
4. Настроить подключение к базе.
5. Проверить права на upload и cache.
6. Открыть сайт и админку.
7. Проверить изображения из upload.
8. Проверить форму и почтовое событие.

gunzip < bitrix-db.sql.gz | mysql -u user -p database

Права после восстановления

После распаковки архива от root сайт может потерять права на запись. Нужно проверить upload, cache, managed_cache, stack_cache и html_pages.

ls -la upload
ls -la bitrix/cache
ls -la bitrix/managed_cache

Настройка зависит от пользователя веб-сервера, но смысл один: Битрикс должен писать в рабочие директории, а архивы не должны быть доступны публично.

Где хранить копии

Хранить единственный бэкап на том же сервере недостаточно. Если сервер недоступен, копия тоже недоступна. Лучше иметь внешнее хранилище: отдельный сервер, объектное хранилище или защищённый облачный диск.

• ежедневные копии за несколько последних дней;
• еженедельные копии за месяц;
• отдельная копия перед обновлениями;
• проверка восстановления по расписанию.

Чек-лист

1. Сохраняется база данных.
2. Сохраняется upload.
3. Сохраняются local и php_interface.
4. Сохраняются .settings.php и dbconn.php.
5. Сохраняется crontab.
6. Копия хранится вне основного сервера.
7. Архивы не лежат в публичной директории.
8. Проверено восстановление на тестовой копии.

Хороший бэкап Битрикс-сайта — это не только архив. Это понятный комплект данных и проверенный порядок восстановления. Без проверки даже большой архив может оказаться бесполезным в момент аварии.