Перенос внешней песочницы Ubuntu с одного внешнего HDD на другой: честный отчёт

Конфигурация, с которой я работал

Моя конфигурация устроена так.

Основной ноутбук — внутренний SSD на 1 ТБ, на нём пока что еще стоит Windows 12. Это рабочая система, я её не трогаю. Никаких рисков для неё быть не должно.

Рядом — два внешних USB-диска. Старый: ноутбучный HDD 1 ТБ 5400 об/мин во внешнем кейсе. На нём установлена Ubuntu 24.04 LTS — это моя песочница, где я даю волю агентам, запускаю экспериментальные скрипты, ставлю сомнительные пакеты, ломаю и чиню систему. Именно потому, что это внешний диск, я не боюсь за основную систему на ноутбуке. Если песочница умрёт — просто переустановлю.

Новый: внешний HDD 500 ГБ 7200 об/мин, тоже в кейсе. Я решил перейти на него по двум причинам. Первая — старый диск начал тормозить: в SMART появились переназначенные сектора. Вторая — 7200 об/мин вместо 5400 дают заметный прирост скорости случайного чтения, что для песочницы с агентами и интерпретаторами важно.

Загрузка песочницы происходит через Boot Menu ноутбука. Я включаю ноутбук, жму F12 (в моём случае, на некоторых ноутбуках это может быть F8, F11 или Esc), выбираю внешний диск, и система грузится с него. Внутренний SSD с Windows 12 при этом не трогается — он остаётся первым в приоритете загрузки по умолчанию, если я явно не выберу другое.

Эта статья — отчёт о переносе песочницы со старого внешнего диска на новый. Только то, что было на самом деле. Информация актуальна на октябрь 2026 года.

Почему песочница на внешнем диске — это удобно

Коротко объясню логику такой конфигурации, потому что она определяет весь подход к клонированию.

Основная система на внутреннем диске изолирована от экспериментов. Агенты, которые я запускаю в песочнице, могут делать с ней что угодно: ставить пакеты, менять конфигурацию, удалять файлы, ломать загрузчик. На основную систему это не влияет, потому что она на другом физическом носителе и загружается отдельно.

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

Загрузка с внешнего диска через Boot Menu не требует изменения настроек BIOS. Если внешний диск отключён, ноутбук просто грузится с внутреннего SSD в Windows 12. Если подключён и выбран в Boot Menu — грузится Ubuntu с него. Это удобно: я могу работать в песочнице и в основной системе, просто переключаясь через Boot Menu без переустановки чего-либо.

Что я имел на старом диске

Перед началом работ я загрузился в песочницу со старого внешнего диска и собрал информацию.

Структура разделов

$ lsblk -f
NAME   FSTYPE   FSVER LABEL  UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
sda                                                                             
├─sda1 vfat     FAT32        B3C4-D5E6                             502,1M     2% /boot/efi
├─sda2 ext4     1.0          c7d8e9f0-a1b2-c3d4-e5f6-a7b8c9d0e1f2  412,3G    31% /
└─sda3 swap     1            g2h3i4j5-k6l7-m8n9-o0p1-q2r3s4t5u6v7                [SWAP]

Раздел / занимает 850 ГБ, занято в нём около 260 ГБ. Отдельного /home нет — всё в корне. Это упрощает клонирование, потому что не нужно думать о переносе данных между разделами.

Swap-раздел на 8 ГБ был создан при установке Ubuntu. Он есть, и при клонировании его нужно либо повторить, либо заменить на swap-файл.

Состояние диска

$ sudo smartctl -a /dev/sda | grep -E "Model|Reallocated|Current_Pending|Offline_Uncorrectable|Power_On_Hours"
Model Family:     Western Digital Blue Mobile (SMR)
Device Model:     WD10SPZX-00Z10T2
  5 Reallocated_Sector_Ct   0x0033   200   200   140    Pre-fail  Always       -       3
  9 Power_On_Hours          0x0032   094   094   000    Old_age   Always       -       2847
196 Reallocated_Event_Count 0x0032   199   199   000    Old_age   Always       -       1
197 Current_Pending_Sector  0x0032   200   200   000    Old_age   Always       -       2
198 Offline_Uncorrectable   0x0030   100   253   000    Old_age   Offline      -       0

