Linux как перенести систему

Перенос Linux на другой компьютер

Вступление

Хочу поделиться собственным опытом переноса системы на другой компьютер, целиком и полностью отличающийся аппаратной конфигурацией.
На самом деле, вариантов перенести систему много. Каждый имеет свой подход. Я же опишу способ, который больше всего подходит для новичков.

Что имеем

Итак, вот конфигурация моего исходного компа, с установленно ОС:
Материнка: Intel S3200shv
Процессор: Intel Core 2 Duo E8400
Память: 8Гб
Raid 1 ёмкостью 300 Гб
ОС: Fedora 12 i686
Будем для краткости называть его «донором».

Конфигурация компа назначния:
Материнка: Intel Desktop Board D845EBG2
Процессор: Celeron 2ГГц
Память: 512Мб
HDD 160 Гб
Это будет «пациент».

Как видите, системы различаются целиком и полностью. В том числе размеры жёстких дисков. Но в этом нет ничего страшного.
На исходной системе мои разделы имели такой вид:
# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/dm-6 5.0G 2.5G 2.2G 53% /
/dev/dm-1 194M 55M 130M 30% /boot
/dev/dm-5 4.0G 141M 3.7G 4% /tmp
/dev/dm-3 99G 257M 94G 1% /var/db
/dev/dm-7 2.0G 87M 1.8G 5% /var/log
/dev/dm-2 173G 229M 164G 1% /var/www

В кратком виде алгоритм будет таким:
1. Создать разделы у «донора», как Вы хотите.
2. Установить на комп назначения такую же систему, как на исходном компе.
3. Подключить к исходному компу HDD компа назначения
4. Скопировать файлы из разделов «донора» в разделы «пациента».

Многие вместо второго шага правят разделы вручную. Я предлагаю установку, поэтому этот способ как мне кажется, проще и универсальнее. Чтобы Вы не мучились с переустановкой загрузчика и правкой /etc/fstab.

Шаг первый

Я размечал свой HDD с помощью загрузочного диска pmagic. Удобно и наглядно.
Разделы я создавал «один-в-один» как и на исходном компе, только меньше размером, т.к. HDD «пациента» меньше.

Шаг второй

Установка Fedora на подготовленный HDD прошла быстро и без проблем. Правда, сначала не мог запустить её в графическом режиме, т.к. стояла планка только в 256 Мб. Пришлось заменить на 512 и процесс пошёл.

Шаг третий

Для начала советую провести у «донора» небольшую подготовку. Это установить kudzu:
yum install kudzu
На всякий случай с помощью dd создать бэкап исходной системы. Мало ли, вдруг что-то напутаете при копировании файлов из-за невнимательности?
Далее, выключаем оба компа, подключаем к «донору» винчестер HDD, на который мы только что установили такую же систему. Загружаемся с LiveCD.

Шаг четвёртый

Заходим в консоль, под рутом создаём 2 директории: /mnt/donor/ и /mnt/pacient/. Внутри каждой директории я создал поддиректории, и туда смонтировал разделы HDD «донора» в /mnt/donor/, а разделы HDD «пациента» в /mnt/pacient/.
Теперь можно начать копировать файлы. Но прежде, очень важное замечание! Есть некоторые исключения, которые не нужно копировать от «донора»! Создадим где-нибудь файл exclude_list, содержащий эти исключения:
/etc/fstab
/boot/grub/grub.conf
/proc
/sys
/dev
/mnt
/media

А теперь копируем файлы с пом. команды:
rsync -xrlptgoEv —progress —exclude-from=/путь/до/exclude_list /путь/откуда/копируем/ /путь/куда/копируем/
Аналогично выполняем вышеприведённую команду для всех смонтированных разделов. Только обязательно в конце «/путь/откуда/копируем/» указывайте слеш.
Перезагружаемся.

У меня после перезагрузки система стартовала без проблем. В логах ни на что не ругалась. Единственное, что пришлось сделать, это подредактировать файл /etc/sysconfig/network-scripts/ifcfg-eth0, т.к. скопировался MAC-адрес с компа «донора». Ну и автозагрузка программ исправил с помощью ntsysv.
Было бы классно, если бы с виндой можно было проделать такой же фокус.

Источник

Бэкап Linux и восстановление его на другом железе

