Содержание
Перенос операционной системы с одного сервера на другой — это не просто копирование файлов. Это почти как пересадка сердца: нужно сохранить все связи, настройки, артефакты конфигурации, но при этом адаптировать организм к новому телу. В современных реалиях, где простои измеряются не часами, а тысячами упущенных запросов в секунду, умение перенести Ubuntu 24.04 без полной переустановки становится не просто полезным навыком — оно превращается в элемент выживания.
В этой статье мы подробно разберём три проверенных метода миграции: через rsync, побитовое копирование с помощью dd и перенос LVM-томов. Каждый из них имеет свои особенности, риски и преимущества. Мы не просто покажем команды — мы погрузим вас в логику каждого шага, объясним, почему и для чего выполняется та или иная операция, и покажем, как избежать самых опасных ловушек. Начнём с основ — с подготовки, без которой даже самый гениальный план рухнет в первые пять минут.
Подготовительный этап: основа успеха миграции
Прежде чем даже думать о том, как скопировать систему, необходимо подготовить «почву» — на старом и новом серверах. Этот этап включает резервное копирование, диагностику текущего состояния и настройку целевой машины. Пренебрежение хотя бы одним из пунктов может привести к потере данных или невозможности загрузки.
Создание полной резервной копии
Первое и самое важное правило: никогда не мигрируйте без бэкапа. Даже если вы — гуру с 20-летним стажем. Ошибки случаются, диски выходят из строя, а команды в терминале не прощают невнимательности.
В зависимости от типа файловой системы и архитектуры хранения, стратегия резервного копирования может отличаться:
- Для LVM (Logical Volume Manager) — используйте снапшоты. Они позволяют создать мгновенный снимок тома без остановки сервисов:
Здесьsudo lvcreate -L 10G -s -n backup_snapshot /dev/ubuntu-vg/root-L 10G— размер резервного пространства (должен быть достаточным для всех изменений во время бэкапа),-s— флаг создания снапшота. - Для Btrfs — используйте встроенные подтома:
Эта команда создаёт мгновенный, почти бесплатный по ресурсам снимок корневой файловой системы.sudo btrfs subvolume snapshot / /@backup_snapshot - Для EXT4/XFS — создайте архив с помощью
tar, исключив временные и системные директории:
Параметрsudo tar -cvpzf /backup.tar.gz \ --exclude=/backup.tar.gz \ --exclude=/proc --exclude=/sys --exclude=/dev \ --exclude=/mnt --exclude=/media --exclude=/run \ --exclude=/tmp --one-file-system /--one-file-systemгарантирует, что архив не выйдет за пределы корневого раздела, игнорируя все смонтированные тома (например, /home на отдельном диске).
Сохраните бэкап на внешний носитель или другой сервер. Лучше всего — и там, и там.
Фиксация текущего состояния системы
Даже если вы восстановите файлы, без знания текущей конфигурации может потребоваться часы, чтобы «довести систему до ума». Запишите всё:
- Список установленных пакетов:
Это позволяет восстановить весь программный стек одной командой позже.dpkg --get-selections > /root/pkg-list.txt - Сетевые настройки:
ip -brief a > /root/network-info.txt - Структура дисков:
lsblk -f > /root/disk-layout.txt blkid >> /root/disk-layout.txt cat /etc/fstab >> /root/layout.txt - Список сервисов:
systemctl list-unit-files --type=service > /root/services.txt
Перенесите эти файлы на резервный сервер:
scp /root/*-info.txt user@backup-server:/backups/
Подготовка нового сервера
Новый сервер должен быть «готов к принятию» мигрирующей системы.
- Разметка дисков должна совпадать с исходной. Используйте
lsblkна обоих машинах для сравнения. - Если используется аппаратный RAID или ZFS, их нужно настроить до переноса.
- На время миграции отключите автообновления:
sudo systemctl disable unattended-upgrades - Разрешите root-логин по SSH (временно!):
sudo sed -i 's/#PermitRootLogin.*/PermitRootLogin yes/' /etc/ssh/sshd_config sudo systemctl restart sshd - Убедитесь, что на новом диске достаточно места:
df -h /
Этот этап — не бюрократия, а страховка. Чем более идентичны серверы, тем меньше сюрпризов вас ждёт после переноса.
Метод первый: миграция через rsync — гибкость и контроль
Rsync — это швейцарский нож системного администратора. Он не копирует биты, а синхронизирует файлы, сохраняя атрибуты, права, владельцев и метаданные. Это делает его идеальным для миграции между дисками разного типа (HDD → SSD), разного размера или даже разных архитектур (при условии одинаковой разрядности).
Загрузка с Live-носителя
Чтобы избежать конфликтов с работающими процессами, оба сервера (или хотя бы целевой, если источник доступен по сети) загружаются с LiveUSB:
sudo dd if=ubuntu-24.04-live-server-amd64.iso of=/dev/sdc bs=4M status=progress
После загрузки монтируем корневые разделы:
# На старом сервере: sudo mkdir /mnt/old-root sudo mount /dev/sda2 /mnt/old-root # На новом сервере: sudo mkdir /mnt/new-root sudo mount /dev/nvme0n1p2 /mnt/new-root
Убедитесь, что /mnt/old-root/etc содержит конфигурационные файлы, а /mnt/new-root — пуст.
Сам процесс копирования
Используем rsync с полным набором параметров:
sudo rsync -aAXv --delete \ --exclude={"/dev/*","/proc/*","/sys/*","/tmp/*","/run/*","/mnt/*","/media/*","/lost+found"} \ /mnt/old-root/ /mnt/new-root/
Разберём ключи:
-a— архивный режим (сохраняет права, владельцев, временные метки);-A— копирует ACL;-X— копирует расширенные атрибуты (xattrs);-v— подробный вывод;--delete— удаляет файлы на цели, отсутствующие на источнике;--exclude— исключает системные директории, которые не должны копироваться.
Постобработка
После копирования нужно адаптировать систему к новому «телу»:
- Обновите UUID в
/etc/fstab. Получите новые значения:
Замените старые UUID вblkid/mnt/new-root/etc/fstab. - Переустановите загрузчик. Для этого создайте chroot-окружение:
sudo mount --bind /dev /mnt/new-root/dev sudo mount --bind /proc /mnt/new-root/proc sudo mount --bind /sys /mnt/new-root/sys sudo chroot /mnt/new-root Внутри chroot: grub-install /dev/nvme0n1 update-grub exit - Сгенерируйте новый machine-id:
Без этого systemd может запутаться, особенно если старый сервер всё ещё работает в сети.sudo rm /mnt/new-root/etc/machine-id sudo systemd-machine-id-setup --root=/mnt/new-root
Если система не загружается — воспользуйтесь boot-repair:
sudo add-apt-repository ppa:yannubuntu/boot-repair sudo apt update sudo boot-repair
Метод второй: побитовое клонирование через dd — точность как сталь
Если вам нужна абсолютная идентичность — например, при замене диска в одноплатной системе или при восстановлении после отказа — на помощь приходит утилита dd. Она копирует диск посекторно, включая загрузочную область (MBR/GPT), таблицы разделов и даже «мёртвые» сектора.
Когда использовать dd?
Этот метод подходит, если:
- Диски одинакового размера (целевой не меньше источника);
- Вы переносите систему на идентичное «железо»;
- Вам критична точность копирования (включая скрытые разделы, криптографические метки и т.д.).
Процесс клонирования
Подключите целевой диск к исходному серверу. Определите имена устройств:
sudo lsblk -d -o NAME,SIZE
Запустите копирование:
sudo dd if=/dev/sda of=/dev/sdb bs=64K status=progress conv=noerror,sync
Пояснение параметров:
bs=64K— оптимальный размер блока для современных дисков;status=progress— показывает прогресс;conv=noerror,sync— продолжает копирование даже при ошибках чтения, заполняя повреждённые блоки нулями.
Для отслеживания прогресса в реальном времени (во втором терминале):
sudo kill -USR1 $(pgrep ^dd)
Постобработка
После копирования:
- Сбросьте кеш:
sudo sync - Проверьте целостность файловой системы:
sudo fsck -f /dev/sdb2 - Если оборудование изменилось — обновите initramfs:
sudo mount /dev/sdb2 /mnt/new-root sudo mount --bind /dev /mnt/new-root/dev sudo mount --bind /proc /mnt/new-root/proc sudo mount --bind /sys /mnt/new-root/sys sudo chroot /mnt/new-root dpkg-reconfigure linux-image-$(uname -r) update-initramfs -u grub-install /dev/sdb update-grub
Метод dd — мощный, но опасный. Одна ошибка в имени устройства — и вы сотрёте не тот диск. Всегда дважды проверяйте lsblk!
Метод третий: миграция LVM-томов — гибкость для enterprise
Если ваша система использует LVM, вы обладаете мощнейшим инструментом для миграции. LVM позволяет переносить тома «на лету», изменять их размеры и даже объединять несколько физических дисков в единое логическое пространство.
Подготовка
Подключите новый диск к работающему серверу. Создайте на нём Physical Volume:
sudo pvcreate /dev/nvme0n1
Сохраните текущую конфигурацию Volume Group:
sudo vgcfgbackup -f /root/vg_backup.txt ubuntu-vg
Здесь ubuntu-vg — имя вашей группы томов (узнать можно через vgdisplay).
Перенос данных
Теперь перенесите данные с одного PV на другой:
sudo pvmove -n lv-root /dev/sda2 /dev/nvme0n1
Команда может занять часы — но она работает в фоне, не останавливая систему.
Если вы хотите увеличить том во время переноса:
sudo lvextend -L 50G /dev/ubuntu-vg/lv-root sudo resize2fs /dev/ubuntu-vg/lv-root # для EXT4 # или sudo xfs_growfs / # для XFS
Обновление конфигурации
После переноса обновите UUID в системных файлах:
NEW_UUID=$(sudo blkid -s UUID -o value /dev/ubuntu-vg/lv-root) sudo sed -i "s/old-uuid-here/$NEW_UUID/g" /etc/fstab /boot/grub/grub.cfg
И переустановите загрузчик на новый диск:
sudo grub-install /dev/nvme0n1 sudo update-grub
Важно: для успешного pvmove в группе томов должно быть достаточно свободного места — не меньше размера переносимого тома.
Завершающий аккорд: первые шаги на новом сервере
После успешного переноса система должна «осознать», что она теперь живёт в новом теле.
Сетевые настройки
MAC-адреса изменились — это значит, что Netplan может перестать работать. Обновите конфигурацию:
sudo nano /etc/netplan/00-installer-config.yaml
Укажите новые интерфейсы (можно узнать через ip link show), затем примените:
sudo netplan apply
Пересборка драйверов
Особенно важно при смене чипсета или процессора:
sudo dkms autoinstall sudo update-initramfs -u -k all
Очистка идентификаторов
Удалите старые SSH-ключи, чтобы избежать предупреждений «man-in-the-middle»:
sudo rm /etc/ssh/ssh_host_* sudo dpkg-reconfigure openssh-server
Тестирование в chroot
Перед перезагрузкой проверьте систему:
sudo mount --bind /dev /mnt/new-root/dev sudo mount --bind /proc /mnt/new-root/proc sudo mount --bind /sys /mnt/new-root/sys sudo chroot /mnt/new-root # Внутри: systemctl --failed journalctl -b -p3 ip a mount | grep /
После перезагрузки
Выполните диагностику:
- Проверка оборудования:
lspci -k | grep -A 2 "Ethernet\|VGA" - Тест диска:
sudo dd if=/dev/zero of=./test.bin bs=1G count=1 oflag=direct status=progress - Мониторинг:
htop iotop
Заключение: миграция как философия поддержания стабильности
Перенос Ubuntu 24.04 на новый сервер без переустановки — это не просто техническая задача. Это проявление уважения к времени, вложенному в настройку системы, к данным, которые невозможно восстановить, и к пользователям, которые не должны страдать от простоев.
Выбор метода зависит от контекста:
- Rsync — универсален, подходит для разных дисков, облачных миграций, апгрейдов.
- dd — идеален для точного клонирования, особенно в однотипных системах.
- LVM — лучший выбор для enterprise-инфраструктур, где важна гибкость и масштабируемость.
Независимо от выбранного пути, успех миграции определяется не командами, а подготовкой. Создайте бэкап. Зафиксируйте состояние. Протестируйте. И помните: даже самый совершенный перенос — пустая трата времени, если вы не проверите, что всё действительно работает.
Следуя этой инструкции, вы не просто перенесёте сервер — вы сохраните его душу.