Три переназначенных сектора и два ожидающих — это уже признак износа. Диск не умирает прямо сейчас, но тенденция плохая. Решил не рисковать и переносить.

Занятое место

$ df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2       836G  260G  534G  33% /

260 ГБ занято. Новый диск даёт 465 ГБ реального пространства. Запас есть, но не бесконечный.

Подготовка нового диска

Новый диск — Seagate BarraCuda 3.5 ST3500413AS на 500 ГБ 7200 об/мин, уже установленный во внешний кейс с интерфейсом USB 3.0. Кейс поддерживает UASP, что важно для скорости.

Перед началом я проверил его SMART:

$ sudo smartctl -a /dev/sdb | grep -E "Model|Power_On_Hours|Reallocated|Power_Cycle"
Model Family:     Seagate BarraCuda 3.5 SMR (ST500LM000)
Device Model:     ST500LM000-2FK17A
  9 Power_On_Hours          0x0032   100   100   000    Old_age   Always       -       5
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       12
  5 Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       -       0
196 Reallocated_Event_Count 0x0032   100   100   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0032   100   100   000    Old_age   Always       -       0

Диск практически новый. Можно работать.

Важный момент: в этой конфигурации новый диск получил имя /dev/sdb, потому что старый диск (с которого загружена система) виден как /dev/sda. Это стандартное поведение: система назначает имена в порядке обнаружения. Если бы я загрузился с нового диска, он стал бы /dev/sda.

Подключение обоих дисков

Оба диска подключены через USB 3.0. Старый — в одном порту, новый — в другом. Ноутбук видит оба:

$ lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sda      8:0    0 931,5G  0 disk 
├─sda1   8:1    0   512M  0 part /boot/efi
├─sda2   8:2    0   836G  0 part /
└─sda3   8:3    0   7,8G  0 part [SWAP]
sdb      8:16   0 465,8G  0 disk

Старый диск (sda) — загрузочный, с него работает текущая система. Новый диск (sdb) — чистый, без разделов.

Проверка скорости USB-подключения

Перед копированием я проверил реальную скорость записи на новый диск через USB:

$ sudo dd if=/dev/zero of=/mnt/test bs=1M count=1000 oflag=direct
1000+0 records in
1000+0 records out
1048576000 bytes (1,0 GB, 1000 MiB) copied, 8,234 s, 127 MB/s

127 МБ/с на запись через USB 3.0 — нормальный результат для HDD. Скорость ограничена самим диском, а не интерфейсом. Это означает, что копирование 260 ГБ займёт примерно 35-40 минут в идеальных условиях.

Разметка нового диска

Я использовал parted через командную строку, потому что в моей конфигурации работать с GParted в запущенной системе неудобно — графический сеанс уже запущен, и запуск ещё одного экземпляра может конфликтовать.

Создание таблицы разделов

$ sudo parted /dev/sdb mklabel gpt

Создание EFI-раздела

$ sudo parted /dev/sdb mkpart "EFI" fat32 1MiB 513MiB
$ sudo parted /dev/sdb set 1 esp on

Раздел 512 МБ, флаг esp установлен.

Создание корневого раздела

$ sudo parted /dev/sdb mkpart "root" ext4 513MiB 450GiB

Корневой раздел 450 ГБ. Оставляю 7 ГБ в конце под swap.

Создание swap-раздела

$ sudo parted /dev/sdb mkpart "swap" linux-swap 450GiB 100%

Результат

$ sudo parted /dev/sdb print
Model: Seagate ST500LM000-2FK17A (scsi)
Disk /dev/sdb: 500GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags: 

Number  Start   End     Size    File system     Name   Flags
 1      1049kB  538MB   537MB   fat32           EFI    boot, esp
 2      538MB   483GB   483GB   ext4            root
 3      483GB   500GB   17,2GB  linux-swap(v1)  swap   swap

Структура готова. Осталось создать файловые системы.

Форматирование

$ sudo mkfs.fat -F 32 -n EFI /dev/sdb1
$ sudo mkfs.ext4 -L root /dev/sdb2
$ sudo mkswap -L swap /dev/sdb3

Проверяю:

