Как перенести сервер к другому провайдеру без простоя

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

Материал для владельца одного-двух серверов, который уходит от текущего провайдера из-за цены, проблем с оплатой или упавшего качества связи. Разберём, что именно входит в переезд, когда снапшот всё-таки работает, как сверить версии PHP и базы, как перенести задания планировщика cron и systemd-юниты (файлы описания фоновых служб) и в каком порядке переключать трафик, чтобы не потерять почту.

Чем перенос сервера отличается от переноса сайта

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

Сервер — это вся среда целиком. Кроме файлов и базы на нём живут установленные пакеты, настройки Nginx или Apache, задания планировщика, systemd-юниты фоновых сервисов, SSL-сертификаты, правила файрвола iptables, системные пользователи и их SSH-ключи, почтовые ящики и настройки резервного копирования.

Половина этого хозяйства не входит ни в один архив сайта. Стандартный бэкап из панели управления сохраняет /var/www и дамп MySQL — и всё. Скрипт, который каждую ночь в 03:00 выгружает заказы в бухгалтерию, в такой архив не попадёт, и о его существовании вспомнят через неделю, когда бухгалтерия спросит про выгрузку. Что вообще считается миграцией в терминах хостинга, разбирает справка про миграцию данных.

Снапшот или чистая установка: что выбрать

Снапшот — это снимок состояния диска виртуальной машины на конкретный момент. Внутри одного провайдера он переносит сервер идеально: развернули копию, поменяли IP, готово. Между разными провайдерами так получается редко.

Мешают три вещи. Форматы образов различаются (qcow2, raw, vmdk), и панель нового провайдера обычно принимает только один из них. Внутри образа прописаны сетевые настройки старой площадки — статический IP, шлюз, DNS-серверы, — и после запуска машина не видит сети. Плюс размер: образ диска на 40 ГБ не встанет на тариф с 30 ГБ, даже если реально занято 12 ГБ. Механику снимков объясняет статья про снапшот.

Практический вывод простой: если вы меняете площадку, закладывайте чистую установку. Заодно получится обновить систему — переезжать со старой Ubuntu 20.04 на актуальную 24.04 всё равно придётся, и совместить это с переносом дешевле, чем делать два раза.

Инвентаризация: что описать до начала переноса

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

Соберите вывод нескольких команд в один текстовый файл и сохраните его к себе на компьютер. Команда systemctl list-units --type=service --state=running покажет все работающие службы, dpkg -l в Debian и Ubuntu выведет список установленных пакетов, crontab -l — задания текущего пользователя.

Отдельно выпишите то, что живёт вне пакетов: домены и их текущие DNS-записи, список системных пользователей, пути к SSL-сертификатам, реквизиты внешних сервисов из переменных окружения, адреса и порты, на которые ходят сторонние интеграции. У среднего сервера с двумя-тремя сайтами такая опись занимает 40–60 строк и полчаса времени.

Сверка версий: PHP, база данных и конфиги веб-сервера

Главный источник поломок после переезда — расхождение версий. Код, который годами работал на PHP 7.4, на PHP 8.3 падает с фатальной ошибкой на первом же обращении к несуществующему свойству. База, выгруженная из MySQL 8.0, не всегда импортируется в MariaDB 10.6 из-за разницы в кодировках и правилах сортировки текста.

Поэтому версии на новом сервере ставят такие же, как на старом, а обновляют их отдельным шагом уже после переезда. Узнать текущие можно за минуту: php -v, mysql --version, nginx -v, lsb_release -a для версии системы.

Команда nginx -T выводит итоговую конфигурацию со всеми подключёнными файлами — её удобно сохранить целиком и потом сравнить с новой. Расширения PHP стоит выписать поимённо: отсутствие одного php-intl или php-gd ломает половину функций магазина, а в логах это выглядит как обычная ошибка 500.

Сколько стоит новый сервер и на чём остановиться

Стартовые тарифы в каталоге расходятся почти в десять раз: от 59 ₽/мес у нижней границы до 593 ₽/мес у крупных площадок за формально похожую конфигурацию. Разница — в типе дисков, поколении процессора и плотности соседей на физической машине.

При переезде конфигурацию берут не «как было», а по факту потребления. Посмотрите на старом сервере вывод free -m и df -h: если из 4 ГБ памяти занято 1,2 ГБ, а из 80 ГБ диска — 18 ГБ, платить за прежний тариф незачем. Подборка стартовых предложений собрана в разделе недорогих VPS, а машины в российских дата-центрах — в разделе VPS в России.

Данные проверены 04.09.2026.

Заложите в бюджет неделю параллельной работы двух серверов: старый нельзя выключать сразу, а суммарно это добавит 60–150 ₽ разово. Дороже обойдётся только вариант, где старую машину отключили в день переключения и через сутки выяснили, что забыли забрать почтовый архив.

