How to move linux from hdd to ssd

Перенос работающей 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 на почти любой случай.

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

Источник

Upgrading To Solid State Drive in Linux: The Easy Way and The Hard Way

Last updated October 29, 2020 By Community 23 Comments

Many current Linux users switched over from windows simply because they were sick of using a machine so sluggish that it was barely able run its native OS; sick of spending time watching an “hour glass” icon waiting for something—anything—to happen. And many found this simple act to be a type of upgrade since Linux systems always were far more efficient in their use of resources. Likewise, you could also upgrade your ram or your graphics card.

If you do all three, you’ll get tangible though probably only an incremental improvement.

How can I get even more performance out of my system? As technology changes so do the choke points in your system. These days what’s usually gumming up the works is a spinning metal disc; your hard disc drive. Over the years, I’ve tweaked lots of systems, but nothing I’ve ever done has produced such spectacular results as installing a solid-state hard drive. Suddenly every thing’s faster; boot-ups take a 1/5th to a 1/6th of the time and programs pop into action. This isn’t incremental change; it’s a radical change.

Initially, I was skeptical; I’d heard stories about random bit flips and I already knew that SSDs were expensive.

These days SSD’s are now just as reliable as their ancestors, and though cheaper than before, still a lot more than HDDs by about 5x to 10x per gigabyte. In other words, a 1T SSD can cost up to $1,000.00US.

So the first question to ask is how big does my hard drive really needs to be?

Above is a screen shot of my system. Notice that I’m only using about 1/2 my main drive. And I still have space for a second 100G partition.

So to answer my own question: “No, I don’t need a terra-byte”. On this computer, I installed a 256G SSD which cost me about $70.00US. And since the system and all my programs are running off a big hunk of semiconductor, suddenly it’s the fastest system I’ve ever had.

Another thing you may have noticed is while the data on my main drive is a svelte 79G, the data on the other is a waddling 307G. There are two reasons for this. First, I never throw anything away. Second, I’ve read the words “but first back up your home folder” so many times that I stopped putting stuff there in the first place. It’s a habit that another advantage I’ll get to later.

Upgrading your system to SSD: The easier way

It turns out—like so many things Linux—that the easiest way is also the best way.

• Backup your home folder.
• Remove the old HDD.
• Replace it with your sparkling new SSD. (If you have a desktop computer remember you’ll need an adapter bracket; with SSDs it’s one size fits all. And don’t worry about the tiny four-pronged wire. It’s there to power the motor that SSDs don’t have since they don’t spin!)
• Re-install your favorite Linux distro from CD, DVD or flash drive.

One of the beauties of Linux is that there are hundreds of flavors to choose from and many are free. So starting from scratch won’t break the bank. And, a clean installation ensures that your OS will be finely tuned to all your hardware, including your new SSD. Besides, configuring a new system can be lots of fun when you don’t have to watch a spinning wheel all the time.

Finally, don’t throw out your old HDD. If your machine has extra drive bays you can re-install them and use them as storage media. If not, you can get the same result by purchasing a drive enclosure. And why—you might ask—would I store all my files on my old slow drive? Because for your computer opening files is fast and easy anyway, so you don’t really gain much. Furthermore, on my laptop—which has a second drive bay—I use the old HHD as a home folder. That way each of the three OS’s I installed on the SSD have access to exactly the same files, and they’re always in perfect synchrony.

There is a much harder way of doing this: cloning your old disc to the new one. We are going to see it in the next section.

Upgrading your system to SSD: The harder way

So, you’re convinced that upgrading to an SSD is a good idea, but you are adamant about keeping your current OS. Don’t worry, it can be done, but remember you’re choosing the “hard way”. This means a lot more preparation, time and some extra software and hardware besides.

What we’re talking about here is cloning. Fortunately, there are lots of open source options. They all seem to operate on the same principle: they make an image of the partition you want to clone and store it as a single file or series of files. Think of them as bit-for-bit photocopies of your hard drive. This has two important consequences. First, if your partition is 250G, it will photocopy all 250G of it—even the unused space. Second, the empty “destination” partition—on your new SSD—usually must be bigger than the source.

