Полный перенос ОС и содержимого разделов на LVM разделы

Делайте. http://ru.gentoo-wiki.com/wiki/Stage4

0. Загружаетесь с livecd
1. Архивируете систему
2. Удаляете разделы на которых размешалась система
3. Создаёте раздел типа 8e (Linux LVM)
4. Создаёте группу томов и логические тома 5. Создаёте на логических томах файловую систему
6. Создаёте необходимые директории и монтируете файловые системы в правильной последовательности
7. Распаковываете систему
8. chroot и установка загрузчика

ЗЫЖ: под загрузчик лучше выделить отдельный обычный раздел.

rsync -narvx / /mnt/backup — проверить, что нормально и убрать n (dry-run), если что-то примонтировано отдельно (/home, /log, /usr) добавить после «/»

можно grub.cfg / menu.lst поправить или во время загрузки «е» -> подставить раздел -> «Esc» -> «b»

Если успешно загрузится с внешнего диска, можно уже gparted -> lvm и обратно. Немного больше движений, чем с live-cd (дополнительная перезагрузка), зато сначала можно убедиться, что бекап рабочий.

Пример для генты с raid->dm-crypt->lvm http://en.gentoo-wiki.com/wiki/Root_filesystem_over_LVM2,_DM-Crypt_and_RAID

> ЗЫЖ: под загрузчик лучше выделить отдельный обычный раздел.
Не лучше, а обязательно.

> 8. chroot установка загрузчика
Он же и так стоит уже, его нужно перенести на отдельный раздел. Далее нужно доставить пакеты, если их еще нет в системе (по крайней мере sys-fs/lvm2 если используется только lvm), пересобрать инитрд с поддержкой lvm, исправить /etc/fstab и поправить /boot/grub/grub.cfg

rsync -narvx / /mnt/backup — проверить, что нормально и убрать n (dry-run), если что-то примонтировано отдельно (/home, /log, /usr) добавить после «/»

Ну что за костыли? rsync не нужен, если есть cp. Ещё таким способом не скопируется то, что лежит на / под точками монтирования (например, содержимое /dev до примонтирования туда tmpfs, без которого будут проблемы). liveCD, как предлагали выше, тоже не нужны.

Просто грузимся в single, убеждаемся, что / примонтирован в read-only, после этого:

mount /dev/нужный_девайс_1 /mnt/backup
mount --bind / /mnt/root
cp -a /mnt/root/. /mnt/backup
umount /mnt/root
umount /mnt/backup
# Если есть ещё ФС на диске, то для них:
mount $FS
mount /dev/нужный_девайс_n /mnt/backup
cp -a /mnt/root/. /mnt/backup
umount $FS
umount /mnt/backup

Недавно как раз перешёл на LVM. инфу с хомяка просто скопировал на внешний хард + сделал stage4 системы. sda1 100Mb под /boot, sda2 — остальное под lvm.

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

tips:

-- поддержку лвм (ядро, initramfs, lvm2) можно сделать еще до переноса на старой системе, тогда в chroot останется лишь загрузчик.

-- stage4 быстрее будет сделать при помощи lbzip2/pbzip2:

tar cpvf path_to_backup.tar.bz2 --use-compress-prog=lbzip2 / -X list.excl