Перенос данных через rsync: одна команда и что она делает

Для копирования файлов между серверами используют rsync — утилиту, которая передаёт только различия между источником и приёмником. Первый проход копирует всё, каждый следующий — лишь изменившиеся куски, поэтому повторная синхронизация тех же 20 ГБ занимает не час, а полторы минуты. Подробности работы утилиты описаны в справке про rsync.

Рабочая команда выглядит так: rsync -avz --numeric-ids -e ssh /var/www/ root@NEW_IP:/var/www/. Флаг -a сохраняет права, владельцев и даты файлов, -v печатает, что происходит, -z сжимает поток при передаче, --numeric-ids переносит владельцев по числовым идентификаторам, а не по именам, которых на новой машине может не быть.

Скорость упирается в канал. На 100 Мбит/с реально получается около 40 ГБ в час, на гигабитном канале — до 300 ГБ. Косая черта в конце пути источника важна: /var/www/ копирует содержимое папки, а /var/www без неё создаст внутри приёмника вложенную папку www. Базу данных через rsync не переносят — её выгружают дампом, порядок разобран в гайде про перенос базы данных MySQL.

Cron и systemd-юниты теряют чаще всего

Задания планировщика не лежат в одном файле, и это главная ловушка переезда. Личные задания каждого пользователя хранятся отдельно и достаются командой crontab -l -u имя. Системные лежат в каталоге /etc/cron.d/ и в файле /etc/crontab. Плюс есть каталоги /etc/cron.daily/ и /etc/cron.hourly/ со скриптами, которые запускаются без явного расписания.

Проверьте все эти места по очереди и перенесите содержимое вручную, сверяя часовой пояс. Задание на 03:00 по московскому времени на сервере с UTC отработает в 06:00 — формально всё работает, фактически ночная выгрузка попадает в утренний пик. Синтаксис расписаний разбирает материал про менеджер crontab.

Вторая часть — фоновые сервисы. Собственные systemd-юниты живут в /etc/systemd/system/ и представляют собой обычные текстовые файлы: скопировали, выполнили systemctl daemon-reload, затем systemctl enable --now имя.service. Без команды enable сервис запустится один раз и не поднимется после первой же перезагрузки — ошибка вскрывается только через месяц.

Почта: почему письма пропадают после переезда

Почтовый сервер на новом IP — это отдельная задача, и она не решается копированием конфигов. Письма перестают доходить по трём причинам, и все три связаны с DNS и репутацией адреса.

Первая — MX-запись домена продолжает указывать на старый сервер, письма уходят туда, а вы читаете новый. Вторая — запись SPF перечисляет разрешённые IP-адреса отправителей, и нового адреса в ней нет: получатели считают такие письма подделкой. Третья — обратная запись PTR, которая связывает IP-адрес с именем сервера: у свежего адреса её либо нет, либо она указывает на техническое имя провайдера, и крупные почтовые сервисы отправляют письма в спам. Что и где прописано, поясняет справка про записи DNS.

Порядок действий такой: сначала поднимаете почту на новом сервере и проверяете отправку на свой ящик, потом просите провайдера настроить PTR на имя вашего домена, затем добавляете новый IP в SPF и только после этого переключаете MX. Сами ящики переносят копированием каталога /var/mail или /var/vmail тем же rsync — там лежат все письма в виде файлов.

Пошаговый порядок переключения

Ниже последовательность, при которой сайт не отдаёт ошибок в момент переезда, а откат занимает минуту. Она рассчитана на один сервер с сайтом, базой и парой фоновых заданий.

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

1. За сутки до переезда снизьте TTL всех A-записей домена с обычных 3600 секунд до 300. TTL — это срок, на который провайдеры кешируют ответ DNS: чем он меньше, тем быстрее разойдётся переключение. Так оно займёт 5 минут, а не час.
2. Закажите новый сервер, поставьте ту же версию ОС и те же версии PHP и базы, что выписали при инвентаризации.
3. Сделайте первый проход rsync по файлам, не останавливая старый сервер: это самая долгая часть, 20 ГБ уходят примерно за 30 минут.
4. Проверьте сайт на новой машине через файл hosts на своём компьютере: в нём прописывают соответствие домена и IP, и домен будет вести на новую машину только у вас.
5. Включите на старом сервере режим обслуживания, повторите rsync — он догонит только то, что изменилось с первого прохода, — и снимите свежий дамп базы. На это уходит 5–15 минут.
6. Перенесите cron, systemd-юниты и сертификаты, запустите фоновые сервисы и убедитесь, что в логах пусто.
7. Переключите A-запись на новый IP, дождитесь расхождения по DNS и верните TTL к 3600 секундам.

