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

Прежде чем браться за rsync, стоит разобраться в альтернативах. Существуют три основных способа перенести Linux-сервер на виртуальную машину, и у каждого своя область применения.

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

Clonezilla — клонирование на уровне разделов. Clonezilla копирует только занятые блоки, поэтому работает быстрее dd. Но она тоже требует загрузки с Live CD на обеих сторонах — полный простой на всё время клонирования. Для сервера с терабайтом данных это могут быть часы.

rsync — копирование на уровне файлов. Rsync передаёт файлы, а не блоки. Это даёт принципиальные преимущества для P2V-миграции:

• Целевой диск может быть любого размера — лишь бы хватило места для данных. Можно переехать с RAID-массива на 2 ТБ на виртуальный диск в 100 ГБ.
• Можно изменить разметку диска и файловую систему. Переход с ext3 на ext4, перекомпоновка разделов — всё возможно.
• Первичное копирование идёт на работающем сервере. Не нужно останавливать сервисы для первого прогона.
• Повторные прогоны передают только изменения (дельту). Финальная синхронизация после остановки сервисов занимает минуты, а не часы.

Когда rsync не подходит: зашифрованные файловые системы (LUKS), миграция Windows-серверов, экзотические ФС без поддержки POSIX-атрибутов.

P2V-миграция через rsync состоит из шести этапов: подготовка целевой VM, настройка SSH, первичная синхронизация, перенос баз данных, финальная дельта-синхронизация, правка загрузчика и настроек сети. Разберём каждый шаг.

Шаг 1. Создание целевой виртуальной машины. Создайте VM в Proxmox (или другом гипервизоре) и установите тот же дистрибутив и ту же мажорную версию ОС, что и на исходном сервере. Если исходный сервер на Debian 11 — ставьте Debian 11, не Debian 12. Несоответствие версий ядра — самая частая причина проблем после миграции. Проверьте версию: cat /etc/os-release.

Рекомендации по VM: контроллер VirtIO SCSI (virtio-scsi-single), сетевой адаптер VirtIO, диск достаточного размера для реальных данных. Убедитесь, что rsync установлен на обеих машинах. Полная документация — на официальном сайте rsync.

Шаг 2. Настройка SSH-доступа. На целевой VM сгенерируйте ключ (ssh-keygen -t ed25519) и скопируйте его на исходный сервер (ssh-copy-id root@IP_СЕРВЕРА). Rsync должен работать от root, чтобы корректно скопировать все файлы с сохранением владельцев и прав.

Шаг 3. Список исключений. Создайте файл /root/rsync-exclude.txt с директориями, которые нельзя копировать:

• /proc/*, /sys/*, /dev/*, /run/* — виртуальные ФС, создаются ядром при загрузке
• /tmp/*, /mnt/*, /media/*, /lost+found, /swapfile — временные файлы и точки монтирования
• /etc/fstab — таблица монтирования с UUID дисков целевой VM
• /etc/network/interfaces, /etc/netplan/*, /etc/hostname, /etc/machine-id — сетевые настройки и идентификатор машины
• /boot/grub/*, /boot/grub2/* — конфигурация загрузчика (будет пересоздана)

Шаг 4. Запуск rsync. Сначала пробный прогон: rsync -aAXvn --numeric-ids --exclude-from=/root/rsync-exclude.txt root@IP_СЕРВЕРА:/ /. Убедитесь, что в выводе нет исключённых путей. Затем реальная синхронизация:

rsync -aAXvP --numeric-ids --exclude-from=/root/rsync-exclude.txt root@IP_СЕРВЕРА:/ /

Разбор ключевых флагов: -a (archive — рекурсия, права, владелец, метки времени), -A (ACL), -X (расширенные атрибуты, критично для SELinux), -P (прогресс и возобновление), --numeric-ids — критически важный флаг, без него rsync сопоставляет владельцев по именам, а не по UID/GID, что ломает права на файлы.

Рекомендуем запускать rsync внутри tmux или screen. После первого прогона запустите повторно 2–3 раза — каждый следующий передаёт только дельту и работает значительно быстрее. Перед миграцией не забудьте сделать резервную копию исходного сервера.

Шаг 5. Перенос баз данных. Файлы БД на работающем сервере — не консистентный снимок. Rsync может скопировать часть файлов InnoDB в одном состоянии, а часть — в другом. Результат — битая база. Правильный подход — дамп. Для MySQL/MariaDB: mysqldump --all-databases --single-transaction --skip-lock-tables --routines --triggers --events > /root/all-databases.sql. Для PostgreSQL: sudo -u postgres pg_dumpall > /root/all-databases.sql. Подробнее о типах баз данных и их особенностях — в отдельной статье.

Шаг 6. Финальная синхронизация. Остановите все прикладные сервисы на исходном сервере (systemctl stop nginx mysql php8.1-fpm). Сделайте финальный дамп БД. Запустите rsync с флагом --delete: rsync -aAXP --numeric-ids --delete --exclude-from=/root/rsync-exclude.txt root@IP_СЕРВЕРА:/ /. Флаг --delete удаляет на целевой стороне файлы, которых больше нет на исходном сервере — это гарантирует точную копию. Этот прогон займёт минуты.

Шаг 7. Настройка целевой VM. После финальной синхронизации VM нельзя просто перезагрузить — нужно исправить несколько вещей:

• Проверить /etc/fstab — UUID дисков должны совпадать с реальными (blkid).
• Проверить /etc/hosts — файл не исключался и мог перезаписаться с исходного сервера.
• Переустановить GRUB — загрузчик привязан к конкретному диску. Выполните update-grub (Debian/Ubuntu) или grub2-mkconfig -o /boot/grub2/grub.cfg (CentOS/RHEL). Для UEFI: grub-install --target=x86_64-efi.
• Пересоздать initramfs — update-initramfs -u -k all (Debian) или dracut --regenerate-all --force (CentOS). Без этого VM уходит в kernel panic — ядро не находит драйвер VirtIO.
• Перегенерировать machine-id — rm /etc/machine-id && systemd-machine-id-setup.
• SELinux (CentOS/RHEL) — создайте touch /.autorelabel для автоматической переразметки контекстов при загрузке.

Чек-лист после запуска VM: система загрузилась и доступна по SSH; df -h — файловые системы примонтированы; systemctl --failed — нет упавших сервисов; веб-сервер отвечает, БД доступны; cron-задания на месте; права на файлы корректны. Не удаляйте исходный сервер минимум 48 часов.

Если вы работаете с NFS-хранилищами, убедитесь, что точки монтирования на новой VM настроены корректно — они не переносятся автоматически.

P2V-миграция Linux-сервера через rsync — проверенный и надёжный метод, который работает в большинстве случаев. Главные правила: rsync — для файлов, базы данных — через дамп; всегда используйте --numeric-ids; не копируйте fstab, сетевые конфиги и machine-id; пересоздайте initramfs и GRUB на целевой VM; не удаляйте исходный сервер, пока не убедитесь в работоспособности. Делайте --dry-run перед первым запуском — это решает 90% проблем.

Ответы на частые вопросы о P2V-миграции Linux-серверов с помощью rsync.