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

Интернет-магазин на 1С-Битрикс переезжает с общего хостинга на новый сервер: файлы скопировали, базу восстановили — а на старом продолжают оформлять заказы. В итоге часть данных остаётся на прежнем месте. На примере такого переезда разберём, как выбрать способ переноса, проверить копию до переключения домена и не потерять изменения. Сценарий рассчитан на 1С-Битрикс: Управление сайтом 24.x; конкретные требования зависят от редакции, версии PHP и конфигурации сайта.

Сценарий: магазин переезжает, сайт пока работает

Представим типичную ситуацию: сайт доступен покупателям, на нём размещены каталог и заказы, а владелец хочет сменить хостинг. Это условный пример, а не отчёт о реальном проекте: мы не приписываем ему вымышленные объёмы базы или время простоя. Ключевое ограничение — данные меняются во время переноса. Файлы можно скопировать заранее, а вот финальную копию базы нужно согласовать с моментом переключения.

Перед началом уточните на обоих серверах версии PHP и СУБД, доступную память, свободное место, настройки веб-сервера и расширения PHP, необходимые сайту. Сверьте их с требованиями именно вашей версии Битрикс и используемого решения. Также нужны доступы к старому и новому серверу, панели хостинга или SSH, базе данных и DNS. Если на сайте настроены обмен с 1С, почта, платёжные сервисы или внешние интеграции, запишите их адреса и расписание.

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

Три способа переноса и их цена

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

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

Копия считается готовой не тогда, когда архив появился на новом сервере, а когда сайт на копии прошёл проверку, а вы понимаете, как перенесёте последние изменения перед переключением.

План переноса без гонки за последним заказом

1. Снимите исходные параметры. Запишите версии PHP и СУБД, размер базы и каталога сайта, список дополнительных расширений, настройки веб-сервера, задания cron и внешние интеграции. Проверка: вы можете сравнить эти параметры с новым сервером и заранее увидеть несовместимости.
2. Подготовьте новый сервер. Установите подходящее окружение по требованиям вашей версии Битрикс, создайте базу и пользователя с нужными правами, настройте веб-сервер. Не переключайте DNS. Проверка: на сервере доступны нужные версии компонентов, а администратор может подключиться к базе.
3. Создайте первую копию. Выберите штатный архив или раздельное копирование файлов и базы. Переносите данные по защищённому каналу; не отправляйте архив с базой через открытые ссылки. Проверка: на новом сервере есть архив или полный набор файлов, а дамп базы читается и не обрывается посреди таблицы.
4. Восстановите копию на тестовом адресе. Настройте подключение сайта к новой базе и откройте копию по временно назначенному домену или через локальное сопоставление домена. Не публикуйте тестовую копию для поисковых систем и покупателей. Проверка: открываются главная страница, каталог, карточка товара и вход в административную часть.
5. Проведите функциональную проверку. Проверьте создание тестового заказа, почтовые уведомления, загрузку изображений, поиск, обмены и интеграции, которые использует проект. Посмотрите журналы веб-сервера и Битрикс. Проверка: действия завершаются ожидаемо, в журналах нет повторяющихся ошибок, а тестовый заказ появляется в административной части.
6. Согласуйте финальную копию и переключение. Выберите окно, когда покупатели не смогут создавать новые данные на старой версии: например, временно ограничьте оформление заказов. Сделайте финальную копию базы и изменений файлов, восстановите их на новом сервере, затем переключите DNS или другой механизм маршрутизации. Проверка: домен открывает новый сервер, а контрольный заказ и уведомление проходят на нём.
7. Сохраните старый сервер на время контроля. Не удаляйте его сразу. Убедитесь, что DNS обновился у используемых клиентов, фоновые задания работают только в нужном месте, а интеграции не пишут одновременно в две базы. Проверка: в течение согласованного периода новые данные появляются на новом сервере, а старый не принимает изменения.

Что сравнить до переключения

Наличие главной страницы ещё не означает, что магазин переехал. Сравните поведение копии и исходного сайта на важных для бизнеса операциях.

• Каталог: количество контрольных товаров, цены, остатки и изображения.
• Заказ: создание, смена статуса и доставка письма; тестируйте без реального списания денег.
• Администрирование: вход, редактирование товара и сохранение изменений.
• Фоновые задачи: обмен с 1С, отправка почты и запланированные задания. Уточните, где именно они запускаются, чтобы не получить дубли.
• Внешние системы: платёжный шлюз, CRM, аналитика и службы доставки. Проверьте разрешённые адреса, сертификаты и обратные уведомления.

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

Что ломается и когда какой способ выбирать

Архив не создаётся или восстановление обрывается

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

Сайт открывается, но не оформляет заказ

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

После переключения появляются старые товары или пропадают изменения

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

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

Термин: финальная синхронизация

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

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

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