Перенос коробочного Битрикс24 на другой сервер

Сначала выбираю способ переноса

Перенос коробочного Битрикс24 можно выполнить несколькими способами, и универсально лучшего варианта нет. Для небольшого портала проще использовать штатную резервную копию и restore.php. На больших порталах основную сложность обычно создаёт каталог upload, а при большой базе данных удобнее переносить её отдельно средствами MySQL через SSH.

Перед началом я оцениваю отдельно три объёма:

размер базы данных;
размер всего сайта без upload;
размер upload.

Также проверяю скорость диска, свободное место на старом и новом сервере, доступную пропускную способность между серверами и допустимое окно простоя.

небольшой портал
→ полный backup Битрикс
→ restore.php

большой upload
→ backup без upload
→ upload через rsync

большая база
→ файлы отдельно
→ mysqldump / MySQL через SSH

крупный портал с коротким окном простоя
→ предварительная синхронизация файлов
→ финальная синхронизация
→ свежая БД
→ переключение

Способ 1: полная резервная копия Битрикс

Для обычного портала самый простой и понятный способ — встроенное резервное копирование Битрикс24. Создаётся полная копия, включающая файлы сайта и базу данных, после чего на новом сервере она восстанавливается через restore.php или мастер BitrixVM.

Последовательность

Проверить исходный портал и убедиться, что он работает до переноса.
Создать свежую резервную копию.
Подготовить новый сервер или BitrixVM.
Передать архив на новый сервер или использовать ссылку на архив.
Запустить restore.php или восстановление из мастера BitrixVM.
Указать параметры новой базы данных.
После восстановления проверить портал.
Удалить restore.php и локальные копии архива с нового сервера.

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

Когда этот способ удобен

портал сравнительно небольшой;
на исходном сервере достаточно свободного места;
backup создаётся без ошибок;
не требуется минимизировать простой до нескольких минут;
нужен максимально штатный и воспроизводимый сценарий.

Почему облачный backup всё равно требует место на диске

Распространённое заблуждение — считать, что при сохранении резервной копии в облако локальное место на сервере не требуется. В действительности Битрикс сначала формирует файл резервной копии локально, проверяет его целостность и только после этого передаёт в облачное хранилище. После успешной отправки локальный файл может быть удалён.

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

Способ 2: upload переносится отдельно

На старых или активно используемых порталах каталог /upload часто занимает большую часть диска: документы, вложения задач, изображения, файлы CRM, записи и другие пользовательские данные.

Архивировать десятки или сотни гигабайт upload через встроенный backup не всегда рационально. Сам Битрикс в документации по резервному копированию из командной строки рекомендует большие каталоги с множеством файлов, например /upload, архивировать отдельно.

Практическая схема

В штатной резервной копии я исключаю upload, а сам каталог переношу напрямую между серверами.

старый сервер
├── backup Битрикс
│   ├── ядро
│   ├── local
│   ├── публичная часть
│   └── база
│
└── upload
    └── rsync → новый сервер

Для передачи удобно использовать rsync через SSH:

rsync -aH --info=progress2 \
  /home/bitrix/www/upload/ \
  root@NEW_SERVER:/home/bitrix/www/upload/

После первой большой передачи можно повторить ту же команду ближе к переключению. rsync передаст только новые и изменённые файлы, поэтому второй проход обычно значительно быстрее первого.

Дозагрузка upload

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

Когда переносить upload отдельно

upload значительно больше остальных файлов сайта;
backup создаётся слишком долго;
не хватает места на исходном сервере для полного архива;
нужно уменьшить время финального простоя;
между серверами доступен быстрый SSH.

Способ 3: база данных через SSH

Базу данных не обязательно переносить внутри штатного архива Битрикс. Для больших баз я часто отделяю её от файлов и использую стандартные инструменты MySQL.

Вариант с промежуточным дампом

mysqldump \
  --single-transaction \
  --quick \
  --routines \
  --triggers \
  DATABASE_NAME \
  | gzip > /tmp/bitrix.sql.gz

После этого файл можно передать:

scp /tmp/bitrix.sql.gz root@NEW_SERVER:/tmp/

и загрузить на новом сервере:

gunzip -c /tmp/bitrix.sql.gz \
  | mysql DATABASE_NAME

Прямая передача без файла дампа

Если свободного места мало, а соединение между серверами стабильное, дамп можно сразу передавать через SSH:

mysqldump \
  --single-transaction \
  --quick \
  DATABASE_NAME \
  | gzip \
  | ssh root@NEW_SERVER \
    'gunzip | mysql DATABASE_NAME'

