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

[antivir]

Помню времена, когда я переносил Slackware простым копированием в MC по F5.

[tpedko]

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

[zCooler]

> узнать какой у вашего диска UUID можно с помощью команды: ls -l /dev/disk/by-uuid, на выводе должно получиться что то вроде:

Так-же можно воспользоваться командой:

[root@hydrogenium production]# blkid
/dev/sda1: UUID=«2db018a9-c02c-49dd-b8fd-64f1fe105aa6» TYPE=«ext3»
/dev/sda2: LABEL=«SWAP-isw_dgbggb» TYPE=«swap»
/dev/sdb1: LABEL="/" UUID=«21dc4eb2-9acb-4387-be21-cc2aa8170443» TYPE=«ext3»
[root@hydrogenium production]#

[BuriK666]

для этого есть rsync
# rsync -av --exclude="/backup*" / /backup/

[zwie]

Такой метод всегда работал, и наверное еще долго будет работать. Хотя суть можно описать в 3 строчках
1) Переносим файлы
2) Правим конфиги
3) Устанавливаем загрузчик.
Хотя наверное кому-нибудь статья покажется полезной.

[rtzra]

Сейчас проще воспользоваться чем-то вроде clonezilla, partimage и еще миллион всяких. Но если оказался в чистом поле и без этих инструментов — то или dd или ваш способ.

[ArtRoman]

partimage меня недавно расстроил тем, что не поддерживает ext4.

[rtzra]

Да, есть такое дело, расстраивался вместе с вами. Поэтому пришлось осваивать fsarchiver.

[mmxspb]

Сделал. Привыкну.

[NukLeoN]

а dump и restore уже списали со счетов?

[mmxspb]

Когда искал решение для себя читал, что dump и restore не всегда корректно обходятся с правами.

[Anton_Shevtsov]

вроде как только ext2\ext3

хотя у меня на centos5 — этот способ самый популярный

[VaMpir]

О, спасибо! Как раз через пару дней понадобится, когда буду на SSD переезжать.

[Henryh]

Полезный опыт. Спасибо.

[andy128k]

LVM смотрит на эту возню как на…

[surly]

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

[andy128k]

man pvmove

[surly]

Прелесть!

[andy128k]

Вот-вот. Переносить можно на лету. Файлы на этом разделе могут быть открыты даже на запись.

[rich]