Я работаю в организации с маленьким штатом, деятельность тесно связана с IT и у нас возникают задачи по системному администрированию. Мне это интересно и частенько я беру на себя решение некоторых.

На прошлой неделе мы настраивали FreePBX под debian 7.8, нанимали фрилансера. В процессе настройки оказалось, что сервер (да, я так называю обычный PC) не хочет грузится с HDD при подключенных USB 3G модемах, которые мы используем для звонков на мобильные, колупание BIOSа не помогло. Непорядок. Решил, что нужно перенести его на другую железяку. Так появилось сразу две связанные задачи:

• сделать бэкап сервера;
• восстановить бэкап на другом железе.

Гугление не дало внятных ответов, как это сделать, пришлось собирать информацию кусками и пробовать. Всякие acronis’ы отбросил сразу, ибо не интересно.

Опыт общения с linux-системами у меня небольшой: настройка VPN сервера на open-vpn, ftp-сервера и еще пара мелочей. Сам себя я характеризую как человека умеющего читать маны и править конфиги 🙂

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

Начинаем копать теорию:

Второй способ требует наличия внешнего жесткого диска объемом не меньше раздела, который архивируем. Да и что с ним потом делать, непонятно, хранить на полочке? Остановился на tar, чуть сложнее в реализации, нужно будет создать MBR, но время создания/восстановления архива существенно меньше, хранить бэкап проще, полтора гига можно закинуть в облако и скачать, когда будет нужно. Записывать его можно на ту же live-флэшку, с которой буду грузиться.

Итак, план действия:

1. Создание бэкапа

Грузимся с live-флэшки, у меня это debian-live-7.8.0-amd64-standard.

Переключаемся на root:

Монтируем раздел, который будем архивировать, у меня это sda1, чтобы случайно не наломать дров, монтируем только для чтения. Посмотреть все свои разделы можно при помощи команд ls /dev | grep sd или df -l

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

Все готово для создания архива

Здесь у нас параметры: c — создать архив, v — выводить информацию о процессе, z — использовать сжатие gzip, p — сохраняем данные о владельцах и правах доступа, f — пишем архив в файл, путь к файлу, —exclude — исключаем из архива каталог (я исключил каталоги с записями разговоров и каталог с бэкапами FreePBX), /mnt/ — каталог, который архивируем.

Ждем… у меня вся подготовка и создание архива заняли 10 минут. Будь флэшка быстрее, уложился бы в 7-8 минут.

Складываем архив в надежное место за пределами офиса.

Восстановление бэкапа на другом железе

2. Размечаем диск, создаем файловую систему

Грузимся с live-флэшки, у меня все та же debian-live-7.8.0.

Переключаемся на root:

Размечаем диск. Мне понравилась утилита с псевдографическим интерфейсом cfdisk. Там все просто и понятно.

Удаляем все имеющиеся разделы. Я создал два новых раздела, один на 490 Gb под / (sda1) и 10 Gb под swap (sda2) в конце диска, т.к. он практически не будет задействован. Проверим типы разделов. Который под систему должен иметь тип 83 Linux, второй — 82 Linux swap / Solaris. Помечаем системный раздел загрузочным (bootable), сохраняем изменения и выходим.

Cоздаем файловую систему на первом разделе.

3. Распаковываем архив.

Монтируем отформатированный раздел

Распаковываем архив прямо с флэшки

Параметр —same-owner — сохраняет владельцев у распаковываемых файлов, x — извлекаем из архива, v — выводить информацию о процессе, p — сохраняем права доступа, f — указываем файл, который распаковываем, C — распаковываем в категорию.

4. Создаем MBR на новом диске.

Чтобы корректно создать загрузочную запись, монтируем рабочие каталоги к нашему будущему root-каталогу, у меня это /mnt. Каталоги /dev и /proc сейчас используются live-системой, используем параметр bind, чтобы они были доступны сразу в двух местах:

Переключаемся на новую систему используя chroot:

Делаем swap-раздел для новой системы:

Подключаем его же:

Чтобы grub работал, нужно указать ему правильные UUID разделов в fstab, сейчас там прописаны разделы предыдущей системы:

Открываем второй терминал (Alt+F2) под root:

И видим текущие UUID разделов.