But let’s not get ahead of ourselves. Before starting, make sure you have the following:

• A bootable disc with your clone-ware.
• A bootable grub rescue disc.
• A bootable version of G-parted
• A 21/2” drive enclosure.
• A big fat external HDD; like the one you are about to backup your home folder on.
• Your sparkling new SSD.
• 2 empty USB sockets.

Before Cloning:

Create a live G-parted disc. G-parted is a simple and powerful partition editor, but if you’ve never used it before take the time to read about it; especially “shrink partition” and “create partition”. You can find the manual here. And if you remember nothing else remember that no changes are made until you click “apply all operations”, and that after re-sizing sda, it must be re-booted—perhaps for the last time. This to ensure that errors—if there are any—can be immediately corrected. It also ensures that you won’t be spending the next few hours cloning a buggy drive.

After putting your SSD into an enclosure, unmount all unnecessary USB devices and boot into G-parted. When G-parted (eventually) boots it will show your main drive as sda1. Right clicking on it gets you to “re-size/move” option, where you can graphically shrink your partition. This ensures your target drive is bigger than the source and it prevents you from wasting a lot of time copying unused space.

Next, plug in your SSD—it should appear as sdb and “unallocated”—and create a bootable primary partition formatted to ext4. Don’t worry about labels or UUIDs; all the particulars will be in the image you’re about to clone onto it. All we want to do here is create a target partition that the clone-ware can easily find and write to.

Then, tidy up your external HDD. This is where you’ll store your image; you want to make it easy for your clone-ware to find it when it’s time to restore. If you’re lazy (like me) and your external HDD is a mess (like mine) it’s easiest to just grab it all and nest it in all in one file for the time being. Also, make sure you have loads of space; if you’re imaging a 150G partition it’s not going to fit onto a 32G flash drive.

Finally, you’re going to have to pick out some clone-ware. For an excellent overview see this. Once you’ve made up your mind download and create live CD or flash drive.

Cloning:

I ended up using Clonezilla, but they all do the same sorts of things in the same sorts of ways. In a two-step process they first “image” your system to your external HDD, then restore from your HDD to your target drive. They are all bootable media, meaning patience is required. For an excellent overview of Clonezilla see here. The only thing I did differently is I stuck with partition cloning, so I used the “saveparts” and “restoreparts” commands.

Once you boot into Clonezilla you’re going to have lots of time to kill. It’s not unusual for the whole save and restore process to take 3 hours.

One thing the cited tutorial doesn’t show is the “restore grub” option. If you’ve been looking for it and can’t find it, don’t worry, it’ll show up after Clonezilla gets past the “WARNING. WARNING. WARNING. ” bit and before the final copying begins.

Testing:

At this point, it’s plug and play. Remove your SSD from the enclosure, and swap it with your old HDD. Even if you have a free bay I would not recommend re-installing your old HDD at this point. It’s always best to keep things simple.

Finally, power it up. Most of the time your old OS will be up and running on your new SSD. You’ll notice a real improvement in boot times and in general responsiveness.

However, there is also a chance boot right away. If this happens, kill it (Ctrl Alt Del) and try again. It’s not unusual for it to boot on the second or third attempt. And once it does, it will boot properly from then on.

If your SSD still stubbornly refuses to boot, simply boot into your grub rescue disc and re-install grub2.

A Final Caveat:

This really is the hardest way to achieve the worst results. After going through all this and using it for a few months I ended up overwriting it with a fresh installation of the same OS. As I expected the newer installation was quicker still.

Dave Merritt

I’m a 59 year old, full­time landscaper and part­time PCmedic. I’ve been an avid Linux user for over ten years. In that time, I do not claim to have made every possible mistake, only most of them. I’m a big fan of prog rock, avant­ jazz and J S Bach, and enjoy reading Neal Stevenson and anything to do with the foundational problems in modern physics.

Like what you read? Please share it with others.

Источник