rsync -a, chroot + grub-install

Нет нужды насиловать dd диски.

rsync -aHAXS

Если бы была FreeBSD, то мог бы воспользоваться стандартной процедурой dump/restore для полного и безопасного копирования данных. А на Linux форматируй SSD в XFS и просто скопируй содержимое HDD на SSD, воспользовавшись режимом восстановления (когда нет запущенных важных сервисов), или загрузившись с Live-USB.

• Подключить SSD через USB.
• rsync с текущей системы на SSD.
• chroot && grub-install, если необходимо.
• Поправить UUID в /etc/fstab, если необходимо.
• Вставить SSD в ноутбук.

Это ключи для заливки на NFS, как я понял?

Сохранение хардлинков, расширенных атрибутов...

А не проще сначало в поиск? Полно прог типа hdd to ssd

Зачем проги, если можно нативными утилитами.

Зато с гуем и удобно.

А на Linux форматируй SSD в XFS

Уржаться. Впрочем, ты в своём репертуаре... Только непонятно, почему не ZFS. :-)

Я хорошо придумал, или лучше как-то иначе?

Если у тебя старый hdd с 4K сектором, то пойдёт, если там разделы выровнены. Если же на hdd сектор 512b, то правильнее (точнее даже жизненно необходимо для ssd - у ssd точно 4K сектор) разбить ssd примерно так же на разделы с выравниванием по границе сектора (хотя это автоматом все утилиты уже умеют, наверное), а потом уже как тут подсказали про rsync. Потом загрузчик переустановить. С dd загрузчик переустанвлиать не надо.

https://clonezilla.org/

Только непонятно, почему не ZFS.

Потому что ZFS на Linux требуется большей квалификации пользователя, чем обращение с классической ФС, поддержанной вендором дистрибутива. К тому же, XFS умеет dump/restore - пригодится в будущем.

Уржаться. Впрочем, ты в своём репертуаре...

Ага, уржаться - dump/restore как раз для переезда очень удобен, потому что реализован на уровне ФС и «перевезет» все доп. аттрибуты и расширения, в отличие от tar.
У вас тоже когда-то так можно было:
http://surf.ml.seikei.ac.jp/~nakano/dump-restore/dump-restore-mini-HOWTO.en.html
Но потом стало «ненужно» и «оно устарело!»
На самом деле в пингвине 2.4 дооптимизировались до того, что в режиме RW ФС в любом случае консистентно было уже не прочитать, а приделать соотв. механизм в ФС (как бздшники - ага, супир-пупир-гордость-бтрфнутых-фичу снапшотов добавили в UFS в 2000 году) или хотя бы обеспечить возможность работы в RO почему-то постеснялись. Вместо этого порекомендовав tar (у которого, помимо прочих исторических недостатков, при чтении с RW ФС все те же проблемы, разве что забекапить неконсистентые метаданные ФС им не получится - «только» сами файлы).
В общем да, прям «уржаться» с лапчатых и их тяге к выкидыванию вылизанного и проверенного и переизобретанию с нуля :)

фу как грубо, есть же сквош-тулз

Есть полезная утилита - fsarchiver Последнее время пользуюсь ей для переноса с диска на диск или SSD. Может, среди прочего делать архив на живой системе (который смонтирован rd/wr)

«перевезет» все доп. аттрибуты

Ничего против dump/restore не имею.
Но вот xattrs - это путь в никуда. Скоро (можно сказать уже) в этих xattrs будет больше информации, чем в самом файле. Не файловая система, а какая-то атрибутная система. Удобное место для того, чтобы припрятать что-нибудь (зловредное). Темная энергия, темная материя, браны, струны, ntfs-потоки.

потому что реализован на уровне ФС и «перевезет» все доп. аттрибуты

Дополнительные атрибуты (расширенные же, правда?) - это не фича в Linux. Потому, если ты EA задействовал, то уж сам догадаешься, как переехать.

Остальная вода в комментариях не нуждается.

Потому, если ты EA задействовал, то уж сам догадаешься, как переехать. Остальная вода в комментариях не нуждается.

Да-да, пофиг на удобство, изкоробочную согласованность данных, простоту бэкапов и переезда. Все вода. «Оно ненужно! НЕНУЖНО, я говорю!» - как я и написал :)