Вручную переписываем их в fstab переключаясь между Alt+F1 и Alt+F2. Да, муторно, но попытки копировать занимали у меня больше времени, чем переписывание. Сохраняем fstab.

Устанавливаем grub2. У меня один физический диск, поэтому ставим его на sda:

На чистый диск должно встать без ошибок. Обновляем информацию из fstab:

Возвращаемся в Live-систему:

Размонтируем все каталоги:

Если вылазят процессы, которые используют эти каталоги, убиваем их используя fuser.

Все, поехали. Грузимся с жесткого диска:

Здесь статья должна была закончиться, но у меня возникли проблемы с подключением к интернету. Сервер видит сеть, видит компьютеры в ней, но в интернет не ходит… а это как бы важно для телефонии.

5. Тестирование и устранение неполадок.

Показывет интерфейсы eth1 и lo, гугление сказало, что gateway можно прописать только подключению eth0, остальные рассчитаны только на работу внутри сети.

Похоже, отсутствие eth0 вызвано способом переноса системы. Находим файл, который отвечает за нумерацию интерфейсов, смотрим туда:

Действительно, там два активных интерфейса, определенных MAC’ами. Комментируем первый, второму прописываем eth0.

Перезапуск /etс/init.d/networking не помог, поэтому перезагружаемся:

Подключаем донглы, проверяем, все работает.
Спасибо за внимание.

Источник

Аникин

Навеяно статьей про перенос freebsd на другой диск. Будем делать тоже самое но на linux. В linux все несколько сложнее.

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

Затем примонтируем его в /mnt

Теперь нам нужно создать дампы разделов, в данном случае нужно создать только дамп sda1. Установим утилиты dump/restore.

И создаем дамп раздела в файл /mnt/root.img

Создание дампа в /mnt/root.img возможно когда на разделе используется менее 50% от /dev/sdb1. Иначе на разматывание дампа места не хватит. В остальных случаях нужно создавать дамп в другом месте, но не в разделе корня, чтобы дамп не мотал сам себя. Можно использовать раздел другой тачки примонтированный по sshfs, я проверял это прекрасно работает.
Переходим в /mnt и разматываем дамп.

Как видим раздел перенесся на /dev/sdb1. Если у нас /boot на отдельном разделе, то переносим его аналогично.

Теперь нам нужно установить загрузчик.

Затем если требуется правим /mnt/etc/fstab и меню grub в /mnt/boot/grub/grub.cfg.

Тут немного поясню зачем проверять и править эти файлы. У меня например в этих файлах были прописаны uuid разделов, и если мы уберем старый диск то ОС соответственно не загрузится, т.к у новых разделов у нас другие uuid. Я вместо uuid прописал реальные устройства корня и свопа /dev/sda1 и /dev/sda3. Все устройства sdb, станут у нас sda после извлечение первого диска.

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

P.S. Утилиты dump и restore не ограничиваются переносом ОС с одного диска на другой. Таким образом можно переносить linux вообще на другую тачку с другим железом и дисками. Процедура почти такая же за небольшими изменениями.

1. На первой тачке создаем дамп ОС;
2. Загружаем вторую тачку с livecd;
3. Размечаем и форматируем диски;
4. Копируем туда дамп c первой тачки(по scp, например);
5. Разворачиваем дамп с помощью restore;
6. Устанавливаем загрузчик;
7. Загружаемся.

Источник

Перенос работающей Linux системы на XFS с HDD на SSD меньшего размера

Привет, Хабр! Представляю вашему вниманию русскоязычную версию статьи «Migrating CentOS system from HDD to smaller SSD on XFS filesystem» автора Denis Savenko.

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

Я думаю я не один, кто в какой-то момент решил преобрести себе SSD-диск для работающей системы. В моём случае это была работающая система на CentOS 7 на моём крошечном домашнем сервере. Далее я хотел перенести её «как есть» на новый диск. Но, как оказалось, это не так то просто сделать, учитывая следующее:

