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

Когда-то давным давно в далекой-далекой галактике мне понадобилось перенести мою систему linux с одного винчестера на другой, а пользоваться проприетарщиной ужас, как не хотелось. Погуглив и поискав с помощью других поисковиков я нашел для себя решение, которое линукс-админу может показаться смешным, а меня оно тогда здорово выручило.

В общем — вот оно. Бейте ногами, режьте на части. Встречайте!



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

Разберем на конкретном примере моей системы. Я собираюсь перенести систему с HDD=80Gb на HDD=20Gb.

Мой диск, объемом 80Gb размечен следующим образом:

/dev/hda1 — /boot (250 Mb)
/dev/hda2 — swap (1Gb)
/dev/hda3 — extended (20Gb) (включает в себя /dev/hda5, /dev/hda6, /dev/hda7, /dev/hda8)
/dev/hda5 — / (5Gb)
/dev/hda6 — /tmp (512Mb)
/dev/hda7 — /usr (10Gb)
/dev/hda8 — /var (5Gb)
/dev/hda4 — /home (54Gb)


/home очень сильно забит информацией, потому его в клонирование я не включаю.

Выставив перемычки как положено, я подключаю новый HDD в систему. Он принял метку hdb
Можно разметить его с помощью ЛЮБОЙ удобной для вас утилиты. Мне было проще воспользоваться GPARTED — так визуально понятнее, да и видно там сразу, сколько реально места занято данными на той или иной партиции, что поможет определить стоит ли выделять столько много (или мало) места.

Я разметил новый диск (/dev/hdb) следующим образом:

/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)


Следующим шагом надо подмонтировать все созданные разделы на новом HDD к существующей системе.
Для этого на существующей системе я создал директорию /backup, в которой создал поддиректории /boot, /root, /var, /usr (/tmp — не надо), в соответствии с разделами на которые я разделил новый HDD.
Далее осуществляем само монтирование:

sudo mount /dev/hdb1 /backup/boot
sudo mount /dev/hdb5 /backup/root
sudo mount /dev/hdb7 /backup/var
sudo mount /dev/hdb8 /backup/usr


Вот и подобрались к самому интересному, но отнюдь не самому простому месту, к копированию данных.
В отличии от Windows Linux позволяет скопировать себя ПОЛНОСТЬЮ. Но надо помнить один важный момент — в системе есть аттрибуты на директории и файлы, а так же симлинки и хардлинки. Так вот необходимо так скопировать систему, чтоб все эти связи не растерялись. Для такой процедуры, по мнению больших специалистов, лучше всего подходит команда tar.
Смысл в том, что мы НЕ БУДЕМ архивировать файлы на диск, а будем их переносить через так называемую «трубу» или «поток» на приемный HDD.

Для упрощения процедуры переноса я написал скрипт backup.sh:

#!/bin/sh
cd /
tar -cf - dev initrd.img opt srv bin cdrom etc initrd lib sbin sys vmlinuz | (cd /backup/root; tar -xvpf -)
cd /boot
tar -cf - * | (cd /backup/boot; tar -xvpf -)
cd /var
tar -cf - * | (cd /backup/var; tar -xvpf -)
cd /usr
tar -cf - * (cd /backup/usr; tar -xvpf -)


немного объясню, что к чему:

«cd /»
— переход в root

«tar -cf — dev initrd.img opt srv bin cdrom etc initrd lib sbin sys | (cd /backup/root; tar -xvpf -)
» — заtarивание перечисленных директорий и файлов с передачей их на расtarивание на приемный HDD.

Узнать какие директории и файлы надо переносить несложно. Просто выполните команду «ls /» тем самым получив листинг вашей системы начиная с /.
В моем случае это:

ls /
backup boot dev home initrd.img media opt root srv tmp var
bin cdrom etc initrd lib mnt proc sbin sys usr vmlinuz


Из всего этого «добра» нам нужно выделить то что будет находиться в /.
Так, как я выделил отдельные партиции на диске под /boot, /var, /tmp, /usr и /home, получается что их на данном шаге нужно пропустить. Следовательно берем только dev initrd.img opt srv var
bin cdrom etc initrd lib sbin sys vmlinuz


А с остальными проще:
cd /boot
— заходим в существующий /boot

tar -cf - * | (cd /backup/boot; tar -xvpf -)
переносим все содержимое /boot в /backup/boot

и т.д.

Итак запускаем скрипт backup.sh и идем отдыхать на некоторое время. У меня все заняло около 10 минут.

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