Да-да, пофиг на удобство, изкоробочную согласованность данных, простоту бэкапов и переезда.

Простота переезда не меняется никак. Вообще никак.

Тем более, что переезд — это крутейший бэкап, который не надо хранить, а проверка работоспособности будет произведена автоматически :)

А если по теме, то как учили отцы: tar cf - dirs... | ( cd new_root; tar xf - ) — работает до сих пор, сохраняя все консистетно с hardlink-ами, естественно при загрузки в r/o

У меня LVM-разметка на HDD, небольшой корень, своп, большой хомяк. Я выключил ноут, вытащил hdd, воткнул его в USB. На штатное место установил SSD и собрал ноут. Загрузися с HDD(USB), создал boot и пустой раздел на новом. Сделал pvcreate, vgextend; сделал pvmove, vgreduce. Отсоединил HDD от usb. Магия? Не забудь подшаманить fstab и grub всё таки: какие-то пару мест пришлось поправить руками.

PS. SSD и hdd были примерно равны по объему. Можно пошаманить с архивацией home отдельно, если с размером проблемы. Но систему вышеуказанным образом пенерести проще всего

PPS. Про бекапы не забывай, конечно. Я все это без дрожи в руках делал ибо пробекапил накануне

Clonezilla

На так давно переезжал.

Загрузился с Clonezilla Live.

Создал образ своего HDD на съемном диске.

Вытащил HDD и установил на его место SSD.

Загрузился с Clonezilla Live и восстановил образ диска на SSD (в режиме эксперта дополнительно выбрал [-icds] «пропустить проверку размера целевого диска перед созданием таблицы разделов» + «использовать таблицу разделов из образа».

Всё.

сохраняя все консистетно

Сохраняя может и консистентно, но вот читая RW FS «как получится».

Сохраняя может и консистентно, но вот читая RW FS «как получится».

При переезде неконсистентность изменяемых данных по барабану. Тебе домашнее задание понять, почему так.

но вот читая RW FS «как получится».

А дочитать еще пару слов сил не хватило? При RW ничего не может гарантировать, даже если в ядре будет спец интерфейс для такого «бэкапа». Есть еще состояния пользовательских процессов, которые принципиально, то есть филосовски, не могут сделать консистентность, как бы ни обмазывались транзакциями. Ибо иначе ничего нельзя было б делать, кроме логов.

mount и cp -ax достаточно

Но вот xattrs - это путь в никуда.

Концептуально не согласен. Это удобно — например, прописать для документов автора, тему и прочее или дату последнего бэкапа или … в общем, все то, что сейчас хранится или рядышком в txt файле или в отдельной БД непоймуков и калибров. И не надо кивать на известных извращенцев и оверинжинеров из МС - извратить можно что угодно.
По сути, это список ключ-значение, напрямую привязанный к файлу. Примерно то же самое было бы, если договорится и принят стандарт на «filename.additionalinfos».
Другое дело, что оно хоть и появилось давно, но на поддержку упорнейше забивали (копирование, бэкапы/архивы, поиск и прочее), так что никто не заморачивался использованием. А теперь уже и поздновато проталкивать - слишком простой, кроссплатформенный и логичный концепт, а значит не модно. Скорее изобретут очередной systemd-xtradata-on-patched-btrfs-for-docker-in-flatpack-with-mysqldbd.

При переезде неконсистентность изменяемых данных по барабану.

Не, круче. Переезд — самое время, когда можно обновить систему. :) И потому надо сохранять не образы и прочее, а только хомяки и настройки. И то в виде копии для кропотливого ручного рассмотрения и copy-paste, а не тупо на замену. :(

Это удобно — например, прописать для документов автора, тему и прочее или дату последнего бэкапа или …

Или сделать пустой файл исполняемый, который, внезапно, что-то делает...

При переезде неконсистентность изменяемых данных по барабану.
по барабану

Какой оригинальный эвфемизм для «не нужно!»

Тебе домашнее задание понять, почему так.

Тебе домашнее задание написать 100 раз «нинужна!»
А потом еще раз перечитать внимательно и глазками - речь не о нужности-ненужности, а о наличии/отсутвии консистентности.

Или сделать пустой файл исполняемый, который, внезапно, что-то делает...

Проблемы индейцев-вантузоводов шерифа …

И не надо кивать на известных извращенцев и оверинжинеров из МС - извратить можно что угодно.

А потом еще раз перечитать внимательно и глазками

Тебе второе домашнее задание: прочитать тему. И третье: придумай, зачем в то время могло потребоваться дублирование на уровне ФС функционала LVM.

Проблемы индейцев-вантузоводов шерифа …

Ты так молод, что не знаешь про OS/2 ? :-)

