Как перенести сервер с другого VDS-хостинга: три рабочих способа

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

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

С чего начать в любом случае

Независимо от выбранного метода, есть подготовительные шаги, которые экономят нервы.

Проведите инвентаризацию. Прежде чем что-либо копировать, нужно понимать, что именно вы переносите. Зафиксируйте версию ОS, веб-сервер (nginx, Apache), версию PHP, СУБД (MySQL/MariaDB, PostgreSQL), список сайтов и их корневые каталоги, базы данных, почтовые ящики, SSL-сертификаты и cron-задачи. Посмотреть установленные пакеты можно так:

# Debian/Ubuntu
dpkg --get-selections > packages.list

# CentOS/AlmaLinux/RHEL
rpm -qa > packages.list

А history, crontab -l, nginx -T и systemctl list-units --type=service --state=running помогут восстановить картину того, что и как было настроено.

Заранее понизьте TTL у DNS-записей. Это делается в панели управления доменом за сутки-двое до переезда. Поставьте TTL для A/AAAA-записей в 300 секунд (5 минут). Тогда после смены IP пользователи переключатся на новый сервер почти мгновенно, а не будут несколько часов попадать на старую машину из-за кэша.

Снимите резервную копию до начала работ. Любой перенос — это риск, поэтому свежий бэкап на отдельном хранилище должен быть в наличии всегда.

Способ 1. Перенос через бэкап панели управления (ISPmanager и аналоги)

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

Когда подходит: на источнике и приёмнике одна и та же панель одной версии и редакции. Перенос между разными панелями (например, из cPanel в ISPmanager) штатным бэкапом не сработает.

1. На новом сервере установите ту же версию и редакцию панели, что и на старом. Убедитесь, что лицензия активирована.
2. На старом сервере в разделе резервного копирования настройте хранилище — это может быть FTP/SFTP-сервер, облако или S3-совместимое хранилище. Создайте полную резервную копию: пользователи, сайты, базы данных, почта и настройки.
3. На новом сервере подключите то же хранилище резервных копий и запустите восстановление из созданной копии.

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

Способ 2. Клонирование диска через rescue-режим и dd

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

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

Почему именно rescue-режим

Копировать смонтированный, работающий диск через dd нельзя — данные на нём постоянно меняются, и копия получится повреждённой. Rescue-режим (его предоставляет большинство VDS-хостингов в панели) загружает сервер в отдельную минимальную систему в оперативной памяти, а основной диск остаётся не смонтированным. Только в таком состоянии можно снимать его целиком.

Процесс

1. Переведите оба сервера в rescue-режим.
2. На источнике запустите потоковое копирование диска на приёмник по SSH. Чтобы не гонять по сети пустое место, поток сжимают на лету:

dd if=/dev/sda bs=4M status=progress | gzip -1 - | \
  ssh root@NEW_IP "gunzip | dd of=/dev/sda bs=4M"

Здесь /dev/sda — системный диск (уточните имя через lsblk), NEW_IP — адрес нового сервера в rescue-режиме.

3. После завершения проверьте и при необходимости поправьте на новом сервере сетевые настройки (новый IP, шлюз), UUID разделов в /etc/fstab, конфигурацию загрузчика GRUB.
4. Выйдите из rescue-режима и загрузитесь в обычном режиме.

Альтернатива поспокойнее: rsync вместо dd

Побитовый dd копирует диск целиком, включая свободное место и привязку к конкретному «железу». Часто надёжнее склонировать не диск, а файловую систему — через rsync из rescue-режима. Так вы переносите только реальные данные и легче переживаете разницу в окружении:

rsync -aAXHv --numeric-ids \
  --exclude={"/dev/*","/proc/*","/sys/*","/tmp/*","/run/*","/mnt/*","/media/*","/lost+found"} \
  / root@NEW_IP:/mnt/target/

После этого на новом сервере нужно установить загрузчик и обновить fstab. Для копирования разделов «как есть» также подойдёт partclone.

Плюсы: получаете полную копию системы без ручного разбора конфигов. Минусы: чувствителен к различиям в окружении; диск приёмника должен быть не меньше; после клонирования почти всегда нужна правка сети, fstab и загрузчика.

Способ 3. Ручной перенос

Самый трудоёмкий, но и самый гибкий способ. Вы поднимаете чистый сервер и переносите данные по частям, контролируя каждый шаг. Именно здесь пригодится та самая инвентаризация — и history, по которой можно восстановить, как настраивался старый сервер.

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

Шаг 1. Восстановите окружение

По собранному списку пакетов и истории команд установите на новом сервере тот же набор ПО: веб-сервер, нужную версию PHP, СУБД, дополнительные модули. На Debian/Ubuntu список пакетов со старой машины можно применить так:

# на новом сервере
sudo dpkg --set-selections < packages.list
sudo apt-get dselect-upgrade

Шаг 2. Перенесите файлы сайтов

Файлы удобнее всего переносить через rsync — он докачивает только изменения и сохраняет права и владельцев:

rsync -avz -e ssh /var/www/ root@NEW_IP:/var/www/

Шаг 3. Перенесите базы данных

Выгрузите дампы на старом сервере и загрузите на новом. Для MySQL/MariaDB:

# на старом сервере
mysqldump --single-transaction --routines --triggers \
  имя_базы > база.sql

# на новом сервере
mysql имя_базы < база.sql

Не забудьте создать пользователей БД и выдать им права — пароли в дампе не переносятся.

Шаг 4. Конфиги, cron, SSL

Перенесите конфигурацию веб-сервера (виртуальные хосты nginx/Apache), настройки PHP, задания cron (crontab -l на старом, crontab -e на новом), системных пользователей. SSL-сертификаты от Let's Encrypt проще перевыпустить на новом сервере после переключения DNS, а платные — скопировать вместе с ключами.

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

После переноса: проверка и переключение

Перенос завершён, но переключать на него боевой трафик сразу рискованно. Действуйте аккуратно.

Проверьте сайт до смены DNS. На своём компьютере добавьте в файл hosts (/etc/hosts в Linux/macOS, C:\Windows\System32\drivers\etc\hosts в Windows) строку с новым IP и доменом. Тогда у вас сайт будет открываться с нового сервера, а у пользователей — всё ещё со старого. Прокликайте основные страницы, проверьте формы, оплату, почту.

Сделайте финальную досинхронизацию. Между первым копированием и переключением на старом сервере могли появиться новые данные — заказы, комментарии, загрузки. Чтобы не потерять их, на время переключения переведите старый сайт в режим обслуживания (или только на чтение) и прогоните rsync ещё раз — он докачает разницу. Базу при необходимости тоже перелейте свежим дампом.

Переключите DNS. Поменяйте A/AAAA-записи на новый IP. Благодаря заранее сниженному TTL переключение займёт минуты.

Не удаляйте старый сервер сразу. Подержите его в рабочем состоянии хотя бы несколько дней. Если на новом всплывёт незамеченная проблема, у вас будет куда откатиться. Параллельно следите за логами nginx, PHP и базы на новой машине.

Какой способ выбрать

Если на обоих серверах одна панель — переносите через её бэкап или встроенную миграцию: это быстро и надёжно. Если панели нет, а систему хочется получить идентичной — клонируйте диск через rescue-режим, помня про требования к одинаковому окружению. А если нужен полный контроль, обновление ОС или перенос между разными хостингами — выбирайте ручной способ.

В любом случае главные страховки одни и те же: свежий бэкап до начала работ, заранее сниженный TTL, проверка через hosts до переключения и сохранённый на пару дней старый сервер. С такой подготовкой переезд проходит без потерь и почти без простоя.