НЕДОСТАТОЧНО просто скопировать данные на партиции /var, /tmp, /usr.
После всех процедур переноса нам необходимо СОЗДАТЬ эти директории на приемном диске, как точки монтирования тех самых партиций (и все те точки монтирования, которые мы исключили при переносе — /home, /media, /tmp, /var, /mnt, /proc, /usr) ОБЯЗАТЕЛЬНО С ТЕМИ ЖЕ аттрибутами! То есть:

sudo mkdir /backup/root/home
sudo mkdir /backup/root/media
sudo mkdir /backup/root/tmp
sudo mkdir /backup/root/var
sudo mkdir /backup/root/mnt
sudo mkdir /backup/root/proc
sudo mkdir /backup/root/usr


какие выставить аттрибуты на директории можно узнать набрав команду ls -la / на исходной системе. Но кроме /tmp везде должен быть владелец root группа root и права 766. На /tmp надо поставить права 777.

Теперь надо на приемном HDD поправить fstab, если необходимо (если вдруг вы СОВСЕМ ПО ДРУГОМУ разметили диск). А так же поправить menu.lst загрузчика GRUB.

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

lrwxrwxrwx 1 root root 10 2008-02-17 17:45 11815c66-5ae7-4497-9039-51de9adef664 -> ../../hda2
lrwxrwxrwx 1 root root 10 2008-02-17 17:45 78711a48-6776-4474-8fa8-87016aad83a2 -> ../../hda6
lrwxrwxrwx 1 root root 10 2008-02-17 17:45 83fded3d-37c4-4d85-a965-a7bbe326178a -> ../../hda7
lrwxrwxrwx 1 root root 10 2008-02-17 17:45 a60e482c-8260-48fb-a19e-f5f906d4d444 -> ../../hda8
lrwxrwxrwx 1 root root 10 2008-02-17 17:45 bc7607fe-3bf2-4bc1-adce-8ab749a271c9 -> ../../hda1
lrwxrwxrwx 1 root root 10 2008-02-17 17:45 cacd40ea-ac88-4143-b5d9-5cb477eeb85d -> ../../hda4
lrwxrwxrwx 1 root root 10 2008-02-17 17:45 d4404ea9-0a8e-4a4c-b72d-10a5edd697be -> ../../hda5

вот нам нужны как раз цифры «11815c66-5ae7-4497-9039-51de9adef664», к примеру. Это UUID партиции swap (в моем случае).

в menu.lst правим следующие строки:

# kopt=root=UUID=d4404ea9-0a8e-4a4c-b72d-10a5edd697be ro
(не смотрите что строка закомментирована, при обновлении ядра именно отсюда берется информация)

kernel /vmlinuz-2.6.22-14-generic root=UUID=d4404ea9-0a8e-4a4c-b72d-10a5edd697be ro quiet splash locale

и

kernel /vmlinuz-2.6.22-14-generic root=UUID=d4404ea9-0a8e-4a4c-b72d-10a5edd697be ro single


Не забудьте тот факт, что хоть система и скопирована на диск, но она пока не умеет загружаться, потому что мы не установили загрузчик.
Делается это просто:
Берем установочный диск UBUNTU и грузимся.
переходим в консоль ctrl+f1

sudo su
grub
find /grub/stage1
root (hd0,0) сюда пишем то что выдала предыдущая команда
setup (hd0) сюда пишем то же самое но до первой запятой.
quit


Все — отсединяем диск от системы, подключаем, проверяем. У меня все заработало.

ЗЫ!

Так как я не переносил /home — то система ругнулась на то что я как пользователь есть а вот домашней папки у меня нет. Я поступил варварским способом — userdel %username%, а затем adduser %username%.

Просто мне было НЕВАЖНО. И лень расставлять аттрибуты. А таким образом система сделала все за меня.

P.S. Не ругайте сильно за, возможно, устаревший способ, но на тот момент он работал и работал хорошо! (Тот момент можете вычислить по версии ядра упомянутого в этой статье).
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама

