Резервная копия Битрикс: как снять и проверить за вечер

План на вечер: снять полный архив сайта на 1С-Битрикс (база плюс файлы), скачать его к себе и развернуть на тестовом домене, чтобы убедиться, что копия живая. На сайте в пару гигабайт это 30–60 минут, из которых активной работы минут пятнадцать, остальное — ожидание архиватора и загрузки. Инструкция проверялась на 1С-Битрикс: Управление сайтом с ядром main 22.x и новее, PHP 8.x, MySQL 8.0 или MariaDB 10.x. Названия пунктов меню между версиями почти не менялись, но если ваш интерфейс отличается, ориентируйтесь на смысл поля, а не на точную формулировку.

Что нужно до начала

Самая частая причина брошенного на середине бэкапа — выясняется, что не хватает места или прав. Проверьте всё сразу:

• доступ в админку с правами администратора (группа «Администраторы»);
• свободное место на диске: минимум сумма размера файлов сайта и размера базы, с запасом процентов тридцать. Архив сначала собирается рядом с сайтом;
• SSH или хотя бы файловый менеджер хостинга, чтобы забрать архив и посмотреть логи, если что-то упадёт;
• доступ к базе данных: имя, пользователь, пароль. Они лежат в /bitrix/.settings.php, в старых сборках — ещё и в /bitrix/php_interface/dbconn.php;
• место, куда архив ляжет после скачивания: ваш компьютер, внешний диск, объектное хранилище — что угодно вне этого сервера;
• менеджер паролей, если будете ставить пароль на архив. Забытый пароль означает, что архива у вас нет.

Форма резервного копирования предлагает несколько параметров. Вот что в них ставить для полной переносимой копии:

Шесть шагов через админку

1. Проверьте систему. Настройки → Инструменты → Проверка системы, запустите тестирование. Смысл простой: не архивировать уже сломанное. Проверка: в отчёте нет красных строк по правам на запись и по подключению к базе. Красное по правам почините до бэкапа, иначе архив соберётся неполным.
2. Посмотрите, сколько места есть. В консоли: du -sh . в корне сайта и df -h по диску. Проверка: свободного места больше, чем размер сайта вместе с базой.
3. Сбросьте кеш. Настройки → Настройки продукта → Автокеширование, кнопка очистки файлов кеша. Проверка: папка bitrix/cache заметно уменьшилась или опустела.
4. Запустите копирование. Настройки → Инструменты → Резервное копирование, заполните параметры по таблице выше, нажмите создание копии. Архиватор работает шагами и показывает прогресс — страницу не закрывайте. Проверка: в конце в списке резервных копий появляется запись с датой, размером и числом частей.
5. Скачайте все части. Не одну, а все: архив из трёх частей без второй части бесполезен. Проверка: сумма размеров скачанных файлов совпадает с размером копии в админке, а tar -tzf имя_архива.tar.gz | head выводит список файлов без ошибок.
6. Положите рядом паспорт копии. Обычный txt: дата, версия ядра (Настройки → Обновление платформы), версия PHP и MySQL, имя базы, пароль на архив — в менеджере паролей, а не в этом файле. Проверка: через полгода по этому файлу понятно, на какое окружение копию можно развернуть.

Где хранить и сколько держать

Архив в /bitrix/backup/ — это не резервная копия, а промежуточный файл. Сервер умирает вместе с ним, шифровальщик добирается до него первым, а при переполнении диска сайт ляжет как раз из-за него. Минимальная рабочая схема: свежая копия на сервере, вторая у вас локально, третья в другом месте — облачное хранилище или домашний диск. Старые части удаляйте из /bitrix/backup/ вручную, они не чистятся сами.

Копия, которую вы ни разу не разворачивали, — это не резервная копия, а файл неизвестного содержания.

Если сайт большой: копия из консоли

Встроенный архиватор рассчитан на сайты в единицы гигабайт. На десятках гигабайт он чаще упирается в таймаут веб-сервера, чем доходит до конца. Тогда делайте то же самое двумя командами по SSH. Пароль в командной строке не пишем — он уходит в историю оболочки и виден в списке процессов. Создайте файл ~/.mysql-backup.cnf с правами 600:

[client]
user=YOUR_DB_USER
password=YOUR_DB_PASSWORD

Дамп базы (MySQL 8.0 / MariaDB 10.x). Опция с файлом настроек идёт первой — иначе mysqldump её не примет:

