Миграция Intel NUC в виртуальную среду: сохранение рабочих сред
Мой верный, но устаревающий мини-ПК Intel NUC всё ещё пригоден для эксплуатации, однако использование целого устройства исключительно для запуска двух Docker-контейнеров больше не оправдано. Я планировал вернуть его к роли файлового сервера, но столкнулся с проблемой: на установленной Ubuntu работала система мониторинга n8n, сервис ntfy, обширная история рабочих процессов и множество настроек, которые не хотелось восстанавливать по памяти. Вместо того чтобы переносить приложения по отдельности, я создал полный образ физического диска с помощью Clonezilla и развернул его в VMware Workstation. В итоге 120 ГБ SSD-накопитель сжался до более компактных 9,12 ГБ, Ubuntu загрузилась почти идеально, а автоматизации n8n продолжили работу.
Для меня эти автоматизации оказались ценнее самого оборудования: мини-ПК можно заменить, а вот их работоспособное состояние — нет. Модель Intel NUC6CAYB не представляла собой ничего особенного: процессор Intel Celeron J3455, 4 ГБ оперативной памяти, 120 ГБ SSD SanDisk и ОС Ubuntu Server 26.04.1 LTS. Хотя с самим ПК проблем не было, вся система вместе с автоматизациями занимала лишь 19 ГБ на SSD, что делало использование целого мини-ПК крайне нерациональным, когда мне потребовалось локальное хранилище.
Анализ рабочих нагрузок перед миграцией
Контейнеры продолжали выполнять полезные функции: n8n запускал рабочий процесс, отслеживающий мой сервер Home Ops, и проверял удаленный экземпляр Glances, формируя ежедневные отчеты. Оба сервиса отправляли уведомления в Telegram-бот. Простое копирование файлов Compose не сохранило бы bind-монтируемые данные, учетные данные, состояния рабочих процессов, историю выполнения и все мелкие настройки, которые я не документировал.
Перед тем как задействовать Clonezilla, я провел аудит нагрузки командами sudo docker compose ls и sudo docker inspect n8n —format ‘{{range .Mounts}}{{.Source}} -> {{.Destination}}{{println}}{{end}}’. Это подтвердило работу обоих проектов и то, что для n8n установлена политика перезапуска unless stopped. Я также намеренно остановил Homarr для проверки автоматизаций: уведомления об отключении и восстановлении пришли корректно, и сервер был готов к переносу в виртуальную машину.
Поскольку образ диска не должен быть единственной копией, я создал отдельный архив с директориями n8n и ntfy, конфигурацией Caddy и сертификатами. Также я сгенерировал SHA-256 хеши для проверки целостности данных после развертывания образа на виртуальной машине.
Использование Clonezilla для создания образа
Хотя SSD имел заявленную емкость 120 ГБ (фактическая — 111,8 ГБ), мой USB-накопитель был объемом 115 ГБ. Создание побайтового образа заняло бы почти все место, несмотря на наличие пустых блоков. Файловая система Ubuntu показала более оптимистичную картину: из 109 ГБ было занято лишь 19 ГБ. Поскольку Clonezilla понимает ext4, она смогла скопировать только занятые блоки данных.
Для подстраховки я использовал отдельный 16 ГБ USB-накопитель с Balena Etcher для загрузки Clonezilla Live, а 100 ГБ USB-диск — в качестве репозитория для образа. Благодаря многопоточному сжатию Zstandard (z9p), поддерживаемому Clonezilla, итоговый образ уменьшился до 9,12 ГБ.
Процесс миграции состоял из шести шагов:
- Выбор режима device-image (вместо прямого копирования между дисками).
- Монтирование 115 ГБ USB-накопителя как репозитория образов.
- Выбор опции savedisk с последующим именованием образа.
- Выбор внутреннего SSD SanDisk в качестве источника.
- Применение многопоточного сжатия z9p.
- Верификация готового образа.
Clonezilla захватила EFI-раздел (1 ГБ) и раздел ext4 (110,7 ГБ), преобразовав 19 ГБ занятого пространства в сжатый файл объемом 9,12 ГБ.
Развертывание в виртуальной среде
После создания образа я подготовил ВМ с параметрами, максимально повторяющими конфигурацию NUC: UEFI, одно vCPU (два ядра), 4 ГБ ОЗУ, пустой SATA-диск 128 ГБ и сетевой адаптер в режиме моста (bridged). Я подключил ISO-образ Clonezilla к виртуальному приводу и пробросил 100 ГБ USB-накопитель как USB-устройство.
После того как Clonezilla смонтировала NTFS-раздел и обнаружила образ, я воспользовался функцией restoreddisk, выбрав виртуальный диск VMware в качестве целевого. Во время восстановления и первой загрузки я держал сетевой адаптер отключенным, так как физический сервер и его клон изначально имели одинаковые имена хостов, сервисные URL-адреса и IP-адреса.
Результаты миграции и проверка работоспособности системы
Одновременное нахождение обеих машин в сети потенциально могло привести к ситуации, когда два устройства заявляли бы права на одну и ту же идентичность.
Clonezilla — это бесплатная утилита с открытым исходным кодом для создания образов дисков и клонирования, предназначенная для резервного копирования на голое железо, миграции дисков, восстановления и развертывания систем. Clonezilla Live загружается со сменных носителей и копирует только занятые блоки на поддерживаемых файловых системах, что помогает сохранять размеры образов меньше. Разработчик — Стивен Шиау (Steven Shiau). Платформа — загружаемая среда GNU/Linux live для компьютеров с архитектурой x86 и x86-64. Ценовая модель — бесплатное ПО с открытым исходным кодом.
Первая загрузка прошла успешно, но сеть отсутствовала. Клон сохранил память о физическом адаптере, которого больше не существовало. Первая виртуальная загрузка показала Ubuntu в хорошем состоянии: система дошла до знакомого приглашения входа в систему на мини-ПК. Файловая система, учетные записи пользователей, имя хоста, установленные пакеты Docker и системные службы — все это пережило миграцию. В течение каких-то славных 30 секунд миграция выглядела как полный успех.
Проблемы с сетью и настройка Netplan
К сожалению, сетевое окружение вернуло к суровой реальности, и следующие команды помогли обнаружить проблему:
sudo grep -R . /etc/netplan
ip -br address
Netplan все еще был привязан к физическому MAC-адресу Ethernet устройства NUC f4:4d:30:6a:c5:87. Вместо этого VMware предоставила серверу виртуальный адаптер с именем ens33 и MAC-адресом 00:0c:29:41:3e:b4. Поскольку оборудование, которого ожидала Ubuntu, больше не существовало, ни один интерфейс локальной сети не был настроен.
Перед тем как попытаться исправить это, я создал резервную копию файла Netplan, заменил старый MAC-адрес и сохранил enp3s0 в качестве имени интерфейса, которого теперь ожидал сервер:
match: macaddress: 00:0c:29:4a:e3:b4
set-name: enp3s0
DHCP заработал немедленно, но он назначил IP-адрес 192.168.1.234 вместо исходного адреса .249. Это сразу же нарушило работу сертификатов Caddy, закладок, интеграций n8n и локальных URL-адресов сервисов, так как они уже указывали на 192.168.1.249. Решение оказалось простым: достаточно было снять бронь с адреса .249 в OpenWRT и создать новое бронирование, используя MAC-адрес виртуального сетевого адаптера в VMware.
Финальная перезагрузка доказала, что старый IP-адрес сохранился, а также устранила старую ошибку маршрутизации ntfy, вызванную первоначально назначенным IP-адресом. Наконец, я установил open-vm-tools, и восстановленная система стала чувствовать себя относительно комфортно на виртуализированном оборудовании VMware.
Проверка приложений и автоматизации
Успешная загрузка не была достаточным доказательством успешности миграции. Сервер должен был выполнять ту же реальную работу, что и раньше. Приглашение входа в систему и успешное SSH-соединение доказывали лишь то, что Linux может читать восстановленный диск. Этого было недостаточно, чтобы доказать работоспособность данных приложений, отслеживания и автоматизации.
Я открыл n8n по его исходному HTTPS-адресу и, к счастью, обнаружил, что оба рабочих процесса не только присутствуют, но также живы и выполняются. Их предыдущая история также сохранилась, в то время как Docker автоматически запущен и для n8n, и для ntfy.
Затем я намеренно остановил Homarr на сервере домашней автоматизации (Home Ops), чтобы повторить тест, который проводил перед миграцией на виртуальную машину:
sudo docker stop homarr
Следующее запланированное выполнение рабочего процесса n8n запустилось, обнаружило изменение и отправило уведомление через ntfy и Telegram. Затем я восстановил контейнер:
sudo docker start homarr
Следующее запланированное выполнение обнаружило противоположный переход и отправило сигнал all clear в ntfy и Telegram. Рабочий процесс действительно сохранил свое предыдущее состояние, просто дождался следующего расписания и проследовал по правильным веткам n8n в обоих направлениях.
Убедившись в работоспособности, я создал снимок (snapshot) и на этом закончил работу.
Итоги и ограничения миграции
В целом миграция заняла около 3 часов, причем большую часть этого времени заняло ожидание ползущего по экрану индикатора выполнения. Хотя этот обмен физической машины на виртуальную прошел успешно, миграция в таком направлении все же имеет свои ограничения:
- Она сохраняет устаревшую конфигурацию и весь накопившийся мусор наряду с полезными данными и приложениями.
- Аппаратно-зависимые сетевые настройки, драйверы и лицензии сломаются, если было задействовано много проприетарного оборудования.
- Повторное подключение оригинальной машины создает конфликты имен хостов, MAC-адресов и IP-адресов.
- Полный образ диска не заменяет отдельное резервное копирование приложений.
NUC и сервер автоматизации оказались отличными кандидатами, поскольку Ubuntu использует общую аппаратную поддержку, а ее рабочие нагрузки упакованы в контейнеры. Clonezilla избавила меня от необходимости пересобирать стек автоматизации. VMware подчеркнула все преимущества использования виртуальной машины в первую очередь — такие как возможность создания и отката снимков, а главное — масштабируемость.
Самое важное заключается в том, что физический NUC теперь свободен для роли файлового сервера у рабочего стола, и я могу гораздо эффективнее использовать его аппаратное обеспечение и твердотельный накопитель.