А дочитать еще пару слов сил не хватило?

А, вижу r/o. Ну извини, тем более, выглядит как дополнительное ограничение вкупе с этим вашим таром — дополнительно все отключать в ro. Просто запустить дамп в фоне как-то удобнее. Ну и всякие birth-time плюс доп. флаги (chattrs) оно сохраняет.

При RW ничего не может гарантировать, даже если в ядре будет спец интерфейс для такого «бэкапа».

Вообще-то могут. Для этого и сделали снапшоты в «не COW FS» - обеспечить консистентность на уровне ФС, плюс всех тех приложений, кто не «проигнорил» сигнал на синхронизацию. Данные-то считываются с примонтированного снапшота, который в тот момент «RO». Другое дело, что на практике проблемы обычно только с тазами банных и прочими тырпрайзоподбными монстроидами.

С полной копией последний пункт не нужен. Только когда прошивка с UEFI записи о efi загрузчике grub потрёт, заметив отсутствие диска.

Ещё большие данные на меньший носитель не запихнуть, конечно. Кроме маловероятных проблем с выравниваем, есть реальная проблема с TRIM/discard, т.к. будут скопированы даже бессмысленные данные. Стоит пройтись по всем ФС и свободному месту.

Или сделать пустой файл исполняемый, который, внезапно, что-то делает

Проблемы индейцев-вантузоводовполувантузоводов шерифа …

Ты так молод, что не знаешь про OS/2 ? :-)

Не юли.

Я например просто воссоздал те же разделы что были и на hdd, тот же lvm, всё примонтировал, перекинул файлы, подключив ssd через юсб. Потом переткнул ssd в ноут, загрузился с него. Ну где-то там заменил uuid и заинсталлил grub.

Не юли.

Про тему ты забыл, понятно. И про LVM.

Про тему ты забыл, понятно. И про LVM.

LVM, которая уровнем ниже? Это в соседнюю ветку. На обсуждение ты забИл, понятно.
Тема/оффтоп этой ветки вообще-то были EA.
Неужели так сложно если не следить за самой веткой и рефами ответво, то хотя смотреть, что в ответе цитировалось?

Но вот xattrs - это путь в никуда.

Концептуально не согласен.
... извратить можно что угодно.

Чем меньше всяких «что угодно» (например, xattrs), тем меньше извращений. Xattrs - это метаданные, они не должны иметь значения для пользователя данных. Если без xattrs данные теряют смысл для пользователя, то xattrs - это тоже данные и надо пересмотреть формат данных, чтобы данные сохранялись в содержимом файла, а не в метаданных. Наизвращались над данными и метаданными. Cкоро жабаскриптеры файловую систему в неструктурированную key-value бд переделают. В общем, по классике: «Смешались в кучу кони, люди» (с) Лермотов, кажись.

LVM, которая уровнем ниже?

Да. И которой по барабану, какая ФС сверху. Нужны были снапшоты? Использовали LVM. Грузить этим ФС во времена тёплых ламповых компьютеров было явно чрезмерно.

Тема/оффтоп этой ветки вообще-то были EA.

Это ты так решил почему-то. Но твоё мнение, в данном вопросе, разбивается о «Переезд с HDD на SSD без потери ОС». Увы и ах.

Неужели так сложно если не следить за самой веткой

Тебе, очевидно, да.

Cкоро жабаскриптеры файловую систему в неструктурированную key-value бд переделают.

Только появились расширенные аттрибуты еще до ЖС, так что привычное «это могли придумать только жабоскритозники» — не катит.

Если без xattrs данные теряют смысл для пользователя, то xattrs - это тоже данные и надо пересмотреть формат данных, чтобы данные сохранялись в содержимом файла, а не в метаданных