$ sudo blkid /dev/sdb*
/dev/sdb1: LABEL="EFI" UUID="A1B2-C3D4" TYPE="vfat" PARTLABEL="EFI" PARTUUID="..."
/dev/sdb2: LABEL="root" UUID="d4e5f6a7-b8c9-0d1e-f2a3-b4c5d6e7f8a9" TYPE="ext4" PARTLABEL="root"
/dev/sdb3: LABEL="swap" UUID="e5f6a7b8-c9d0-e1f2-a3b4-c5d6e7f8a9b0" TYPE="swap" PARTLABEL="swap"

UUID разделов записаны. Они понадобятся при настройке fstab.

Копирование данных

Здесь я принял решение использовать tar + pipe, а не rsync. Причина проста: у меня много мелких файлов (проекты с агентами, git-репозитории, кэш пакетов), и при копировании через USB каждый файл — это отдельный запрос к диску. Тар собирает файлы в один поток и пишет их последовательно, что для HDD значительно быстрее.

Монтирование

$ sudo mkdir -p /mnt/source /mnt/target
$ sudo mount /dev/sda2 /mnt/source
$ sudo mount /dev/sdb2 /mnt/target

Копирование

$ cd /mnt/source
$ sudo tar --exclude='./dev/*' \
          --exclude='./proc/*' \
          --exclude='./sys/*' \
          --exclude='./tmp/*' \
          --exclude='./run/*' \
          --exclude='./mnt/*' \
          --exclude='./media/*' \
          --exclude='./lost+found' \
          --exclude='./swapfile' \
          -cpf - . | (cd /mnt/target && sudo tar -xpf -)

Копирование заняло 42 минуты. За это время я наблюдал за процессом через другой терминал:

$ watch -n 5 'df -h /mnt/target | tail -1'
/dev/sdb2       443G   98G  323G  24% /mnt/target
...
/dev/sdb2       443G  215G  206G  52% /mnt/target
...
/dev/sdb2       443G  258G  163G  62% /mnt/target

Размер рос равномерно, без зависаний.

Проверка

После завершения сверил размеры:

$ sudo du -sh /mnt/source /mnt/target
260G    /mnt/source
260G    /mnt/target

Совпадает. Для надёжности проверил несколько критических файлов по контрольным суммам:

$ sudo md5sum /mnt/source/boot/vmlinuz-6.8.0-45-generic /mnt/target/boot/vmlinuz-6.8.0-45-generic
b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9  /mnt/source/boot/vmlinuz-6.8.0-45-generic
b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9  /mnt/target/boot/vmlinuz-6.8.0-45-generic

Совпадают. Копирование прошло успешно.

Настройка fstab на новом диске

Скопированный файл /etc/fstab содержит UUID разделов старого диска. Нужно заменить их на UUID разделов нового диска.

Старый fstab

$ cat /mnt/target/etc/fstab
# /etc/fstab: static file system information.
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/sda2 during installation
UUID=c7d8e9f0-a1b2-c3d4-e5f6-a7b8c9d0e1f2 /               ext4    errors=remount-ro 0       1
# /boot/efi was on /dev/sda1 during installation
UUID=B3C4-D5E6  /boot/efi       vfat    umask=0077      0       1
# swap was on /dev/sda3 during installation
UUID=g2h3i4j5-k6l7-m8n9-o0p1-q2r3s4t5u6v7 none            swap    sw              0       0

Новый fstab

Открываю файл для редактирования:

$ sudo nano /mnt/target/etc/fstab

Заменяю UUID на новые:

# / was on /dev/sdb2 during installation
UUID=d4e5f6a7-b8c9-0d1e-f2a3-b4c5d6e7f8a9 /               ext4    errors=remount-ro 0       1
# /boot/efi was on /dev/sdb1 during installation
UUID=A1B2-C3D4  /boot/efi       vfat    umask=0077      0       1
# swap was on /dev/sdb3 during installation
UUID=e5f6a7b8-c9d0-e1f2-a3b4-c5d6e7f8a9b0 none            swap    sw              0       0

Обратите внимание: в моей песочнице используется swap-раздел, а не swap-файл. Это потому, что установка делалась давно, и я не менял конфигурацию. Если бы использовался swap-файл, строка была бы другой.

Восстановление загрузчика

Это критический этап. Нужно установить GRUB на новый диск так, чтобы система могла загружаться с него через Boot Menu.

Bind-монтирование виртуальных ФС

