Старый сервер тянет портал на честном слове: диск забит на 95%, MySQL периодически падает по памяти, а хостер прислал письмо о повышении цены в полтора раза. Знакомая ситуация — и рано или поздно встаёт вопрос переноса коробочного Битрикс24 на другой сервер без потери данных: сделок в CRM, истории чатов, файлов в задачах. Ниже — пошаговый план, которым мы пользуемся в проектах: что делать штатными средствами Битрикса, когда штатных средств не хватает, и как не потерять ни одной сделки при переключении домена.
Инструкция для разработчика или системного администратора с доступом по SSH к обоим серверам и правами администратора в самом портале. Годится и для планового переезда на более мощное железо, и для срочного — когда старый сервер сыплется прямо сейчас.
Что понадобится перед началом
- Root-доступ по SSH к старому и новому серверу.
- Права администратора портала (нужны для модуля «Резервное копирование» и для смены адреса сайта в настройках главного модуля).
- Новый сервер, уже настроенный под требования коробочной версии — те же версии PHP, СУБД и веб-сервера, что и на старом, либо на ступень новее. Расхождение версий между серверами — источник половины проблем при переносе, об этом ниже отдельно.
- Доступ к DNS-записям домена портала — понадобится снизить TTL заранее и потом переключить A-запись.
- Свободное место на новом сервере минимум вдвое больше объёма
/bitrix/uploadи дампа базы — на время параллельного хранения старых и новых данных. - Окно для короткого простоя. Даже при аккуратном переносе несколько минут даунтайма на финальной синхронизации будет — портал в это время лучше не трогать.
Перенос коробочного Битрикс24 на другой сервер: два рабочих способа
Официально Битрикс предлагает переносить портал через встроенный модуль «Резервное копирование» (Настройки → Инструменты → Резервное копирование) и скрипт восстановления restore.php. Для небольших порталов — до нескольких гигабайт файлов в /upload — этого достаточно и это самый безопасный путь: минимум ручных операций, встроенная проверка целостности архива. Для порталов на десятки-сотни гигабайт (частая история для активно используемого коробочного Битрикс24 с записями звонков и вложениями в чатах) штатный бэкап через админку становится неудобным — архив собирается часами и грузит диск. Тогда используют второй способ: прямой перенос базы через mysqldump и файлов через rsync, без промежуточного архивирования. Ниже — оба варианта, шаг за шагом.
Шаг 1. Готовим портал и снижаем TTL домена
Перед любыми операциями зайдите в «Настройки» → «Производительность» → «Проверка системы» и убедитесь, что раздел без критичных ошибок — переносить проблему на новый сервер бессмысленно, её проще исправить на месте. Заодно посмотрите список активных агентов (Настройки → Инструменты → Агенты): если какой-то из них штатно выключен для ускорения текущей работы портала, запишите это — после переноса его придётся включить обратно, иначе логи и очереди начнут копиться без чистки.
Домен трогать будем в конце, но TTL DNS-записи (Time To Live — время, на которое DNS-серверы кешируют ответ) нужно снизить заранее, за 24-48 часов. Если сейчас TTL стоит 3600 секунд или выше, поставьте 300. Иначе после переключения A-записи часть пользователей ещё сутки будет попадать на старый сервер по кешированному DNS.
Частая ошибка на этом шаге: снижать TTL в день переезда. К этому моменту он уже должен был отработать заранее — иначе от снижения никакого толку, кеш у провайдеров уже прогрет старым значением.
Шаг 2. Готовим новый сервер под те же версии ПО
Ставите новый сервер так, чтобы версии PHP и MySQL совпадали с исходным сервером или были на ступень новее — не наоборот. Восстановление дампа базы, сделанного на MySQL 8.0, в более старую версию может просто не пройти из-за изменившегося формата системных таблиц. Обратная ситуация — перенос со старого MySQL 5.7 на 8.x — тоже не проходит гладко без плясок с innodb_strict_mode, но хотя бы формально поддерживается.
Проще всего гарантировать совпадение стека — развернуть окружение официальным скриптом настройки Linux-сервера под продукты «1С-Битрикс» на чистой ОС из поддерживаемого списка (Enterprise Linux 9 — AlmaLinux, Rocky, CentOS Stream, Oracle Linux). Он сам подтягивает нужные версии PHP, MySQL, nginx и Apache и следит за их совместимостью между собой — вручную подбирать версии дольше и рискованнее.
Частая ошибка: взять сервер помощнее, но с более старой версией окружения, «потому что так было настроено полгода назад» на шаблоне провайдера. Разница в версии PHP между серверами вылезает не сразу, а через неделю-две, когда на портале случится действие, завязанное на конкретную функцию рантайма.
Шаг 3. Создаём резервную копию (штатный способ)
В админке старого портала: Настройки → Инструменты → Резервное копирование → Создать резервную копию. Выбираете место хранения — локально на сервере, в облако 1С-Битрикс (если есть лицензия с этой опцией) или на стороннее S3-совместимое хранилище через модуль «Облачные хранилища». Для переноса на другой сервер удобнее локальное хранение — потом просто скачаете архив по SSH.
Если данных много, архив разбивается на тома — размер тома ограничен, и на большом портале файлов получается много. На порталах с большим /upload итоговых файлов может получиться пара десятков, это нормально.
# Альтернатива через админку — консольный запуск резервного копирования.
# Полезен для больших порталов: не упирается в таймаут веб-сервера
# и легко ставится в cron на ночное время
php -f /home/bitrix/www/bitrix/modules/main/tools/backup.php
Частая ошибка: запускать создание копии через браузер на портале с большим объёмом файлов и упираться в таймаут PHP или лимит веб-сервера на время выполнения скрипта. Консольный запуск этого ограничения не имеет.
Шаг 4. Переносим архив и восстанавливаем через restore.php
Копируете файлы архива на новый сервер:
# Переносим все тома архива резервной копии на новый сервер по SSH
scp /home/bitrix/www/bitrix/backup/*.tar.gz root@НОВЫЙ_IP:/home/bitrix/www/
На новом сервере в корень сайта кладёте скрипт restore.php (ссылка на скачивание — прямо в админке старого портала, в том же разделе Настройки → Инструменты → Резервное копирование → Список резервных копий), открываете в браузере http://НОВЫЙ_IP/restore.php и проходите мастер: выбор архива, проверка целостности, распаковка файлов, восстановление базы. После завершения — обязательно удалите restore.php и файлы архива с сервера. Это не просто рабочий мусор миграции: незакрытый restore.php на боевом сервере — реальная брешь в безопасности, он даёт возможность запустить процедуру восстановления портала кому угодно, кто найдёт его по URL, а таких проиндексированных файлов на чужих порталах в сети хватает. Удаляйте сразу после успешного переноса, а не «когда будет время».
Важный нюанс, который легко пропустить: если старый и новый сервер имеют одинаковое доменное имя (например, домен ещё не переключили, а новый сервер уже настроен под тот же адрес), скрипт восстановления может попытаться искать архив сам у себя. Работайте на этом этапе по IP-адресу, а не по доменному имени.
Шаг 5. Ручной перенос для больших порталов (альтернатива штатному бэкапу)
Если портал большой и штатный бэкап неудобен, переносите базу и файлы напрямую, без архивации. Дамп базы делаете с флагом транзакционной согласованности — без него на InnoDB-таблицах снимаются блокировки, и портал на время выгрузки подвисает:
# Дамп базы Битрикс24 с сохранением целостности без блокировки таблиц
# sitemanager — типовое имя базы у BitrixEnv; своё смотрите в /bitrix/.settings.php
mysqldump --single-transaction --routines --triggers sitemanager \
| gzip > /backup/b24-$(date +%F).sql.gz
Файлы переносите через rsync — он умеет докачивать только изменения, поэтому первый прогон можно сделать заранее, пока портал ещё работает на старом сервере, а перед переключением домена — досинхронизировать только разницу:
# Первая, "холодная" синхронизация файлов — можно гнать заранее,
# портал в это время продолжает работать на старом сервере
rsync -avz --progress /home/bitrix/www/ root@НОВЫЙ_IP:/home/bitrix/www/
# Финальная досинхронизация непосредственно перед переключением —
# переносит только то, что изменилось с первого прогона
rsync -avz --delete /home/bitrix/www/ root@НОВЫЙ_IP:/home/bitrix/www/
Дамп базы восстанавливаете на новом сервере через mysql, после чего в файле /bitrix/.settings.php проверяете, что реквизиты подключения к базе соответствуют новому серверу (если база поднята на том же хосте под другим паролем — обновите его вручную).
Этот способ быстрее штатного на больших объёмах, но требует аккуратности: он не проверяет целостность данных так, как это делает мастер восстановления, и весь контроль на вас.
Шаг 6. Переключаем домен
Когда данные на новом сервере проверены — портал открывается по IP, логин работает, документы на месте — переключаете A-запись домена на новый IP. TTL уже снижен на шаге 1, поэтому обновление разойдётся быстро, обычно за 5-15 минут, но проверяйте не «на ощупь», а командой:
# Проверяем, что домен уже резолвится в новый IP
nslookup portal.company.ru
Сразу после переключения зайдите в Настройки → Настройки продукта → Настройки модулей → Главный модуль и поправьте там адрес сайта на актуальный домен. Если этого не сделать, ссылки в почтовых уведомлениях и мобильном приложении будут вести на старый адрес или на IP — пользователи будут получать письма с нерабочими ссылками ещё какое-то время.
Шаг 7. Проверяем портал после переноса
Права на файлы — первое, что стоит проверить после rsync или восстановления архива. Веб-сервер и PHP-процессы должны иметь доступ к файлам от имени системного пользователя, под которым работает Битрикс (обычно bitrix):
# Проверяем и, если нужно, восстанавливаем владельца файлов сайта
chown -R bitrix:bitrix /home/bitrix/www
find /home/bitrix/www -type d -exec chmod 755 {} \;
find /home/bitrix/www -type f -exec chmod 644 {} \;
Дальше — агенты. Заходите в Настройки → Инструменты → Агенты и сверяете список с тем, что записали на шаге 1. Особенно важны агенты чистки логов и очередей — если их случайно выключили при переносе и забыли включить, через месяц-два в базе накопятся гигабайты неочищенных логов бизнес-процессов и истории CRM.
Прогоняете «Проверку системы» (Настройки → Производительность) уже на новом сервере — она отдельно показывает состояние push-сервера, прав на директории и версий ПО. Если портал использует мгновенные сообщения и звонки, отдельно проверьте push-сервер: в актуальных инсталляциях (Push Server 2.0 на Node.js) он работает через обычные 80/443 с проксированием через веб-сервер, а не через отдельные порты — если у вас всё ещё легаси-конфигурация на nginx-push-stream-module, там задействованы порты 8893/8894, и вот их на новом сервере действительно легко забыть открыть в файрволе.
Частые ошибки и как их избежать
Восстановление зависает или не находит архив. Чаще всего причина в одинаковом доменном имени на старом и новом сервере на момент восстановления — restore.php путает, откуда брать файл. Решение: работать по IP до переключения домена, а не по доменному имени.
После переноса портал открывается, но CRM работает медленно. Возникает, когда новый сервер по характеристикам слабее старого, а по факту нужен «как минимум такой же», потому что данных за время работы портала прибавилось. Решение: сверять конфигурацию нового сервера не с официальным минимумом, а с реальной нагрузкой — числом активных пользователей и объёмом базы на момент переноса.
Не работают вложения или аватарки после rsync. Обычно это права на файлы — веб-сервер работает от одного пользователя, а файлы после переноса принадлежат root или другому системному пользователю. Решение: chown на пользователя, от которого работает PHP/Apache, сразу после переноса, до первого открытия портала пользователями.
Письма перестали приходить. IP нового сервера свежий, без репутации у почтовых провайдеров — Яндекс и Mail.ru часто заворачивают такую почту в спам или режут на входе. Это не связано напрямую с переносом портала, но вылезает именно после него. Решение: отправлять почту не с самого сервера, а через внешний SMTP, настроенный в главном модуле.
Из практики А2
Один перенос коробки запомнился тем, что на старом сервере стоял MySQL 5.7, а новый разворачивали уже с MySQL 8 — по умолчанию, потому что «а зачем ставить старое». Дамп базы восстановился без единой ошибки, портал открылся, все обрадовались. Проблемы начались через два дня: часть бизнес-процессов с полями, зависящими от строгой типизации InnoDB, стала падать с ошибками, которых на старом сервере не было. Разбирались через innodb_strict_mode — в MySQL 8 он по умолчанию отличается от того, что было в конфигурации на старом сервере, и это нигде явно не всплывает, пока не начнёт всплывать в проде.
Второй момент, который стабильно ловим на переносах с большим /upload — время. Клиент говорит «у нас там немного файлов», а по факту три года истории вложений в чатах и записей звонков дают полтора терабайта. Штатный бэкап через админку на таком объёме просто не имеет смысла — уходит в многочасовое архивирование и забивает диск копией самого себя. В таких случаях сразу идём вторым способом: rsync заранее, пока портал ещё жив на старом сервере, финальная синхронизация — уже в окне простоя, занимает минуты, а не часы.
И третье, куда падает половина клиентов, которые переносят портал сами, без разработчика: агенты. При ручном переносе кто-то на середине процесса отключает агент чистки логов, чтобы дамп базы собирался быстрее, — и забывает включить обратно. Через месяц звонит с вопросом, почему диск на новом сервере снова заполнен, хотя «только что переехали на нормальные мощности». Проверка списка активных агентов сразу после переноса — то немногое, что стоит сделать всегда, даже если на первый взгляд всё работает штатно.
Итог
После этих шагов портал работает на новом сервере с теми же данными, что были на старом: сделками, историей чатов, файлами. Дальше несколько дней стоит понаблюдать за логами и очередями — иногда неочевидные проблемы всплывают не сразу, а на второй-третьей рабочей неделе. Если на каком-то шаге застряли — опишите ситуацию в комментарии или напишите нам напрямую.