mkdir -p ~/backup
# --single-transaction снимает согласованный дамп InnoDB без блокировки сайта
mysqldump --defaults-extra-file=$HOME/.mysql-backup.cnf \
  --single-transaction --quick --default-character-set=utf8mb4 \
  --routines --events \
  YOUR_DB_NAME | gzip > ~/backup/db_$(date +%F).sql.gz

Проверка: gunzip -t ~/backup/db_*.sql.gz завершается без вывода, а размер файла не нулевой.

Теперь файлы. Запускайте из корня сайта, путь подставьте свой:

cd /home/bitrix/www
tar -czf ~/backup/files_$(date +%F).tar.gz \
  --exclude='./bitrix/cache' \
  --exclude='./bitrix/managed_cache' \
  --exclude='./bitrix/stack_cache' \
  --exclude='./bitrix/backup' \
  --exclude='./upload/resize_cache' \
  .

Проверка: tar -tzf ~/backup/files_*.tar.gz | grep -c 'bitrix/modules' возвращает число больше нуля — ядро в архив попало. И отдельно убедитесь, что внутри есть .htaccess и bitrix/.settings.php: без них сайт на новом месте не поднимется.

Проверка: развернуть копию на тестовом домене

1. Завести поддомен или отдельный аккаунт на хостинге и пустую базу данных под тест.
2. Положить в пустой корень скрипт восстановления restore.php со страницы загрузок 1С-Битрикс, рядом — части архива (или указать скрипту ссылку на архив). Корень должен быть именно пустым: скрипт распаковывает файлы поверх.
3. Открыть restore.php в браузере, дождаться распаковки и ввести параметры тестовой базы.
4. Удалить restore.php и распакованные части архива, зайти в /bitrix/admin/, прогнать Проверку системы и сбросить кеш. Проверка: админка открывается, главная отдаёт 200, товары и картинки на месте.
5. Сразу после подъёма тестовой копии закрыть её от индексации и отключить всё, что умеет писать наружу: отправку писем покупателям, обмен с 1С, боевые платёжные ключи. Тестовая копия, рассылающая реальные письма клиентам, — отдельный способ испортить вечер.

Если не получилось

• Allowed memory size of ... bytes exhausted — архиватору не хватило памяти PHP. Поднимите memory_limit для сайта (256–512 МБ), уменьшите размер части архива и повторите.
• Maximum execution time of 30 seconds exceeded или 504 Gateway Time-out — шаг не успел завершиться. Увеличьте max_execution_time и таймауты веб-сервера либо переходите на консольный вариант из раздела выше.
• Сообщение о невозможности записи в папку архивов — у веб-сервера нет прав на /bitrix/backup/. Проверьте владельца и права каталога, на «Битрикс-окружении» файлы сайта обычно принадлежат пользователю bitrix.
• Процесс падает, а на диске кончилось место — архив собирается рядом с сайтом и удваивает занятый объём. Удалите старые части из /bitrix/backup/, исключите upload/resize_cache и каталоги кеша, при необходимости снимите базу и файлы отдельными копиями.
• На восстановлении — Access denied for user или ошибка подключения к базе — неверные параметры тестовой базы или у пользователя нет прав на неё. Выдайте пользователю полные права на базу и повторите шаг ввода параметров, архив распаковывать заново не нужно.

Что делать дальше

• Поставить регулярность: ночной дамп базы по cron каждый день, полная копия файлов — раз в неделю. Рост интернет-магазина идёт в основном по базе, а не по ядру.
• Завести календарное напоминание раз в квартал: развернуть свежую копию на тесте. Это единственная проверка, которая что-то значит.
• Мерить два числа: размер последнего архива и время его создания. Резкий скачок размера обычно означает мусор в upload, а растущее время — что скоро упрётесь в таймаут.
• Отдельно сохранить то, чего нет в архиве: лицензионный ключ, доступы к хостингу и домену, конфиги Nginx и PHP, задания cron. Смежная тема — перенос сайта на другой хостинг, там к этому списку добавляются DNS и почта.

Дамп базы — текстовый файл с набором SQL-команд, которые заново создают таблицы и заливают данные. Multipart-архив — архив, нарезанный на части фиксированного размера: восстановление требует всех частей по порядку, пропуск одной делает архив нечитаемым.