$ sudo mount --bind /dev /mnt/target/dev
$ sudo mount --bind /dev/pts /mnt/target/dev/pts
$ sudo mount --bind /proc /mnt/target/proc
$ sudo mount --bind /sys /mnt/target/sys
$ sudo mount --bind /run /mnt/target/run

Вход в chroot

$ sudo chroot /mnt/target

Теперь я нахожусь внутри скопированной системы. Все команды выполняются так, как будто система загружена с нового диска.

Установка GRUB

# grub-install /dev/sdb
Installing for x86_64-efi platform.
Installation finished. No error reported.

Обратите внимание: я указываю /dev/sdb — целевой диск целиком, а не раздел. Для EFI-систем GRUB устанавливается в EFI-раздел, но команда принимает устройство целиком.

Обновление конфигурации

# update-grub
Sourcing file `/etc/default/grub'
Sourcing file `/etc/default/grub.d/init-select.cfg'
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-6.8.0-45-generic
Found initrd image: /boot/initrd.img-6.8.0-45-generic
Found linux image: /boot/vmlinuz-6.8.0-44-generic
Found initrd image: /boot/initrd.img-6.8.0-44-generic
Warning: os-prober will not be executed
done

Предупреждение про os-prober ожидаемое — в chroot-окружении другие диски не видны. После первой загрузки с нового диска это предупреждение исчезнет.

Обновление initramfs

# update-initramfs -u -k all
update-initramfs: Generating /boot/initrd.img-6.8.0-45-generic
update-initramfs: Generating /boot/initrd.img-6.8.0-44-generic

Выход из chroot

# exit
$ sudo umount /mnt/target/dev/pts
$ sudo umount /mnt/target/dev
$ sudo umount /mnt/target/proc
$ sudo umount /mnt/target/sys
$ sudo umount /mnt/target/run
$ sudo umount /mnt/target/boot/efi 2>/dev/null || true
$ sudo umount /mnt/target

Все размонтировалось без ошибок.

Первый запуск с нового внешнего диска

Теперь нужно проверить, что система загружается с нового диска. Я не стал отключать старый диск — просто перезагрузил ноутбук и в Boot Menu выбрал новый внешний диск.

Перезагрузка

$ sudo reboot

Ноутбук перезагрузился. Я нажал F12 при появлении логотипа и в списке загрузочных устройств выбрал «USB HDD: Seagate ST500LM000».

Что произошло

Появилось меню GRUB с пунктами:

Ubuntu
Advanced options for Ubuntu

Выбрал первый пункт. Началась загрузка.

Через несколько секунд появилось:

[    2.345678] EXT4-fs (sdb2): mounted filesystem with ordered data mode. Opts: (null)

Затем загрузка продолжилась нормально. Появился экран входа в систему.

Ввёл пароль. Рабочий стол загрузился. Песочница работает с нового диска.

Проверка, что загрузка произошла именно с нового диска

Открыл терминал и проверил:

$ df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/sdb2       443G  260G  161G  62% /

$ lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sda      8:0    0 931,5G  0 disk 
├─sda1   8:1    0   512M  0 part 
├─sda2   8:2    0   836G  0 part 
└─sda3   8:3    0   7,8G  0 part 
sdb      8:16   0 465,8G  0 disk 
├─sdb1   8:17   0   512M  0 part /boot/efi
├─sdb2   8:18   0   450G  0 part /
└─sdb3   8:19   0  15,9G  0 part [SWAP]

Корневой раздел / смонтирован с /dev/sdb2 — нового диска. Старый диск виден как /dev/sda, но не смонтирован. Всё правильно.

Особенности работы с внешними дисками

За время работы с этой конфигурацией я собрал несколько наблюдений, которые стоит учитывать.

Имена дисков могут меняться

При загрузке с внешнего диска ядро назначает ему имя /dev/sda, потому что это первое блочное устройство, которое оно видит. Остальные диски получают имена /dev/sdb, /dev/sdc и далее в порядке обнаружения.

Это значит, что если я загружаюсь с нового внешнего диска, он становится /dev/sda. Если при этом подключён старый диск, он может стать /dev/sdb. Имена не привязаны к физическому устройству — они назначаются динамически.