Это теория. На практике у нас туева хуча форматов, легаси и прочее, не умеющее сохранять желаемое.
И документ без метаданных типа subj/author или «забэкаленно: вчера, на: зеракало3» не теряет смысл, просто с ним возиться неудобнее. Зато сама реализация аттрибутов доволно проста и зело универсальна, а не 1000 программ, каждая со своим БД и несовместимыми форматами, типа калибры, непоймуков и прочего. Еще и прекрасно с ls, grep, find и т.д. взаимодействовать можно (было бы).

Тема/оффтоп этой ветки вообще-то были EA.

Это ты так решил почему-то. Но твоё мнение, в данном вопросе, разбивается о «Переезд с HDD на SSD без потери ОС». Увы и ах.

Что, старость не радость — читать целыми предложениями трудно, а удерживать внимание более 5 минут склероз мешает? Сочувствую.

Это удобно — например, прописать для документов автора, тему и прочее или дату последнего бэкапа или …

Или сделать пустой файл исполняемый, который, внезапно, что-то делает...
AS ★★★★★

Метаданные появились раньше данных (имя файла, биты чтения/записи, владелец и тп). Но они не должны вылезать за пределы хранилища, так как вне конкретного хранилища эти данные не имеют значения (не должны иметь значения). Поэтому или ты дампаешь хранилище со всеми метаданными не имея понятия, что за данные там хранятся; или архивируешь данные с новыми метаданными архива и теряешь метаданные хранилища (вплоть до других имен директорий и файлов).
Выполняемый файл на одной системе не должен быть выполняемым на другой, без придания ему смысла через действие «установка программы» или аналога. Отдельный привет запускателям скачанных из интернета программ «СашаКрей.jpg.exe». Напомню, имя файла - это метаданные. Вот такие извращения от переизбытка «чего угодно». Тоже про несоответствие владельцев для разных систем (хранилищ) и что было бы, если эти метаданные напрямую отображались из одной системы на другую. Также весело когда программы меняют метаданные совместно использумах файлов (необязательно одновремено используемых). Раз такие наглые, чего имя файла не меняют, разрешения, владельца(тоже метаданные)? Как согласовать их поведение, ведь они не меняют сами данные? Что за дискриминация по типам метаданных?
Поэтому введение новых метаданных должно быть обоснованно с точки зрения системы/хранилища, а не с точки зрения пользователя данных. Данные пользователя должны быть данными, метаданные - для системы.

читать целыми предложениями трудно, а удерживать внимание более 5 минут склероз мешает?

Чья б корова мычала... Человек интересуется конкретным вопросом, а у тебя недержание своей идеи неуместной. :-)

твои отцы не видели приличного юникса? ибо в каждом есть dump/restore и таром пользуются только неучи.

снапшоты - это solaris 8, например.

Грузить этим ФС во времена тёплых ламповых компьютеров было явно чрезмерно.

вот чтоб ты ещё знал за них что-нибудь.

твои отцы не видели приличного юникса? ибо в каждом есть dump/restore и таром пользуются только неучи.

Вы, простите, с какого юникса начинали? Я с 3BSD, в 86 году. dump/restore это — дамп, то есть разменивал скорость его создания на ненужный объём. Никакому приличному юниксу не надо было прятать не в файлах какую-то (лицензионную) информацию, эти страдал только dos. Потому бэкапы для хранения как и инсталляторы делались tar-ом, ибо хранить несколько версий только измененного гораздо полезнее, чем полные дампы, начиная с цены этого хранения. Впрочем, в те времена количество разных типов дисков было по пальцам пересчитать, потому основная копия вначале делалась dd-шкой и её аналогом (rollup) на ленту, с которой можно было даже загрузиться. Но это скорее всего было «подменкой» на случай выхода из строя и переписывался в следующую профилактику машины, для длительного хранения с несколькими версиями на диски это было весьма накладно.

Я с 3BSD, в 86 году.

молодец, только х*ле толку, коли ты даже элементарных вещей не знаешь?

dump/restore это — дамп, то есть разменивал скорость его создания на ненужный объём.

это дамп файловой системы, которая, внезапно, знает какие блоки заняты, а какие нет, в отличии от упомянутого тобой dd, это раз. точно так же позволяет указать (не)нужные файлы и каталоги, это джва. и даже, о чудо, умеет в инкременталы. так что вывод напрашивается сам по себе.

пользуясь случаем, хочу передать привет пожелать модераторам капчу на дверь в туалет, а также на кухню и холодильник.