Очередной о резервном копировании

man losetup

man resize2fs

man parted

Нет ни сего лучше проверки на практике.
Сделал, залил и запустил.
Груб есть, загрузка заканчивается криком о том повреждение таблицы, что физически супер блоков меньше чем в таблице.
Загрузился с лайва, resize2fs не работает, посылает в e2fsck, и так по кругу.

монтируй образ и вынимай из него данные.

Ну эт ясно, просто думал может можно какой утилитой воспользоваться как если залить мальнекий образ на большой диск.

Ну вы же не знаете в каком месте диска физически находились данные, без разницы, что у вас занято 50 Гб из 200, возможно, что большая часть данных находится в начале диска, а некоторая часть, например, в последних 50 Гб, т.е. начиная со 150 Гб и до конца физической ёмкости диска, это раз.

Два, это то, что у вас будет не целая файловая система, у вас же не просто ячейки, в которые вы «сыплете» данные, а логическая структура, которую нельзя просто взять и обрезать без внесения изменений в эту структуру. Т.е., если вы хотите перенести файловую систему на раздел меньшей ёмкости, то вам нужно в начале с помощью утилит изменения размера логический структуры (файловой системы) уменьшить её размер, в этом случае будут изменены данные, описывающие параметры этой структуры, суперблок файловой системы, и перемещены данные, в случае, если они находятся за пределами области нового размера файловой системы.

В общем вам посоветовали правильно, монтируйте образ файловой системы (диска), можете воспользоваться losetup с указанием смещения относительно начала образа, что бы получить loop устройства, указывающие на начала разделов (файловых систем) или сразу воспользоваться mount с опцией '-o offset'

Да, система будет не рабочей. ФС вправе использовать любые блоки, причём размер задаётся в заголовке ФС и если окажется, как в вашем случае, что ФС больше, чем блочное устройство (раздел диска), то даже если повезёт и нужные файлы будут физически присутствовать, любая запись на ФС может выйти за границу раздела и будет ошибка.

ИМХО, tar нормальный вариант, но в некотрых дистрибутивах у файлов есть расширенные атрибуты (selinux, capabilities, acl, ext2 file attr) и привильность их восстановления из резервной копии может быть важной для работы дистрибутива. Поэтому tar которым создаётся резервная копия и tar, которым эта копия разворачивается должен уметь работать с этими атрибутами. Причём лучше это проверить на практике до того, как реально потребуется резервная копия.

А так ещё советуют clonezilla.

Монтируй бекап-образ черех loopback, за копируй файлы на новый корень, только с сохранением аттрибутов. Потом установи загрузчик - должно заработать.

если есть оффтоп то можно бекапить с него, с r image drive, да это та самая не нужная проприетарщина которая облегчает этот процесс
там в gui можно выбрать чтобы бекапились только актуальные данные, понимает ext4,3,2 hfs и ешё много фс, монтирует собственно сделанные образы и т.д
всё это можно сделать софтом в линуксе но пока есть оффтоп - так проще