• Новый SSD диск был гораздо меньшего объёма, чем уже установленный HDD (серьёзно, SSD всё ещё весьма дорог по сравнению с дисковыми накопителями).
• Разделы на прежнем диске были отформатированы в файловой системе xfs . Это и не удивительно, учитывая тот факт, что CentOS, начиная с 7-ой версии предлагает эту файловую систему «по умолчанию» (наряду и с другими системами на основе RHEL, такими как, собственно, Red Hat Enterprise Linux 7, Oracle Linux 7 или Scientific Linux 7).
• Работающая система должна остаться без изменений, включая конфигурацию, установленное ПО, права доступа и прочие атрибуты файловой системы.

Позвольте мне пояснить, почему описанные мной выше вещи являются серьёзными усложнениями поставленной перед нами задачи.

Во-первых, если бы размер нового диска был таким же или больше, чем у прежнего, можно было бы применить полное клонирование разделов с данными. Для этого существует масса утилит, таких как dd, ddrescue, partclone или даже clonezilla. Единственное, что нужно было бы сделать после, это подправить пару конфигурационных файлов в загрузочном разделе. Если же вы используете LVM для ваших разделов (что также является опцией по умолчанию в CentOS 7), задача могла бы быть ещё проще — в логический том добавляется новый диск, после чего с использованием команды pvmove данные переносятся на другой физический носитель внутри логического тома, и старый диск изымается из раздела, однако это невозможно при меньшем размере нового физического носителя.

Затем, если бы использовалась файловая система, отличная от xfs , например, достаточно популярная ext4 , можно было бы «сжать» старый раздел диска до размеров нового диска. Затем выполняются какие либо действия из описанных выше и вы в дамках. Однако, изменение размера разделов в сторону уменьшения на xfs невозможно в силу её реализации — вы можете только увеличить разделы при её использовании.

И последнее, но ничуть не менее важное, если бы перед нами не стояло задачи перенести работающую сконфигурированную систему с сохранением всех метаданных, было бы проще просто установить систему с нуля на новый диск, заранее сохранив пару важных файлов. Это не подходило мне по двум причинам — во-первых волосы становились дыбом при мысли, что мне придётся повторить все те же действия, которые я выполнял на протяжении нескольких дней кряду, а во-вторых — это просто не спортивно. Я был уверен, что при должном понимании технических особенностей, перенос работающей системы на другой диск не должен был быть невыполнимой задачей.

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

Этап 1. Подготовка

Вот список того, что нам потребуется для переноса:

1. Собственно, подлежащая миграции работающая система. В моём случае это была CentOS 7.4, но я уверен, что ситуация не будет отличаться от любой другой линукс-системы, работающей на xfs .
2. Live CD или флешка с каким-либо дистрибутивом линукс. Для простоты, я буду отталкиваться от того же CentOS 7.4 Live CD. Я предпочитаю версию с Gnome, но это уже дело вкуса. Выбор этого дистрибутива обусловлен тем, что во-первых, он у меня уже был, а во-вторых с ним сразу поставляется нужный нам для переноса набор утилит, а в частности xfsdump . Я не буду останавливаться здесь на том, как создать загрузочный диск или флешку с Live CD дистрибутивом, так как предполагаю, что хабрачитатель должен справиться с этим и без меня.
3. Объём данных на прежнем накопителе не должен превышать размер нового диска (будь то SSD или любой другой диск меньшего размера). В моём случае занято было всего порядка 10 ГБ, поэтому я даже не задумывался от чего нужно избавляться.
4. Чашка горячего кофе.

Этап 2. Миграция

Глотнём кофе и приступим к процессу переноса с запуска системы с подготовленного Live CD дистрибутива. Затем откройте терминал и перейдите в режим суперпользователя при помощи команды su —

Далее в данном руководстве предполагается, что все команды выполняются от имени суперпользователя ( root )

Шаг 1. Разрешение удалённого доступа (опционально)

Для меня удобнее иметь удалённый доступ к машине, на которой я буду производить перенос, т.к. я имею возможность просто копипастить заранее подготовленные команды в свой PuTTY терминал. Если вы загрузили это руководство в браузере на целевой машине, смело переходите к следующему шагу — всё, здесь описанное, вам не понадобится.

Для того, чтобы разрешить удалённый доступ, необходимо задать пароль для пользователя root и запустить SSH демон:

Теперь можно подключиться к целевой машине вашим SSH клиентом (например, PuTTY).

Шаг 2. Разбивка диска на разделы