В этом случае большой SQL-файл не хранится ни на исходном, ни на новом сервере. Минус — при обрыве соединения операцию обычно приходится запускать заново, а отдельного файла дампа для повторного восстановления не остаётся.

Когда я выбираю отдельный перенос базы

база большая и штатный backup работает слишком долго;
нужно отдельно контролировать процесс экспорта и импорта;
на сервере мало места для полного архива сайта;
файлы уже синхронизированы отдельно;
нужно сократить финальное окно переключения.

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

Как уменьшить простой

Если портал большой, основную массу данных можно перенести заранее.

Первый этап — пока production работает

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

Финальное окно

Остановить пользовательские изменения на старом портале.
Остановить или отключить cron и интеграции, которые могут продолжать запись.
Выполнить финальный дамп базы.
Передать и импортировать его на новый сервер.
Повторно запустить rsync upload.
Проверить права файлов.
Запустить новый портал.
Выполнить короткий smoke-test.
Переключить DNS / reverse proxy / внешний IP.

В такой схеме во время простоя передаются уже не все файлы портала, а только накопившаяся разница и актуальная база данных.

Что подготовить на новом сервере

До переноса данных новое окружение должно быть полностью подготовлено. Я проверяю:

подходящую версию BitrixVM / ОС;
PHP и необходимые расширения;
MySQL;
Redis;
Push/RTC;
nginx / Apache;
доступное место на диске;
лимиты PHP;
время и timezone;
SMTP и системную почту;
доступ к внешним сервисам;
резервное копирование уже на новом сервере.

Если перенос одновременно используется для обновления старой коробки, я сначала проверяю совместимость копии портала с новым окружением. Миграция и большое обновление платформы — две разные операции, и по возможности их лучше разделять хотя бы логически и тестировать на копии.

Проверки после переноса

Файлы и база

[ ] Размер upload ожидаемый
[ ] Файлы открываются
[ ] Права и владельцы каталогов корректны
[ ] База импортирована без ошибок
[ ] Кодировка и collation корректны
[ ] Нет старых путей к серверу
[ ] Нет старых параметров подключения к БД

CRM

[ ] Лиды
[ ] Сделки
[ ] Контакты
[ ] Компании
[ ] Реквизиты
[ ] Смарт-процессы
[ ] Таймлайн
[ ] Пользовательские поля
[ ] Поиск

Файлы и документы

[ ] Диск
[ ] Вложения задач
[ ] Файлы CRM
[ ] Документы
[ ] Изображения
[ ] Скачивание файлов
[ ] Превью

Автоматизация

[ ] Роботы
[ ] Бизнес-процессы
[ ] Агенты
[ ] cron
[ ] Собственные обработчики
[ ] Очереди фоновых задач

Коммуникации

[ ] Почта
[ ] Телефония
[ ] Открытые линии
[ ] Мессенджеры
[ ] Push/RTC
[ ] Уведомления

Интеграции

[ ] 1С
[ ] REST
[ ] Webhook
[ ] AD/LDAP
[ ] Внешние API
[ ] callback URL
[ ] белые списки IP

Система

[ ] Проверка системы
[ ] Логи PHP без новых fatal error
[ ] nginx / Apache без критических ошибок
[ ] Redis работает
[ ] cron работает
[ ] место на диске контролируется
[ ] backup нового сервера настроен

Что важно не забыть

Не переносить старые резервные копии без необходимости

Каталог /bitrix/backup может занимать десятки или сотни гигабайт. Старые backup обычно не нужны на новом production-сервере. Их лучше хранить отдельно.

Сохранить старый сервер до окончания проверки

Я не удаляю и не переиспользую старый сервер сразу после переключения. Несколько дней он остаётся выключенным или закрытым от пользователей как дополнительная точка отката.

Учитывать изменение IP

После переезда могут потребовать изменения белые списки у внешних API, телефонии, банковских сервисов, 1С, VPN и других интеграций.

Проверить DNS заранее

Если переключение будет выполняться через DNS, TTL лучше уменьшить заранее. Это сокращает период, когда часть пользователей ещё попадает на старый сервер.

Не забывать про исходящие задачи старого сервера

После переключения старый портал не должен продолжать выполнять cron, отправлять почту или обращаться к интеграциям. Иначе какое-то время два портала могут одновременно выполнять одну и ту же работу.

После миграции нужен новый backup

Первую резервную копию на новом сервере я создаю после успешного функционального теста. Это уже контрольная точка новой инфраструктуры.