С помощью левой кнопки мышки и liveCd: загрузиться с liveCd и gparted`ом склонировать разделы с одного диска на другой.

[ArtRoman]

gparted умеет клонировать?

[rich]

Не Linux way!?
То есть копировать.

[kmeaw]

Можно было сделать немного проще. Для разделов, внутрь которых ничего не подмонтировано, достаточно выполнить синхронизацию с помощью rsync (с сохранением прав доступа, а также ссылок (-H), ACL (-A), расширенных атрибутов (xattrs, -X) и не выходя за пределы файловой системы (-x)), например:
rsync -avHAXhPx /usr /mnt/target/usr

Для разделов, содержащих другие подмонтированные разделы (например, корень (/) содержит /proc, /sys) потребуется сделать простой трюк, чтобы добраться до файлов, которые могут лежать на разделе-источнике внутри точек монтирования (например, в Gentoo часто можно встретить пустые файлы .keep):
mkdir /mnt/bind -p && mount --bind / /mnt/bind

После чего, сведя задачу к предыдущей, копируем содержимое /mnt/bind на target-раздел.

[surly]

Копируя современные системы, вы наткнетесь на маленькую их особенность: раздел /dev в них формируется динамически через udev; при этом некоторые, особо важные устройства, находятся в каталоге /dev по-старинке. И вообще, копировать на ходу — не совсем аккуратное дело (хотя нет ничего невозможного), мешаются /var/run и /sys.
Учитывая широкое распространение Live-DVD, в наше время будет удобнее такой способ:
1) Загрузиться с Live-DVD.
2) Разбить приёмный диск на разделы.
3) Создать точки монтирования для исходной системы и для разделов на приёмном диске, примонтировать разделы.
4) Скопировать систему одним из штатных способов; подойдут, в том числе, cp, dd, rsync, tar.
5) Установить загрузчик на приёмный диск или скопировать его с исходного диска.
6) Просмотреть /etc/fstab на приёмном диске, если надо, переназначить разделы.
7) Теперь можно загружать систему с нового диска.

[mmxspb]

Ну прям все как у меня.

[ekungurov]

И разделы монтировать последовательно, т.е. /backup^W /mnt/dest/root/boot, /mnt/dest/root/var, /mnt/dest/root/usr и т.д. Тогда можно было бы перенести одной командой, и на грабли с точками монтирования не наступили бы.

[RussianNeuroMancer]

Зачем так сложно? Зачем здесь нужны cp, rsync и tar? В вашем примере можно было просто уменьшить разделы до 20 Gb, скопировать dd и переустановить загрузчик через chroot с Alternate/LiveCD.

[mmxspb]

Ну так ведь интереснее :) Тем более для начинающего линуксоида.

[ergil]

права на /tmp должны быть 1777

[d1p]

А есть еще волшебный fsarchiver, так он даже ntfs умеет и много чего еще.

[mafet]

а я обычно вторично монтирую root раздел (mount /dev/sdaXX /oldroot(, так чтоб всякие proc, dev и sys не мешались. потом копирую всё командой cp -av /oldroot/* /newroot/, ну и дальше ставлю загрузчик, правлю конфиги и тп.
я правда не совсем уверен в правильном копировании хардлинков при таком подходе.

[kmeaw]

Не скопируются, получатся два (или больше) обычных файлов.

[dikkini]

Ты пишешь что мы не будем архивировать, а твой скрипт состоит из архивации и сразу разархивации… упс?
Или я что-то не так понял…

[mmxspb]

Не так понял. TAR в данном случае не выводит результат своей работы в файл, а передает его сразу на другой процесс tar.

[dikkini]

результат работы tarа — архив, а процесс — архивирование, а Ваш скрипт это автоматическое разархивирование.
Или я опять что-то не так понял…

[nemckoff]

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

[susl]

Как раз строго говоря tar это tape archive. т.е. tar таки архиватор :)

[mmxspb]

Ну если следовать описанию в мануалах — то таки да. Но разве Линукс не такая вещь, где все можно заставить работать не так, как ему оно предначертано? :)

[ekungurov]

tar — архиватор, но не компрессор. Процесс архивации (резервного копирования в изначальном смысле этого слова) как раз и состоит в том, чтобы упаковать несколько файлов в единый поток данных (для дальнейшей его записи на магнитную ленту).

[mmxspb]

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

[seriyPS]

Я похожими вещами занимался года 3 назад. У меня вышло проще и система до сих пор работает. И LiveCD не понадобился — копировал из однопользовательского режима init1.
Короче, тут описывал — кому интересно почитайте seriyps.ru/blog/2008/11/22/perenos-sistemy-na-drugoi-hdd/ Может и есть ошибки, но, повторю — сейчас пишу с этой системы.

[miga]

/dev/hdb1 — /boot (250 Mb)
/dev/hdb2 — swap (1Gb)
/dev/hdb3 — extended (14Gb) (включает в себя /dev/hdb5, /dev/hdb6, /dev/hdb7, /dev/hdb8)
/dev/hdb5 — / (1Gb)
/dev/hdb6 — /tmp (512Mb)
/dev/hdb7 — /var (5Gb)
/dev/hdb8 — /usr (7Gb)
/dev/hdb4 — /home (4Gb)

Пожалуйста, объясните, зачем вы все это делаете? Вас смущает, что df -h выглядит недостаточно внушительно? Вас очень забавляет прыжки вокруг mount -o bind, когда ВНЕЗАПНО оказывается, что реальное потребление дискового пространства несколько отличается от ваших представлений на момент разбивки диска?

[mmxspb]

Нет, нет — не смущает :) Просто «рядом сидящий гуру» видел себе такую разбивку по-настоящему грамотной. Ну там типа чтоб /tmp внезапно всю систему не переполнил или там /var почтой не забил.
Вот я с тех пор так и поступал. И когда пришла пора переносить систему, пришлось мучаться со всем этим барахлом. Однако тоже опыт, ведь не будете вы спорить, что это не так?

[BmW]

Ну хоть сделали бы так:
mount -o bind / /fakeroot
Если к этому добавить ключик --exclude к tar, скрипт переноса в новое место backup.sh будет в одну строчку, а не в 8

[mmxspb]

Ну вот — подкинули курева :) Придется и это покурить теперь :)

[BmW]

Да что там, монтируем в /fakeroot чтобы всякие /dev /proc исключить, далее все что ненужно вписываем в --exclude к tar и вуаля — копируем со старого корня на новый в одно движение.

[mmxspb]

Боюсь показаться дебилом — /fakeroot — это типа любой каталог, созданный для монтирования «типа рутового раздела» с приемного винта?

[BmW]

не, наоборот, это ваш старый рут примонтированный в новое место. Только там не будет /proc и прочих смонтированных фс.

[RainFall]

Для дома /home отдельно(хотя у меня сейчас просто рут, отвык прыгать по разным системам). На сервере как минимум надо отделять boot, var, tmp

[mmxspb]

Вот меня и обучали на серверной части.

[surly]

Я тоже в таком стиле разбиваю, потому что у каждой из перечисленных файловых систем свой тип ФС и свои режимы доступа. Все, кроме корня и /boot, распределяется через LVM, а /tmp сидит в памяти.
Я считаю, именно такое разбиение обеспечит наибольшую гибкость и безопасность. У меня, кстати, еще /opt на отдельном разделе, в отдельном томе на LVM.

[miga]

В чем заключается большая гибкость и безопасность? Noexec на /var и /tmp?

[surly]

В том числе это. Ну и на /srv и /home тоже noexec. А также read-only на /usr и не монтирование по-умолчанию /boot (всё равно он нужен только загрузчику, а после загрузки ядра не нужен).
Кроме того, я применяю различные файловые системы. EXT3 на всё, что может меняться, ReiserFS (v. 3) на /usr и / (там много мелких файлов), EXT2 на /boot (на фиг не нужна там транзакционная ФС), XFS на раздел с мультимедией (файлы там большие).

Еще одно существенное удобство отделения /usr от корня — это использование LVM. Не всегда угадаешь заранее, какие программы тебе понадобятся, и можно для тома /usr отдавать объём постепенно, по мере установки новых пакетов. Использовать LVM для корня не люблю: при такой конфигурации не обойтись без initrd, что при ручной установке или пересборке ядер — излишний геморрой (не осилил я эту науку, короче говоря).

[miga]

Вы знаете, я бы конечно поспорил, но ведь все равно все останутся при своих :)

[surly]

А что тут спорить? Безопасность и гибкость при таком разбиении действительно увеличиваются. Иной вопрос — а нужны ли они, не приведет ли стремление к гибкости к неоправданному усложнению системы и разным неудобствам?
Этот вопрос, как я считаю, в большой степени является делом вкуса и привычки. Я к такому построению системы привык со времен возни с LFS и Gentoo, для меня большое количество разделов не вызывает неудобств. А для другого пользователя может оказаться совсем наоборот.