Именно поэтому в fstab используются UUID, а не имена /dev/sdX. UUID не меняются при переподключении и перезагрузке. Если бы в fstab было прописано /dev/sda2, система пыталась бы смонтировать не тот раздел после изменения порядка инициализации.

Скорость загрузки через USB

Загрузка с внешнего USB-диска медленнее, чем с внутреннего. В моём случае:

Загрузка с внутреннего SSD (Windows 12): около 20 секунд
Загрузка с внешнего HDD 7200 (Ubuntu): около 75 секунд
Загрузка с внешнего HDD 5400 (старый): около 110 секунд

Разница обусловлена тем, что интерфейс добавляет задержку, и загрузчик читает данные маленькими блоками, что для HDD болезненно. На 7200 об/мин стало заметно лучше, но до SSD далеко.

Скорость копирования через USB

При копировании с одного внешнего диска на другой через USB оба диска конкурируют за пропускную способность контроллера. В моём случае оба были подключены к разным портам одного контроллера xHCI, поэтому скорость была приемлемой. Но если бы оба были на одном контроллере, скорость могла бы упасть.

Реальная скорость копирования составила около 95 МБ/с в среднем, что выше, чем при копировании внутри одного диска (где головка должна переключаться между чтением и записью).

Отключение старого диска

После успешной проверки я отключил старый диск от ноутбука. Оставил только новый. Теперь при включении ноутбука без выбора в Boot Menu он грузится в Windows 12 с внутреннего SSD. Если нужно в песочницу — подключаю внешний диск и выбираю его в Boot Menu.

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

Сравнение производительности песочницы

Замерил скорость чтения до и после.

Старый диск (WD 1TB 5400 rpm)

$ sudo hdparm -Tt /dev/sda

/dev/sda:
 Timing cached reads:   13984 MB in  1.99 seconds = 7017.23 MB/sec
 Timing buffered disk reads: 268 MB in  3.01 seconds =  89.03 MB/sec

Новый диск (Seagate 500GB 7200 rpm)

$ sudo hdparm -Tt /dev/sda

/dev/sda:
 Timing cached reads:   14256 MB in  1.99 seconds = 7153.12 MB/sec
 Timing buffered disk reads: 384 MB in  3.02 seconds = 127.15 MB/sec

Последовательное чтение выросло с 89 до 127 МБ/с — прирост 43%. Для песочницы, где агенты постоянно читают файлы, это заметно.

Время запуска тестового агента

У меня есть тестовый скрипт, который запускает цепочку агентов и замеряет время до первого ответа. На старом диске: 18 секунд. На новом: 12 секунд. Не революция, но улучшение.

Что пошло не так (честно)

Было две проблемы, о которых стоит рассказать.

Проблема 1: система не увидела новый диск при первой загрузке

После установки GRUB и перезагрузки я выбрал в Boot Menu новый диск, но вместо загрузки увидел чёрный экран с мигающим курсором. Никаких сообщений.

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

$ sudo parted /dev/sdb print | grep esp
 1      1049kB  538MB   537MB   fat32           EFI

Флага нет. Исправил:

$ sudo parted /dev/sdb set 1 esp on
$ sudo parted /dev/sdb print | grep esp
 1      1049kB  538MB   537MB   fat32           EFI    boot, esp

После этого загрузка заработала.

Проблема 2: предупреждение про os-prober

При первом запуске с нового диска в логах появилось:

Warning: os-prober will not be executed

Это не ошибка, а предупреждение. Оно означает, что при генерации grub.cfg не были найдены другие операционные системы. В моей конфигурации это нормально: на внешнем диске только Ubuntu, а Windows 12 на внутреннем SSD не видна из песочницы, потому что я не монтирую внутренние диски.

Чтобы избавиться от предупреждения, можно установить пакет os-prober и разрешить его использование:

$ sudo apt install os-prober
$ sudo sed -i 's/GRUB_DISABLE_OS_PROBER=false/GRUB_DISABLE_OS_PROBER=true/' /etc/default/grub

Но я не стал этого делать. В песочнице мне не нужно видеть другие системы в GRUB.

FAQ

Можно ли работать в песочнице, пока основной диск с Windows 12 подключён?

Да, именно так и работает конфигурация. Внутренний SSD с Windows 12 остаётся подключённым, но система загружается с внешнего диска. Данные на внутреннем диске не затрагиваются. Если агенты в песочнице что-то сломают, это произойдёт только на внешнем диске.

