Перенос Битрикс-проекта между серверами

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

Главный риск: перепутать контуры и базы

Проект — это не один сайт, а несколько сред: боевой продакшен, тестовые стенды, ветки разработки. У каждой свои файлы, своя база и своё окружение. Самая частая и самая дорогая ошибка при переносе — смешать контуры: подключить боевой сайт к тестовой базе, развернуть стенд поверх продакшена или потерять разделение, из-за которого разработка начинает писать в боевые данные. Мы исключаем это с самого начала. На аудите мы фиксируем карту контуров: что где лежит, к какой базе подключено, какие связи и зависимости есть между средами. Каждый контур переносится отдельно, со своей базой и своим окружением. Перед запуском мы проверяем подключения построчно: продакшен смотрит в боевую базу, stage — в свою, dev — в свою. Путаницы быть не может, потому что мы её не допускаем по процессу, а не надеемся на внимательность.

Проблема вторая: простой продакшена

Продакшен, который лежит во время переезда, — это прямые убытки: брошенные корзины, упущенные заявки, недоступная админка, нервы у вашей команды. Мы строим процесс так, чтобы простой свёлся к минутам переключения, а не к часам. Боевой сайт работает на старом сервере весь период подготовки. Новый сервер мы собираем и тестируем параллельно: разворачиваем окружение, переносим файлы и базы, поднимаем и проверяем стенды. Когда новая площадка готова, заранее понижаем TTL у DNS — это значение определяет, как быстро интернет узнает о смене адреса сервера. После понижения TTL переключение домена занимает минуты, а не сутки. Само переключение делаем в согласованное окно минимальной нагрузки — обычно ночью или в выходной. Перед ним выполняем финальную синхронизацию свежих данных продакшена, чтобы ничего из накопленного за время переезда не потерялось.

Проблема третья: потеря данных и заказов

База с историей заказов за годы, актуальные остатки, свежие заявки, выгрузки из 1С — потеря любого фрагмента дороже самого переноса. Мы исключаем потерю данных двойной страховкой. Сначала снимаем полные бэкапы файлов и баз всех контуров — это точка отката на случай любых неожиданностей. Затем переносим данные и сверяем количество записей: число товаров, заказов, пользователей на новом сервере должно совпадать со старым. И главное — перед самым переключением DNS делаем финальную синхронизацию свежих данных продакшена. Это закрывает самый коварный сценарий: заказы, оформленные клиентами в те часы, пока шёл переезд. Без финальной синхронизации они остались бы на старом сервере и пропали бы после переключения. У нас они доезжают в новую базу, и ни один заказ не теряется.

Проблема четвёртая: «сайт открылся, но половина не работает»

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

Проблема пятая: непредсказуемый бюджет и сроки

Инфраструктурные работы любят растягиваться и обрастать «внезапными» счетами. Мы фиксируем состав работ, стоимость и сроки до старта. Цена складывается из понятных факторов: числа контуров, объёма баз данных и сложности окружения. Только продакшен переносим от 40 000 рублей за 2–3 дня, продакшен со стендами — от 75 000 рублей за 4–6 дней, сложную инфраструктуру с ветками и отдельным сервером БД — от 130 000 рублей от полутора недель. Аренда нового сервера оплачивается отдельно и оформляется на вас. Всё, что выходит за рамки согласованного плана, обсуждается и оценивается заранее, а не появляется в счёте сюрпризом. Перед стартом вы получаете бесплатный аудит инфраструктуры и прозрачную смету.

Как устроен наш процесс переноса

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

• Аудит контуров. Разбираем продакшен, тестовые стенды, ветки разработки, базы данных и связи между ними. Фиксируем карту инфраструктуры, окружение и зависимости. Составляем план переноса и смету с фиксированными сроками.
• Подготовка сервера. Подбираем и готовим новый сервер или площадку в нужном дата-центре, разворачиваем окружение BitrixVM под каждый контур с учётом нагрузки.
• Перенос контуров. Снимаем полные бэкапы файлов и баз, переносим продакшен, стенды и ветки с раздельными базами на новый сервер.
• Сверка и синхронизация. Сверяем количество записей и связи в базах, проверяем работу стендов и фоновых задач, готовимся к финальной синхронизации данных продакшена.
• Переключение DNS. Заранее понижаем TTL, делаем финальную синхронизацию свежих данных и в согласованное окно переключаем боевой трафик на новый сервер — простой минимален.
• Проверка и резерв. Проходим чек-лист после переезда, проверяем логи, очереди, cron и интеграции, держим старый сервер в резерве несколько дней для быстрого отката.

