Миграция BitrixVM на новый сервер

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

Главный страх клиента: слетит конфигурация окружения

Самое частое опасение — что при переносе потеряются выверенные настройки nginx, PHP, MySQL и прав, и сайты на новом сервере заработают с ошибками. Так бывает, когда окружение собирают заново, по памяти, вместо того чтобы перенести его как есть. Мы подходим иначе. Либо снимаем образ виртуальной машины целиком и разворачиваем его на новом сервере, либо мигрируем пулы и сайты по отдельности, сохраняя версии и параметры nginx, PHP, MySQL, memcached, права и cron-задачи. Перед переключением сверяем настройки с исходным сервером по встроенной панели BitrixVM, которая показывает соответствие окружения требованиям платформы. Это превращает «вроде перенесли» в проверку по чек-листу вендора.

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

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

Когда внутри BitrixVM живёт несколько сайтов и пулов, перенести всё руками сложно и рискованно: легко забыть один из сайтов, перепутать подключения к базам или потерять часть cron-задач. Мы мигрируем все пулы и сайты разом, сохраняя их структуру, подключения к базам, расписания и агентов. Каждый сайт после переноса проверяем по панели BitrixVM по отдельности, чтобы убедиться, что ничего не отвалилось. Для проектов с отдельным сервером базы данных переносим и сверяем не только веб-узел, но и узел БД, чтобы связи между ними остались корректными. Чем сложнее устройство машины, тем подробнее карта переноса и тщательнее сверка.

Проблема третья: простой и потерянные заказы

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

Проблема четвёртая: что если после переключения станет хуже

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

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

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

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

Почему важна экспертиза именно по BitrixVM

BitrixVM — это не просто набор пакетов, а выверенное вендором окружение, в котором десятки параметров влияют на скорость и стабильность сайтов. Администратор без опыта работы с Битрикс собирает окружение «как привык», и сайты формально запускаются, но работают с ошибками: то отваливается композитный кэш, то не уходит почта, то фоновые агенты висят, то не стартует push-сервер. Мы десять лет работаем только с Битрикс и знаем устройство виртуальной машины изнутри: как устроены пулы, какие права нужны каталогам, как настроены memcached и очереди, какие версии PHP и MySQL рекомендованы под вашу редакцию. Поэтому после нашей миграции сайты не просто открываются — они работают так, как задумано вендором.

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

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

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

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

«Боюсь, что при обновлении версий PHP сломаются старые сайты». Поэтому обновление версий — отдельный, контролируемый шаг. Мы проверяем совместимость каждого сайта с новой версией PHP и MySQL на тестовом контуре до переключения. Если какой-то сайт не готов к свежей версии, переносим окружение как есть, а обновление планируем отдельно.

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

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

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

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

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

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

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

Миграция нагруженного магазина: на что обращаем внимание особо

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

Миграция машины со стендами и сложным окружением

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

Что вы теряете, откладывая миграцию

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

Давайте обсудим вашу миграцию

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