-- не забудьте в list.excl включить /media/* /mnt/*, а то начнет архивировать и внешний диск)

-- lvm тома легче увеличивать, чем уменьшать, так что разбивку прикинуть лучше сразу.

-- могут пригодиться getoo и arch wiki по lvm, initramfs, LUKS

частичный оффтоп, при шифровании LUKS работа с диском сильно медленее станет, или не будет заметно? (core i3 M350)

ТС не сказал, что ему нужен raid, тем более шифрованный. Я ему дал ссылку на stage4, т.к. перенос системы проще делать так, запаковать архив и распаковать на готовое место. А ниже описал про подготовку файловых систем, создать группу томов, логические разделы, файловые системы на них, всё это правильно смонтировать, создав перед этим точки монтирования, затем просто распаковать архив, для этого stage4 как раз прекрасно подходит.

Под установкой загрузчика имеется ввиду установка его в mbr, если у ТС до этого раздел с файлами загрузчика был в корне, а не на отдельном разделе.

Про правку /etc/fstab не сказал, забыл, но ТС наверно уж догадается, что теперь его система расположена на других логических носителях и про конфиг загрузчика тоже.

Ну а прочая специфика Gentoo, указанная в предложенном вами руководстве ТС вообще не нужна, он же не указал что у него за система, если бы была Gentoo он бы и сам знал как перенести систему.

Grub2 умеет использовать lvm, нужно дописать подгрузку модуля сначала:

insmod lvm

Так что выделять раздел тоже н обязательно, но лучше сделать, будет проще.

Ну что за костыли? rsync не нужен, если есть cp.

Вы так говорите, будто команда для rsync заметно длиннее. Во-первых, есть -n — можно проверить, прежде чем запускать, во-вторых --append, учитывая, что объем может быть большим, это не лишнее.

Где именно костыльность? (сабж все еще входит в область применения rsync, why not)

Забыл - ещё надо fstab ему будет подправить.

частичный оффтоп, при шифровании LUKS работа с диском сильно медленее станет, или не будет заметно? (core i3 M350)

Заметно. Простой пример: скорость хеширования шары dc падает где-то на 0.5-1 порядок(~100 mb/s -> 10 mb/s).

Еще вероятность фризов (10-20 сек) повышается (не разбираюсь, чтобы сказать, что это 12309).

Да, да, забыл, мне об этом ужо написали.

> ТС не сказал, что ему нужен raid, тем более шифрованный.
наверное поэтому там написано что это достаточно универсальный пример. Достаточно выкинуть оттуда все ненужное (raid, dm-crypt).

> т.к. перенос системы проще делать так
Действительно проще сделать cp -a - проще и быстрее. Но требует чуть больше места.

> Ну а прочая специфика Gentoo, указанная в предложенном вами руководстве ТС вообще не нужна
Принципиальной разницы нет-так или иначе нужно создавать разделы и собирать инитрд (не уверен что в других дистрибутивах инитрд умеет искаропки). Зато в мануале указаны принципы работы с lvm и сборки инитрд (хотя может в других дистрибутивах это можно делать по-другому).

> Grub2 умеет использовать lvm, нужно дописать подгрузку модуля
Не знал. Но luks он не умеет?

А не страшно, что при отказе одного винта, накроется весь LVM и будут большие проблемы с восстановлением данных, и загрузкой системы подавно? Не лучше ли систему на отдельных разделах, а остальное LVM?

P.S. у самого файлопомойка на старом сервачке c LVM... В интернете гуглил по поводу сбоя в винчестере - всё печально. Единственный выход - мониторинг smart с отправкой писем счастья в случае ошибок.... Но, так руки не доходят до настройки.

> частичный оффтоп, при шифровании LUKS работа с диском сильно медленее станет, или не будет заметно
Принципиальной разницы не заметил. (AMD E-350)
Использую luks->lvm->{ext4,reiserfs} /dev/sda4 - зашифрованный раздел

$ dd if=/dev/sda4 of=/dev/null bs=8M count=256
256+0 records in
256+0 records out
2147483648 bytes (2,1 GB) copied, 25,5509 s, 84,3 MB/s

$ dd if=/dev/mapper/vg-root of=/dev/null bs=8M count=256
256+0 records in
256+0 records out
2147483648 bytes (2,1 GB) copied, 33,5144 s, 64,1 MB/s

Kadi

Действительно проще сделать cp -a - проще и быстрее. Но требует чуть больше места.

magres

Хочется это сделать надежно быстро и безопасно при помощи внешнего накопителя.

Проще возможно, ну а если ТС использует USB-HDD через USB-2.0, то он быстрее запишет на внешний диск архив сжатой системы да и прочитает ей потом быстрее, т.к. через USB-2.0 быстрее 30 мегабайт в секунду на USB-HDD не пишется, так что сжатые данные запишутся быстрее, да и процесс распаковки сам по себе идёт быстрее чем запаковка., как следствие объём данных, которые нужно «прогнать» через узкий интерфейс будет меньше. Опять же ТС получит бэкап системы.

Но luks он не умеет

Этого не умеет.

> 30 мегабайт в секунду на USB-HDD
Если процессор не i7 какой-нибудь, то быстрее скопировать.
На ноутбуке как-то бэкапился с упаковкой корня - 15GB упаковывались полчаса, а вот размер архива не очень то и изменился - если не ошибаюсь, вышло ~10GB.

способы бэкапа на вкус и цвет.. но stage4, имхо, удобна тем, что одним файлом и меньше места. У меня полкорня в squashfs, все вместе занимает 2.1Гб, архив вышёл 1.6Гб. А насчёт времени архивации, lbzip2/pbzip2 же, если пару ядер.

anonymous

Где именно костыльность?

Это не к самому rsync, а к этой конкретной команде:

gentoo_root

Ещё таким способом не скопируется то, что лежит на / под точками монтирования (например, содержимое /dev до примонтирования туда tmpfs, без которого будут проблемы).

Суть в том, что нельзя копировать просто /, а сначала надо сделать bind куда-то в другое место, чтобы сохранилось содержимое /dev и т.п., которое было до того, как в эти каталоги что-то примонтировалось. Оно лежит на ФС корня и становится недоступным, когда сверху монтируется tmpfs, но оно нужно на раннем этапе загрузки (там лежит /dev/null, например). Поэтому просто копировать / нельзя, а надо сбиндить / в другой каталог, а его уже копировать, иначе потом могут быть неприятности при загрузке.

частичный оффтоп, при шифровании LUKS работа с диском сильно медленее станет, или не будет заметно? (core i3 M350)

Да. LUKS - это самый простой способ воспроизвести баг 12309.