Вы можете использовать вашу любимую утилиту для этого. Например, в Gnome есть предустановленная утилита для управления дисками. Также в интернетах хвалят gparted , однако я намеренно использовал fdisk , т.к, например, gparted просто не распознавал мой NVMe SSD-диск.

Диск следует разбить по образу и подобию прежнего диска. Я не маньяк партиционирования, поэтому моя схема партиционирования была стандартной:

• /boot — стандартный раздел размером 1GB;
• swap раздел размером 4G;
• / — корневой раздел, LVM volume group с наименованием «main», занимающий оставшееся пространство на диске.

Итак, приступим к разбивке нового диска:

Раздел /boot должен быть стандартным линукс-разделом, поэтому сразу создаём файловую систему на нём:

И теперь нам необходимо создать LVM-структуру для второго раздела на диске. Назовём новую LVM-группу newmain (впоследствии переименуем):

Теперь мы готовы к созданию файловой системы на новых логических разделах:

Шаг 3. Активная фаза

Прежде чем мы начнём, сделаем обе LVM-группы активными (т.к. мы работаем из под Live CD):

Создадим директории для точек монтирования, и примонтируем к системе старые и новые разделы наших дисков:

Убедимся, что всё в порядке при помощи команды lsblk :

Если вы видите что-то наподобие этого, вы всё сделали верно. И здесь начинается настоящая магия — мы собираемся использовать xfsdump для миграции наших данных. Эта утилита достаточно умная и знает о внутреннем устройстве файловой системы xfs , что позволяет ей копировать только занятые данными блоки, что, в свою очередь, во-первых позволяет нам копировать данные на диск меньшего размера, а во-вторых сильно ускоряет процесс переноса. Итак, давайте сделаем дамп данных при помощи этой утилиты, и на лету развернём эти данные на новом месте:

Пару слов об использованных флагах:

• -J уменьшает размер фидбека;
• — сообщает xfsdump и xfsrestore использовать стандартные потоки stdout и stdin соответственно вместо файлов.

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

Если всё прошло хорошо, ваши данные были полностью скопированы с сохранением всех метаданных. Теперь необходимо подправить пару конфигурационных файлов и переустановить Grub2 на новый диск, чтобы сделать его загрузочным.

Шаг 4. Делаем новый диск загрузочным

Первое, что нужно сделать, это узнать UUID для старого и нового загрузочных разделов ( /boot ) при помощи команды blkid :

Предполагая, что sda1 — прежний раздел \boot , и nvme0n1p1 — новый, производим замену UUID в конфигурационных файлах на новой точке монтирования:

Эти две команды подготовят ваши системные файлы конфигурации к новому диску.

Теперь самое время переименовать LVM-группы и отмонтировать диски:

Единственное, что осталось сделать, это переустановить загрузчик. Это необходимо делать с использованием chroot :

Шаг 5. Последний штрих

На данном этапе все данные уже должны быть перенесены и новый диск должен стать загрузочным. Нужно только перезапуститься, вынуть Live CD из привода, и выбрать новый диск в BIOS для загрузки:

Если что-то пошло не так и система не загружается, вы всегда можете «откатиться» на старый диск, просто запустившись с Live CD повторно и переименовав LVM-группы обратно, выполнив vgrename -v <,new>main и vgrename -v main , и затем снова перезапуститься.

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

Использование старого HDD в качестве медиа-хранилища

Если вы, как и я, после переноса системы, хотите использовать ваш прежний диск как медиа-хранилище, это делается также легко.

Во-первых, переразбейте прежний диск

Мы не станем создавать файловую систему на диске напрямую. Вместо этого мы создадим новую LVM-группу, в которую добавим этот диск. Это позволит нам в будущем легко добавлять новые диски в эту группу без лишней мороки (логический диск при этом останется прежний):

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

Готово!

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

UPDATE 02.04.2018

Так как мы производили перенос системы на SSD, то, как советуют в комментариях, хорошо бы уже после переноса в работающей системе включить периодическое исполнение команды trim (сборщик мусора для SSD-дисков, который позволяет не терять в производительности через время). Для этого необходимо выполнить команду:

Это включит на новой системе исполнение trim раз в неделю на любой systemd системе. В случае, если вы или ваша система не используете systemd , есть исчерпывающее руководство от DigitalOcean на почти любой случай.

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

Источник