Старый сервер не удаляйте ещё 7–14 дней. За это время всплывут забытые скрипты, а если что-то пойдёт не так, откат — это возврат A-записи обратно, то есть те же 5 минут. Проверить, куда сейчас смотрит домен, помогает инструкция про проверку DNS-записей.

Как убедиться, что переезд прошёл без потерь

Сразу после переключения проверяют не «открывается ли сайт», а конкретные точки, где обычно и обнаруживаются пропажи. На это уходит 20–30 минут, и это единственный способ поймать проблему раньше пользователей.

Пройдите по списку в первый час: логи веб-сервера на предмет ошибок 500 и 502, срок действия SSL-сертификата, отправка письма с сайта на внешний ящик, загрузка файла через форму, работа поиска и корзины. Отдельно посмотрите journalctl -p err -n 100 — команда покажет последние 100 системных ошибок.

Через сутки проверьте второй слой: отработали ли ночные задания cron, ушли ли уведомления, не выросла ли нагрузка. И сразу настройте резервное копирование на новой машине — старые бэкапы остались на прежней площадке и на новую не переедут сами. Как это устроить, показано в гайде про настройку бэкапов VPS.

Частые ошибки

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

Список ниже стоит прочитать до начала работ и ещё раз — перед переключением A-записи. Каждый пункт стоил кому-то нескольких часов, а первые два — потерянных данных.

• Отключение старого сервера в день переезда: откатиться уже некуда, а забытое обнаруживается на третий день.
• Дамп базы, снятый до финальной синхронизации: заказы и комментарии за последние часы теряются молча.
• Перенос только /var/www без /etc, cron и systemd-юнитов — сайт работает, фоновые задачи мертвы.
• Разные версии PHP на старом и новом сервере: код падает, а причину ищут в переносе файлов.
• Переключение MX-записи до настройки SPF и PTR — исходящая почта уходит в спам на недели.
• Забытый TTL в 86400 секунд: часть пользователей сутки видит старый сервер, часть — новый.

Частые вопросы

Можно ли перенести сервер снапшотом к другому провайдеру? Иногда можно, но рассчитывать на это не стоит: нужен поддерживаемый формат образа, место на диске нового тарифа и ручная правка сетевых настроек внутри системы. Между разными площадками надёжнее поставить чистую ОС и перенести данные rsync.

Сколько времени занимает перенос целиком? Для сервера с одним-двумя сайтами и объёмом данных до 20 ГБ закладывайте 3–6 часов работы плюс сутки наблюдения. Из них около получаса уходит на первую синхронизацию файлов и 5–15 минут на финальную досинхронизацию с дампом базы.

Будет ли простой сайта? При правильном порядке — от 5 до 15 минут: столько сайт стоит в режиме обслуживания, пока досинхронизируются файлы и снимается свежий дамп. Само переключение DNS простоя не даёт, если TTL заранее снижен до 300 секунд.

Как перенести задания cron? Соберите их из четырёх мест: crontab -l для каждого пользователя, /etc/crontab, каталог /etc/cron.d/ и каталоги cron.daily с cron.hourly. Перед запуском сверьте часовой пояс новой машины командой timedatectl, иначе расписание сдвинется на несколько часов.

Что делать с SSL-сертификатом? Бесплатный сертификат Let’s Encrypt проще выпустить заново на новом сервере — это занимает пару минут и не требует переноса файлов. Платный сертификат переносят вместе с приватным ключом, копируя каталог с ним и правя пути в конфиге веб-сервера.

Почему после переезда письма с сайта попадают в спам? У нового IP-адреса нет истории отправки, часто отсутствует запись PTR, а в SPF домена он ещё не перечислен. Настройте PTR через поддержку провайдера, добавьте адрес в SPF и первые дни отправляйте небольшими объёмами.

Нужно ли платить за два сервера одновременно? Да, и это правильные расходы: неделя параллельной работы на стартовых тарифах стоит 60–150 ₽ и оставляет возможность откатиться. Выключать старую машину есть смысл только после того, как отработали все ночные задания и месячные отчёты.

Итог

Переезд сервера держится на трёх вещах: полной описи старой машины, совпадении версий PHP и базы данных и правильном порядке действий, где DNS переключают последним. Файлы переносит rsync за один вечер, а теряются обычно не они, а cron, systemd-юниты и почтовые записи.

Если поводом для переезда стала цена или качество площадки, конфигурацию под текущее потребление удобно подобрать в каталоге виртуальных серверов — там 44 провайдера со стартом от 59 ₽/мес, и по вкладкам видно, где сколько тарифов и какие диски стоят в базовой комплектации.