Почему откат — это не признак слабости, а норма инженерной работы

Хороший перенос отличается от плохого не тем, что в нём «никогда ничего не идёт не так», а тем, что в нём заранее предусмотрен путь назад. Мы не выключаем старый сервер сразу после переключения. Он остаётся в резерве с рабочей копией продакшена ещё несколько дней. Если после переезда вылезет проблема, которую нельзя быстро устранить на новой площадке, мы возвращаем DNS на старый сервер за минуты, спокойно разбираемся и переключаемся повторно. Для бизнеса это означает, что переезд не превращается в игру ва-банк: даже неожиданный сценарий не оборачивается простоем, потому что у нас всегда есть рабочая запасная площадка под рукой.

Кластер, разнесение БД и подготовка к нагрузке

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

Стенды, ветки и порядок в разработке

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

Частые возражения — и честные ответы

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

«Боюсь, что переезд уронит сайт надолго». Простой при нашем подходе — это минуты переключения DNS, а не часы. Продакшен работает на старом сервере до последнего, новый собирается параллельно, TTL понижается заранее, а финальная синхронизация гарантирует, что данные не отстанут. Если что-то пойдёт не так — откат за минуты.

«А вдруг потеряются заказы, оформленные во время переезда». Именно для этого существует финальная синхронизация перед переключением. Свежие данные продакшена досинхронизируются в новую базу непосредственно перед сменой DNS, поэтому заказы, сделанные в процессе переезда, не теряются.

«Не изменятся ли позиции в поиске». Нет. При переносе между серверами платформа, домены и адреса страниц остаются прежними. Это инфраструктурная миграция, а не смена CMS, поэтому 301-редиректы не нужны и SEO не затрагивается. Поисковые системы вообще не замечают смену сервера, если переключение выполнено аккуратно.

Чем мы отличаемся от разовой выгрузки архива

Перенос часто берут как примитивную операцию: скопировал, развернул, поменял DNS. Такой подход работает ровно до первого нестандартного случая — разнесённых баз, кастомного окружения, активных стендов, хитрого обмена с 1С. Мы специализируемся именно на инфраструктуре Битрикс: знаем особенности BitrixVM, права в служебных каталогах, поведение агентов и cron, тонкости кэширования и сессий. Это разница между «скопировали и надеемся, что взлетит» и «перенесли контуры, сверили данные, проверили фоновые задачи по чек-листу и держим откат наготове». За плечами — десять лет работы только с Битрикс, поэтому подводные камни платформы мы проходим заранее, а не обнаруживаем на вашем боевом сервере.

Логика реальных проектов: чему учат наши переезды

За множество выполненных переносов между серверами мы вывели несколько закономерностей, которые экономят клиентам нервы. Первая: TTL у DNS нужно понижать заранее, минимум за сутки до переключения, иначе часть трафика будет ходить на старый сервер часами после переезда. Вторая: финальную синхронизацию данных нельзя пропускать даже на «спокойных» проектах — заказы и заявки приходят и ночью, и в окно работ. Третья: окружение нельзя копировать вслепую — версия PHP, расширения и права нужно проверять на новом сервере отдельно, потому что мелкое несоответствие ломает то, что на старом сервере работало годами. Четвёртая: старый сервер должен дожить в резерве хотя бы несколько дней — большинство неожиданностей всплывает не в момент переключения, а через день-два под реальной нагрузкой.

Показательный пример из практики — смена дата-центра для интернет-магазина. Мы перенесли продакшен и два тестовых стенда на новую площадку, синхронизировали базу и переключили DNS ночью: простой составил около пяти минут, ни один заказ не потерялся. Другой случай — консолидация: у клиента продакшен, stage и dev жили на трёх разных серверах, и поддержка этого зоопарка обходилась дорого. Мы собрали все контуры на одном сервере с понятной структурой окружения, разделив базы и настроив изоляцию стендов, и держали откат наготове на каждом шаге. Третий — производственная компания с ветками разработки и отдельным сервером базы данных: мы перенесли продакшен и ветки, разнесли БД на отдельную машину и настроили деплой между контурами, чтобы дальнейшая разработка шла без риска для боевого сайта.

Когда переносить не нужно — и мы скажем об этом прямо

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

Что вы получаете на выходе

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

Давайте обсудим вашу инфраструктуру

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