Комментарии 58
Помню времена, когда я переносил Slackware простым копированием в MC по F5.
+3
> узнать какой у вашего диска 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]#
Так-же можно воспользоваться командой:
[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]#
+4
для этого есть rsync
# rsync -av --exclude="/backup*" / /backup/
+10
Такой метод всегда работал, и наверное еще долго будет работать. Хотя суть можно описать в 3 строчках
1) Переносим файлы
2) Правим конфиги
3) Устанавливаем загрузчик.
Хотя наверное кому-нибудь статья покажется полезной.
1) Переносим файлы
2) Правим конфиги
3) Устанавливаем загрузчик.
Хотя наверное кому-нибудь статья покажется полезной.
0
Сейчас проще воспользоваться чем-то вроде clonezilla, partimage и еще миллион всяких. Но если оказался в чистом поле и без этих инструментов — то или dd или ваш способ.
+2
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
а dump и restore уже списали со счетов?
+1
О, спасибо! Как раз через пару дней понадобится, когда буду на SSD переезжать.
0
Полезный опыт. Спасибо.
0
LVM смотрит на эту возню как на…
+4
С помощью левой кнопки мышки и liveCd: загрузиться с liveCd и gparted`ом склонировать разделы с одного диска на другой.
-1
Можно было сделать немного проще. Для разделов, внутрь которых ничего не подмонтировано, достаточно выполнить синхронизацию с помощью rsync (с сохранением прав доступа, а также ссылок (-H), ACL (-A), расширенных атрибутов (xattrs, -X) и не выходя за пределы файловой системы (-x)), например:
Для разделов, содержащих другие подмонтированные разделы (например, корень (/) содержит /proc, /sys) потребуется сделать простой трюк, чтобы добраться до файлов, которые могут лежать на разделе-источнике внутри точек монтирования (например, в Gentoo часто можно встретить пустые файлы .keep):
После чего, сведя задачу к предыдущей, копируем содержимое /mnt/bind на target-раздел.
rsync -avHAXhPx /usr /mnt/target/usr
Для разделов, содержащих другие подмонтированные разделы (например, корень (/) содержит /proc, /sys) потребуется сделать простой трюк, чтобы добраться до файлов, которые могут лежать на разделе-источнике внутри точек монтирования (например, в Gentoo часто можно встретить пустые файлы .keep):
mkdir /mnt/bind -p && mount --bind / /mnt/bind
После чего, сведя задачу к предыдущей, копируем содержимое /mnt/bind на target-раздел.
0
Копируя современные системы, вы наткнетесь на маленькую их особенность: раздел /dev в них формируется динамически через udev; при этом некоторые, особо важные устройства, находятся в каталоге /dev по-старинке. И вообще, копировать на ходу — не совсем аккуратное дело (хотя нет ничего невозможного), мешаются /var/run и /sys.
Учитывая широкое распространение Live-DVD, в наше время будет удобнее такой способ:
1) Загрузиться с Live-DVD.
2) Разбить приёмный диск на разделы.
3) Создать точки монтирования для исходной системы и для разделов на приёмном диске, примонтировать разделы.
4) Скопировать систему одним из штатных способов; подойдут, в том числе, cp, dd, rsync, tar.
5) Установить загрузчик на приёмный диск или скопировать его с исходного диска.
6) Просмотреть /etc/fstab на приёмном диске, если надо, переназначить разделы.
7) Теперь можно загружать систему с нового диска.
Учитывая широкое распространение Live-DVD, в наше время будет удобнее такой способ:
1) Загрузиться с Live-DVD.
2) Разбить приёмный диск на разделы.
3) Создать точки монтирования для исходной системы и для разделов на приёмном диске, примонтировать разделы.
4) Скопировать систему одним из штатных способов; подойдут, в том числе, cp, dd, rsync, tar.
5) Установить загрузчик на приёмный диск или скопировать его с исходного диска.
6) Просмотреть /etc/fstab на приёмном диске, если надо, переназначить разделы.
7) Теперь можно загружать систему с нового диска.
+1
Зачем так сложно? Зачем здесь нужны cp, rsync и tar? В вашем примере можно было просто уменьшить разделы до 20 Gb, скопировать dd и переустановить загрузчик через chroot с Alternate/LiveCD.
+2
права на /tmp должны быть 1777
0
А есть еще волшебный fsarchiver, так он даже ntfs умеет и много чего еще.
0
а я обычно вторично монтирую root раздел (mount /dev/sdaXX /oldroot(, так чтоб всякие proc, dev и sys не мешались. потом копирую всё командой cp -av /oldroot/* /newroot/, ну и дальше ставлю загрузчик, правлю конфиги и тп.
я правда не совсем уверен в правильном копировании хардлинков при таком подходе.
я правда не совсем уверен в правильном копировании хардлинков при таком подходе.
0
Ты пишешь что мы не будем архивировать, а твой скрипт состоит из архивации и сразу разархивации… упс?
Или я что-то не так понял…
Или я что-то не так понял…
0
Не так понял. TAR в данном случае не выводит результат своей работы в файл, а передает его сразу на другой процесс tar.
0
результат работы tarа — архив, а процесс — архивирование, а Ваш скрипт это автоматическое разархивирование.
Или я опять что-то не так понял…
Или я опять что-то не так понял…
+1
Строго говоря, тар не архиватор, он просто кучу файлов представляет в виде одного потока, дабы потом блочным архиватором можно было добиться большей плотности упаковки.
-1
Как раз строго говоря tar это tape archive. т.е. tar таки архиватор :)
+1
tar — архиватор, но не компрессор. Процесс архивации (резервного копирования в изначальном смысле этого слова) как раз и состоит в том, чтобы упаковать несколько файлов в единый поток данных (для дальнейшей его записи на магнитную ленту).
0
НЛО прилетело и опубликовало эту надпись здесь
Я похожими вещами занимался года 3 назад. У меня вышло проще и система до сих пор работает. И LiveCD не понадобился — копировал из однопользовательского режима init1.
Короче, тут описывал — кому интересно почитайте seriyps.ru/blog/2008/11/22/perenos-sistemy-na-drugoi-hdd/ Может и есть ошибки, но, повторю — сейчас пишу с этой системы.
Короче, тут описывал — кому интересно почитайте 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, когда ВНЕЗАПНО оказывается, что реальное потребление дискового пространства несколько отличается от ваших представлений на момент разбивки диска?
0
Нет, нет — не смущает :) Просто «рядом сидящий гуру» видел себе такую разбивку по-настоящему грамотной. Ну там типа чтоб /tmp внезапно всю систему не переполнил или там /var почтой не забил.
Вот я с тех пор так и поступал. И когда пришла пора переносить систему, пришлось мучаться со всем этим барахлом. Однако тоже опыт, ведь не будете вы спорить, что это не так?
Вот я с тех пор так и поступал. И когда пришла пора переносить систему, пришлось мучаться со всем этим барахлом. Однако тоже опыт, ведь не будете вы спорить, что это не так?
+1
Ну хоть сделали бы так:
mount -o bind / /fakeroot
Если к этому добавить ключик --exclude к tar, скрипт переноса в новое место backup.sh будет в одну строчку, а не в 8
mount -o bind / /fakeroot
Если к этому добавить ключик --exclude к tar, скрипт переноса в новое место backup.sh будет в одну строчку, а не в 8
0
Для дома /home отдельно(хотя у меня сейчас просто рут, отвык прыгать по разным системам). На сервере как минимум надо отделять boot, var, tmp
0
Я тоже в таком стиле разбиваю, потому что у каждой из перечисленных файловых систем свой тип ФС и свои режимы доступа. Все, кроме корня и /boot, распределяется через LVM, а /tmp сидит в памяти.
Я считаю, именно такое разбиение обеспечит наибольшую гибкость и безопасность. У меня, кстати, еще /opt на отдельном разделе, в отдельном томе на LVM.
Я считаю, именно такое разбиение обеспечит наибольшую гибкость и безопасность. У меня, кстати, еще /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, что при ручной установке или пересборке ядер — излишний геморрой (не осилил я эту науку, короче говоря).
Кроме того, я применяю различные файловые системы. EXT3 на всё, что может меняться, ReiserFS (v. 3) на /usr и / (там много мелких файлов), EXT2 на /boot (на фиг не нужна там транзакционная ФС), XFS на раздел с мультимедией (файлы там большие).
Еще одно существенное удобство отделения /usr от корня — это использование LVM. Не всегда угадаешь заранее, какие программы тебе понадобятся, и можно для тома /usr отдавать объём постепенно, по мере установки новых пакетов. Использовать LVM для корня не люблю: при такой конфигурации не обойтись без initrd, что при ручной установке или пересборке ядер — излишний геморрой (не осилил я эту науку, короче говоря).
0
Вы знаете, я бы конечно поспорил, но ведь все равно все останутся при своих :)
0
А что тут спорить? Безопасность и гибкость при таком разбиении действительно увеличиваются. Иной вопрос — а нужны ли они, не приведет ли стремление к гибкости к неоправданному усложнению системы и разным неудобствам?
Этот вопрос, как я считаю, в большой степени является делом вкуса и привычки. Я к такому построению системы привык со времен возни с LFS и Gentoo, для меня большое количество разделов не вызывает неудобств. А для другого пользователя может оказаться совсем наоборот.
Этот вопрос, как я считаю, в большой степени является делом вкуса и привычки. Я к такому построению системы привык со времен возни с LFS и Gentoo, для меня большое количество разделов не вызывает неудобств. А для другого пользователя может оказаться совсем наоборот.
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Перенос системы LINUX на другой винчестер с переразбивкой разделов