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

Перенос сайта на 1С-Битрикс на новый сервер можно выполнить за один вечер, если заранее подготовить доступы и сократить время переключения DNS. В результате на новом хостинге должны открываться сайт и административная панель, сохраняться заказы и пользователи, а фоновые задания и отправка почты работать так же, как раньше.

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

Инструкция подходит для 1С-Битрикс: Управление сайтом в актуальных ветках 24.x–25.x. Перед началом сверяйте системные требования именно вашей редакции: версия PHP, поддерживаемые СУБД, обязательные расширения и лимиты могут меняться.

• доступ по SSH к старому и новому серверу либо доступ к панели хостинга;
• доступ к базе данных: имя базы, пользователь и пароль;
• копия текущего файла конфигурации веб-сервера и список PHP-расширений;
• доступ к DNS и сертификату HTTPS;
• свободное место на новом сервере минимум размером с файлы сайта плюс размер дампа базы;
• окно для финальной синхронизации, когда новые заказы и изменения на старом сайте не потеряются.

Проверьте версии и расширения на старом сервере. Команды не меняют сайт и подходят для обычного Linux-сервера:

php -v
php -m

Сохраните вывод команд. На новом сервере PHP должен соответствовать требованиям вашей версии Битрикс, а среди расширений должны быть как минимум те, которые использует текущая установка. Проверка успешна, если версии и список критичных модулей сопоставлены, а не просто установлен «самый свежий» PHP.

Сноска. Дамп — файл с SQL-командами для восстановления структуры и данных базы данных. Он не заменяет резервную копию файлов сайта.

Пошаговый перенос

1. Включите режим обслуживания

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

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

2. Сделайте резервную копию базы

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

   mysqldump --single-transaction --routines --triggers --events --default-character-set=utf8mb4 -u bitrix_db -p bitrix_db > /root/bitrix.sql
   ls -lh /root/bitrix.sql
   

   После запуска система попросит пароль интерактивно. Параметр --single-transaction обычно позволяет снять согласованный дамп без длительной блокировки таблиц InnoDB. Проверка: файл /root/bitrix.sql существует и не имеет нулевой размер.

3. Скопируйте файлы сайта

   Перед копированием узнайте фактический корень сайта. Это может быть каталог вроде /var/www/site, но на хостинге путь часто отличается. Пример передачи по SSH:

   rsync -aHAX --info=progress2 /var/www/site/ root@NEW_SERVER:/var/www/site/
   

   Скопируйте весь каталог, включая скрытые файлы: конфигурацию веб-сервера обычно хранят отдельно, но файлы .settings.php, dbconn.php, .htaccess и пользовательские загрузки нужны сайту. Не переносите только папку bitrix: заказы, картинки и настройки могут находиться в других каталогах.

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

4. Создайте базу и восстановите дамп

   На новом сервере создайте пустую базу данных с кодировкой UTF-8 и пользователя с правами на эту базу. Точные действия зависят от MySQL или MariaDB и панели управления, поэтому не копируйте команды создания пользователя между серверами без проверки версии.

   Затем передайте дамп и восстановите его:

   scp /root/bitrix.sql root@NEW_SERVER:/root/bitrix.sql
   mysql -u bitrix_db -p bitrix_db < /root/bitrix.sql
   

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

5. Привяжите конфигурацию к новой базе

   В новых редакциях параметры подключения обычно находятся в bitrix/.settings.php, в старых установках может использоваться bitrix/php_interface/dbconn.php. Не создавайте файл с нуля: найдите существующий и замените только имя базы, пользователя, адрес сервера и другие параметры подключения, если они отличаются.

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

6. Настройте веб-сервер, PHP и права

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

   Владелец файлов должен совпадать с пользователем, от имени которого работает PHP-FPM или другой обработчик PHP. Не выдавайте всему каталогу права 777: это маскирует ошибку владельца и открывает лишние возможности для записи.

   nginx -t
   systemctl reload nginx
   

   Названия сервиса PHP-FPM зависят от дистрибутива и установленной версии PHP, поэтому не запускайте случайную команду перезапуска. Проверка: проверка конфигурации Nginx завершается успешно, а домен открывает именно каталог нового сервера.

7. Проверьте сайт до переключения DNS

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

   • вход в административную панель;
   • карточку товара и поиск;
   • создание тестового заказа;
   • загрузку изображения и файла;
   • форму обратной связи и отправку письма;
   • страницы с ЧПУ, редиректы и robots.txt;
   • интеграции с оплатой, CRM, телефонией и службами доставки.

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

8. Синхронизируйте изменения и переключите домен

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

   После восстановления проверьте настройки домена, HTTPS, почты и фоновых заданий. Затем измените DNS-запись на IP нового сервера. Проверка: после обновления DNS сайт открывается с нового IP, а новые заказы не появляются на старой базе.

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

«Access denied for user» или «Access denied for ...»

Проверьте имя базы, пользователя, пароль и разрешённый адрес подключения. Пользователь базы может иметь права только для localhost, а PHP на новом сервере подключается иначе. Исправьте права в панели или в СУБД и повторите подключение.

«Unknown database»

База на новом сервере не создана, названа иначе или в конфигурации сайта указано старое имя. Сверьте имя в .settings.php или dbconn.php с фактическим именем базы.

«500 Internal Server Error»

Смотрите журнал PHP-FPM и веб-сервера, а не только страницу ошибки. Частые причины — несовместимая версия PHP, отсутствующее расширение, неправильный владелец файлов или ошибка в конфигурации после ручной правки.

Сайт открывается, но картинки и ЧПУ не работают

Проверьте права на каталоги загрузок, правила .htaccess или конфигурацию Nginx и корректность корня сайта. Если главная страница работает, это ещё не означает, что веб-сервер применяет правила маршрутизации Битрикс.

Заказы есть, но письма не уходят

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

Что проверить после переезда

Оставьте старый сервер доступным хотя бы на короткий период, но запретите запись новых данных после переключения. Это позволит быстро сравнить журналы и вернуть DNS, если обнаружится критическая ошибка. Старый сервер нельзя использовать как параллельную рабочую копию без синхронизации: пользователи начнут записываться в две разные базы.

• настройте и запустите cron-задачи Битрикс по расписанию проекта;
• проверьте агенты, очереди, обмен с 1С и фоновые импорты;
• убедитесь, что резервное копирование создаётся уже на новом сервере;
• поставьте мониторинг HTTP-кода, времени ответа, места на диске и ошибок PHP;
• через несколько часов сравните новые заказы, платежи и письма с журналами интеграций.

Следующий практический шаг — выполнить тестовое восстановление свежего дампа на отдельном стенде. Такой тест показывает, действительно ли резервная копия пригодна для аварийного возврата, а не просто успешно создаётся.