Комментарии 58

    +3
    Помню времена, когда я переносил Slackware простым копированием в MC по F5.
      0
      абсолютно согласен, зачем городить такие грабли когда всё отлично копируется по F5.
      +4
      > узнать какой у вашего диска 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]#
        +10
        для этого есть rsync
        # rsync -av --exclude="/backup*" / /backup/
          0
          Такой метод всегда работал, и наверное еще долго будет работать. Хотя суть можно описать в 3 строчках
          1) Переносим файлы
          2) Правим конфиги
          3) Устанавливаем загрузчик.
          Хотя наверное кому-нибудь статья покажется полезной.
            +2
            Сейчас проще воспользоваться чем-то вроде clonezilla, partimage и еще миллион всяких. Но если оказался в чистом поле и без этих инструментов — то или dd или ваш способ.
              0
              partimage меня недавно расстроил тем, что не поддерживает ext4.
                0
                Да, есть такое дело, расстраивался вместе с вами. Поэтому пришлось осваивать fsarchiver.
              +3
              tar — шикарен…
              Но видите ли, современные файловые системы имеют не только posix-права…

              Вот сравните теперь вывод:
              ls -Z /etc | grep -v \?
              и
              ls -Z /backup/etc | grep -v \?
              Вы не пользуетесь SELinux? А как насчет ACL?
              getfacl -tscR /

              • НЛО прилетело и опубликовало эту надпись здесь
                  0
                  Сделал. Привыкну.
                  +1
                  а dump и restore уже списали со счетов?
                    0
                    Когда искал решение для себя читал, что dump и restore не всегда корректно обходятся с правами.
                      0
                      вроде как только ext2\ext3

                      хотя у меня на centos5 — этот способ самый популярный
                      0
                      О, спасибо! Как раз через пару дней понадобится, когда буду на SSD переезжать.
                        0
                        Полезный опыт. Спасибо.
                          +4
                          LVM смотрит на эту возню как на…
                            0
                            Чем поможет LVM, если нужно заменить диск? Всё равно копировать систему придётся.
                              +5
                              man pvmove
                                +1
                                Прелесть!
                                  0
                                  Вот-вот. Переносить можно на лету. Файлы на этом разделе могут быть открыты даже на запись.
                            –1
                            С помощью левой кнопки мышки и liveCd: загрузиться с liveCd и gparted`ом склонировать разделы с одного диска на другой.
                              0
                              gparted умеет клонировать?
                                +1
                                Не Linux way!?
                                То есть копировать.
                              0
                              Можно было сделать немного проще. Для разделов, внутрь которых ничего не подмонтировано, достаточно выполнить синхронизацию с помощью 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-раздел.
                                +1
                                Копируя современные системы, вы наткнетесь на маленькую их особенность: раздел /dev в них формируется динамически через udev; при этом некоторые, особо важные устройства, находятся в каталоге /dev по-старинке. И вообще, копировать на ходу — не совсем аккуратное дело (хотя нет ничего невозможного), мешаются /var/run и /sys.
                                Учитывая широкое распространение Live-DVD, в наше время будет удобнее такой способ:
                                1) Загрузиться с Live-DVD.
                                2) Разбить приёмный диск на разделы.
                                3) Создать точки монтирования для исходной системы и для разделов на приёмном диске, примонтировать разделы.
                                4) Скопировать систему одним из штатных способов; подойдут, в том числе, cp, dd, rsync, tar.
                                5) Установить загрузчик на приёмный диск или скопировать его с исходного диска.
                                6) Просмотреть /etc/fstab на приёмном диске, если надо, переназначить разделы.
                                7) Теперь можно загружать систему с нового диска.
                                  0
                                  Ну прям все как у меня.
                                    0
                                    И разделы монтировать последовательно, т.е. /backup^W /mnt/dest/root/boot, /mnt/dest/root/var, /mnt/dest/root/usr и т.д. Тогда можно было бы перенести одной командой, и на грабли с точками монтирования не наступили бы.
                                  +2
                                  Зачем так сложно? Зачем здесь нужны cp, rsync и tar? В вашем примере можно было просто уменьшить разделы до 20 Gb, скопировать dd и переустановить загрузчик через chroot с Alternate/LiveCD.
                                    +1
                                    Ну так ведь интереснее :) Тем более для начинающего линуксоида.
                                    0
                                    права на /tmp должны быть 1777
                                      0
                                      А есть еще волшебный fsarchiver, так он даже ntfs умеет и много чего еще.
                                        0
                                        а я обычно вторично монтирую root раздел (mount /dev/sdaXX /oldroot(, так чтоб всякие proc, dev и sys не мешались. потом копирую всё командой cp -av /oldroot/* /newroot/, ну и дальше ставлю загрузчик, правлю конфиги и тп.
                                        я правда не совсем уверен в правильном копировании хардлинков при таком подходе.
                                          0
                                          Не скопируются, получатся два (или больше) обычных файлов.
                                          0
                                          Ты пишешь что мы не будем архивировать, а твой скрипт состоит из архивации и сразу разархивации… упс?
                                          Или я что-то не так понял…
                                            0
                                            Не так понял. TAR в данном случае не выводит результат своей работы в файл, а передает его сразу на другой процесс tar.
                                              +1
                                              результат работы tarа — архив, а процесс — архивирование, а Ваш скрипт это автоматическое разархивирование.
                                              Или я опять что-то не так понял…
                                                –1
                                                Строго говоря, тар не архиватор, он просто кучу файлов представляет в виде одного потока, дабы потом блочным архиватором можно было добиться большей плотности упаковки.
                                                  +1
                                                  Как раз строго говоря tar это tape archive. т.е. tar таки архиватор :)
                                                    0
                                                    Ну если следовать описанию в мануалах — то таки да. Но разве Линукс не такая вещь, где все можно заставить работать не так, как ему оно предначертано? :)
                                                    0
                                                    tar — архиватор, но не компрессор. Процесс архивации (резервного копирования в изначальном смысле этого слова) как раз и состоит в том, чтобы упаковать несколько файлов в единый поток данных (для дальнейшей его записи на магнитную ленту).
                                            • НЛО прилетело и опубликовало эту надпись здесь
                                                0
                                                Ну так и эта инструкция не последняя инстанция, а лишь пример над которым можно и нужно работать, изучать и варьировать под свои нужды.
                                                0
                                                Я похожими вещами занимался года 3 назад. У меня вышло проще и система до сих пор работает. И LiveCD не понадобился — копировал из однопользовательского режима init1.
                                                Короче, тут описывал — кому интересно почитайте seriyps.ru/blog/2008/11/22/perenos-sistemy-na-drugoi-hdd/ Может и есть ошибки, но, повторю — сейчас пишу с этой системы.
                                                  0
                                                  /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, когда ВНЕЗАПНО оказывается, что реальное потребление дискового пространства несколько отличается от ваших представлений на момент разбивки диска?
                                                    +1
                                                    Нет, нет — не смущает :) Просто «рядом сидящий гуру» видел себе такую разбивку по-настоящему грамотной. Ну там типа чтоб /tmp внезапно всю систему не переполнил или там /var почтой не забил.
                                                    Вот я с тех пор так и поступал. И когда пришла пора переносить систему, пришлось мучаться со всем этим барахлом. Однако тоже опыт, ведь не будете вы спорить, что это не так?
                                                      0
                                                      Ну хоть сделали бы так:
                                                      mount -o bind / /fakeroot
                                                      Если к этому добавить ключик --exclude к tar, скрипт переноса в новое место backup.sh будет в одну строчку, а не в 8
                                                        0
                                                        Ну вот — подкинули курева :) Придется и это покурить теперь :)
                                                          0
                                                          Да что там, монтируем в /fakeroot чтобы всякие /dev /proc исключить, далее все что ненужно вписываем в --exclude к tar и вуаля — копируем со старого корня на новый в одно движение.
                                                            0
                                                            Боюсь показаться дебилом — /fakeroot — это типа любой каталог, созданный для монтирования «типа рутового раздела» с приемного винта?
                                                              0
                                                              не, наоборот, это ваш старый рут примонтированный в новое место. Только там не будет /proc и прочих смонтированных фс.
                                                      0
                                                      Для дома /home отдельно(хотя у меня сейчас просто рут, отвык прыгать по разным системам). На сервере как минимум надо отделять boot, var, tmp
                                                        0
                                                        Вот меня и обучали на серверной части.
                                                        0
                                                        Я тоже в таком стиле разбиваю, потому что у каждой из перечисленных файловых систем свой тип ФС и свои режимы доступа. Все, кроме корня и /boot, распределяется через LVM, а /tmp сидит в памяти.
                                                        Я считаю, именно такое разбиение обеспечит наибольшую гибкость и безопасность. У меня, кстати, еще /opt на отдельном разделе, в отдельном томе на LVM.
                                                          0
                                                          В чем заключается большая гибкость и безопасность? Noexec на /var и /tmp?
                                                            0
                                                            В том числе это. Ну и на /srv и /home тоже noexec. А также read-only на /usr и не монтирование по-умолчанию /boot (всё равно он нужен только загрузчику, а после загрузки ядра не нужен).
                                                            Кроме того, я применяю различные файловые системы. EXT3 на всё, что может меняться, ReiserFS (v. 3) на /usr и / (там много мелких файлов), EXT2 на /boot (на фиг не нужна там транзакционная ФС), XFS на раздел с мультимедией (файлы там большие).

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

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

                                                      Самое читаемое