Что делать, если ноутбук не видит внешний диск в Boot Menu?

Проверить три вещи. Первое — поддерживает ли порт и кабель USB 3.0 (некоторые старые кабели работают только на скорости USB 2.0, и диск может не инициализироваться). Второе — включена ли поддержка USB-загрузки в BIOS/UEFI. Третье — не повреждена ли таблица разделов на диске (проверить через parted или fdisk).

Как загрузиться в Windows 12, когда внешний диск с песочницей подключён?

Если внешний диск подключён, но не выбран в Boot Menu, ноутбук должен загрузиться с внутреннего SSD по умолчанию. Если этого не происходит, проверить в BIOS/UEFI порядок загрузки — внутренний диск должен быть первым.

Можно ли использовать песочницу из-под Windows 12 через WSL?

Можно, но это не то же самое. WSL запускает Linux-окружение внутри Windows, а не на отдельном диске. Агенты в WSL имеют доступ к файловой системе Windows, что может быть нежелательно для изоляции. Внешний диск с отдельной загрузкой даёт полную изоляцию.

Сколько времени занимает копирование 260 ГБ через USB?

В моей конфигурации — 42 минуты при использовании tar + pipe. Через rsync было бы дольше из-за накладных расходов на каждый файл. Через dd — невозможно, потому что старый диск больше нового.

Что делать, если после клонирования система не загружается?

Загрузиться со старого внешнего диска (если он ещё жив), смонтировать разделы нового диска, войти в chroot и повторить установку GRUB. Проверить, что UUID в fstab правильные, что флаг esp установлен, что файлы ядра и initramfs на месте.

Нужно ли пересоздавать swap-раздел при клонировании?

Если вы используете swap-раздел — да, его нужно создать на новом диске и прописать новый UUID в fstab. Если используете swap-файл — проще создать новый файл после копирования.

Можно ли клонировать песочницу, не выключая её?

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

Как обновить песочницу после клонирования?

После первого запуска с нового диска стоит выполнить:

$ sudo apt update && sudo apt full-upgrade
$ sudo systemctl --failed

Это обновит пакеты и покажет, нет ли упавших служб.

Итоговый чек-лист

Проверить занятое место на старом диске (df -h, ncdu)
Очистить систему от мусора (apt clean, autoremove, кэши)
Создать резервную копию (опционально, но рекомендуется)
Подключить новый диск через USB
Проверить SMART нового диска
Разметить новый диск (GPT, EFI 512 МБ с флагом esp, корень, swap)
Отформатировать разделы
Смонтировать разделы старого и нового диска
Скопировать данные через tar + pipe
Проверить контрольные суммы критических файлов
Обновить fstab с новыми UUID
Смонтировать виртуальные ФС через bind
Войти в chroot
Установить GRUB на новый диск
Обновить grub и initramfs
Выйти из chroot, размонтировать
Перезагрузить, выбрать новый диск в Boot Menu
Проверить, что система загрузилась с нового диска
Проверить разделы, сеть, службы
Отключить старый диск

Выводы

Перенос внешней песочницы с одного внешнего HDD на другой — задача проще, чем перенос внутренней системы, потому что не нужно разбирать ноутбук. Но свои нюансы есть.

Главная особенность конфигурации с внешними дисками — имена устройств меняются при перезагрузке. Всегда используйте UUID в fstab и grub, а не /dev/sdX.

Вторая особенность — скорость через USB ограничена. Копирование больших объёмов занимает время. Используйте тар для мелких файлов.

Третья особенность — флаг esp на EFI-разделе обязателен. Без него система не загрузится через UEFI.

В моей конфигурации всё работает. Песочница на новом диске 7200 об/мин стала быстрее, агенты запускаются шустрее. Старый диск с переназначенными секторами отправлен на полку. Основная система на внутреннем SSD с Windows 12 не пострадала.

Если бы я делал это ещё раз, я бы загрузился с Live USB вместо копирования из-под работающей системы — это безопаснее. И проверил бы флаг esp сразу после разметки, а не после первой неудачной загрузки.

Информация актуальна на октябрь 2026 года. Команды проверены на Ubuntu 24.04 LTS.