Transferring a running Linux system to XFS from HDD to a smaller SSD

Hi, Habr! I present to your attention the Russian version of the article " Migrating CentOS system from HDD to smaller SSD on XFS filesystem " by Denis Savenko.

This article is a Russian-language version of the previously published article in English with minor adjustments for the audience. Immediately make a reservation - I am not a Linux maniac or even a professional system administrator, so it is likely that sometimes I could use unusual, or even stupid solutions. I will be very grateful to you if you point me to them in the comments so that I can improve this guide instead of just reading the article. Thank you in advance for this.

I think I'm not the only one who at some point decided to buy an SSD disk for a running system. In my case, it was a working system on CentOS 7 on my tiny home server. Next, I wanted to transfer it "as is" to a new disk. But as it turned out, it is not so easy to do, given the following:

• The new SSD drive was much smaller than the HDD already installed (seriously, SSD is still quite expensive compared to disk drives).
• Partitions on the same disk were formatted in the xfs file system. This is not surprising, given the fact that CentOS , starting with version 7, offers this file system "by default" (along with other RHEL-based systems, such as Red Hat Enterprise Linux 7 , Oracle Linux 7). or Scientific Linux 7 ).
• A working system should remain unchanged, including the configuration, installed software, access rights and other attributes of the file system.

Let me explain why the things I described above are serious complications of the task before us.

First, if the size of the new disk were the same or larger than the previous one, the full cloning of data partitions could be applied. To do this, there are a lot of utilities, such as dd , ddrescue , partclone or even clonezilla . The only thing that would have to be done afterwards is to tweak a couple of configuration files in the boot partition. If you use LVM for your partitions (which is also the default option on CentOS 7 ), the task could be even simpler — a new disk is added to the logical volume, then the data is transferred to another physical medium inside the logical volume using the pvmove command. and the old disk is removed from the partition, but this is not possible with a smaller amount of new physical media.

Then, if a file system other than xfs , for example, a fairly popular ext4 , was used, the old partition of the disk could be compressed to the size of the new disk. Then any actions from those described above are performed and you are in queens. However, resizing partitions by xfs impossible due to its implementation - you can only enlarge partitions when using it.

Last but not least, if we did not have the task to transfer a working configured system while preserving all the metadata, it would be easier to simply install the system from scratch to a new disk, saving a couple of important files in advance. It did not suit me for two reasons - firstly, my hair was standing up at the thought that I would have to repeat all the same actions that I performed for several days in a row, and secondly, it was just not sporting. I was sure that with a proper understanding of the technical features, transferring a working system to another disk should not have been an impossible task.

Nevertheless, I have developed and tested a detailed step-by-step plan for moving a working system on at least two different environments, taking into account all the above limitations.

Stage 1. Preparation

Here is a list of what we need to transfer:

1. Actually, the working system subject to migration. In my case it was CentOS 7.4, but I am sure that the situation will not differ from any other Linux system running on xfs .
2. Live CD or USB flash drive with any Linux distribution. For simplicity, I will build on the same CentOS 7.4 Live CD. I prefer the Gnome version, but this is a matter of taste. The choice of this distribution is due to the fact that, firstly, I already had it, and secondly, the toolkit we needed to transfer, and in particular xfsdump delivered with it immediately. I will not dwell here on how to create a boot disk or USB flash drive with a Live CD distribution, as I assume that the reader should handle this without me.
3. The amount of data on the old drive should not exceed the size of the new disk (be it an SSD or any other smaller disk). In my case, only about 10 GB was occupied, so I did not even think about what to get rid of.
4. A cup of hot coffee.

Stage 2. Migration

We take a cup of coffee and start the transfer process from launching the system from the live CD distribution prepared. Then open the terminal and go to superuser mode with the command su -

Further in this manual it is assumed that all commands are executed on behalf of the superuser ( root ).

Step 1. Allow remote access (optional)

For me, it is more convenient to have remote access to the machine on which I will carry out the transfer, since I have the opportunity to simply copy the previously prepared commands into my PuTTY terminal. If you downloaded this guide in the browser on the target machine, feel free to skip to the next step - everything described here is not needed.

In order to allow remote access, you must set a password for the root and start the SSH daemon:

 su passwd systemctl start sshd 

Now you can connect to the target machine with your SSH client (for example, PuTTY ).

Step 2. Partitioning the disk

You can use your favorite utility for this. For example, Gnome has a pre-installed disk management utility. Also on the Internet, they praise gparted , but I intentionally used fdisk , because, for example, gparted simply did not recognize my NVMe SSD disk.

The disk should be broken in the image of the old disk. I am not a partitioning maniac, so my partitioning scheme was standard:

• /boot - standard 1GB partition;
• 4G swap partition;
• / - root partition, LVM volume group with the name "main", occupying the remaining disk space.

So, let's proceed to the breakdown of the new disk:

 lsblk #        ,     nvme0n1 fdisk /dev/nvme0n1 n #    ( /boot) p # primary partition #    (1- ) #    (  ) +1G #    /boot #  n #    (  LVM volume group) p # primary partition #    (2- ) #    (   ) #    (100%  ) #  a #   "bootable" 1 #  10  p # ,     w #      

The /boot partition should be a standard Linux partition, so we immediately create a file system on it:

 mkfs.xfs /dev/nvme0n1p1 -f 

And now we need to create an LVM structure for the second partition on the disk. newmain new LVM group newmain (later rename):

 pvcreate /dev/nvme0n1p2 #    LVM-   vgcreate newmain /dev/nvme0n1p2 #   LVM-         LVM- lvcreate -L 4G -n swap newmain #     4   swap lvcreate -l 100%FREE -n root newmain #          

Now we are ready to create a file system on new logical partitions:

 mkfs.xfs /dev/newmain/root #       mkswap -L swap /dev/newmain/swap #  swap    swapon /dev/newmain/swap 

Step 3. Active Phase

Before we start, let's make both LVM groups active (because we work from under the Live CD):

 vgchange -ay main vgchange -ay newmain 

Create directories for mount points and mount old and new partitions of our disks to the system:

 mkdir -p /mnt/old/boot mkdir -p /mnt/old/root mkdir -p /mnt/new/boot mkdir -p /mnt/new/root mount /dev/sda1 /mnt/old/boot mount /dev/nvme0n1p1 /mnt/new/boot mount /dev/main/root /mnt/old/root mount /dev/newmain/root /mnt/new/root 

Make sure that everything is in order with the help of the lsblk :

 lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 931.5G 0 disk ├─sda1 8:1 0 1G 0 part /mnt/old/boot └─sda2 8:2 0 930.5G 0 part ├─main-swap 253:0 0 3.6G 0 lvm [SWAP] └─main-root 253:1 0 926.9G 0 lvm /mnt/old/root nvme0n1 259:0 0 119.2G 0 disk ├─nvme0n1p1 259:3 0 1G 0 part /mnt/new/boot └─nvme0n1p2 259:4 0 118.2G 0 part ├─newmain-swap 253:5 0 4G 0 lvm [SWAP] └─newmain-root 253:6 0 114.2G 0 lvm /mnt/new/root 

If you see something like this, you did everything right. And here the real magic begins - we are going to use xfsdump to migrate our data. This utility is smart enough and knows about the internal structure of the xfs file system, which allows it to copy only the blocks occupied by data, which, in turn, firstly allows us to copy data to a smaller disk, and secondly, greatly accelerates the transfer process. So, let's dump the data with this utility, and deploy this data in a new place on the fly:

 xfsdump -l0 -J - /mnt/old/boot | xfsrestore -J - /mnt/new/boot xfsdump -l0 -J - /mnt/old/root | xfsrestore -J - /mnt/new/root 

A few words about the flags used:

• -J reduces the size of feedback;
• - Tells xfsdump and xfsrestore use standard stdout and stdin streams, respectively, instead of files.

This procedure may take some time (depending on the amount of your data). Therefore, here you will need a cup of coffee prepared in advance, which is time to drink, or else it will cool down.

If everything went well, your data was completely copied and all the metadata was saved. Now you need to tweak a couple of configuration files and reinstall Grub2 to a new disk to make it bootable.

Step 4. Making the new disk bootable

The first thing to do is find out the UUID for the old and new boot partitions ( /boot ) with the blkid :

 blkid ... /dev/nvme0n1p1: UUID="3055d690-7b2d-4380-a3ed-4c78cd0456ba" TYPE="xfs" ... /dev/sda1: UUID="809fd5ba-3754-4c2f-941a-ca0b6fb5c86e" TYPE="xfs" ... 

Assuming that sda1 is the old \boot partition, and nvme0n1p1 is new, we replace the UUID in the configuration files on the new mount point:

 sed -i "s/809fd5ba-3754-4c2f-941a-ca0b6fb5c86e/3055d690-7b2d-4380-a3ed-4c78cd0456ba/g" /mnt/new/root/etc/fstab sed -i "s/809fd5ba-3754-4c2f-941a-ca0b6fb5c86e/3055d690-7b2d-4380-a3ed-4c78cd0456ba/g" /mnt/new/boot/grub2/grub.cfg 

These two commands will prepare your system configuration files for the new disk.

Now it's time to rename the LVM groups and unmount the disks:

 umount /mnt/{old,new}/{boot,root} vgrename -v {,old}main vgrename -v {new,}main 

The only thing left to do is reinstall the bootloader. This should be done using chroot :

 mount /dev/main/root /mnt mkdir -p /mnt/boot mount /dev/nvme0n1p1 /mnt/boot mount -t devtmpfs /dev /mnt/dev mount -t proc /proc /mnt/proc mount -t sysfs /sys /mnt/sys chroot /mnt/ grub2-install /dev/nvme0n1 

Step 5. The final touch

At this stage, all data should be transferred and the new disk should be bootable. You just need to restart, remove the Live CD from the drive, and select the new disk in the BIOS to boot:

 systemctl reboot -f 

If something went wrong and the system does not boot, you can always “roll back” to the old disk, simply by re-launching the Live CD and renaming the LVM groups back by executing vgrename -v {,new}main and vgrename -v {old,}main , and then restart again.

At the same time, the mandatory part of the program is over and we have successfully transferred the working system to a new disk. Old disk can be removed from the computer.

Using the old HDD as a media storage

If you, like me, after transferring the system, want to use your old disk as a media storage, this is also easy.

First, repartition the old disk.

 fdisk /dev/sda d #   2 d #   1 n #   p # primary partition #  1 #   #    #  p # ,    w #    

We will not create a file system on disk directly. Instead, we will create a new LVM group to which we will add this disk. This will allow us in the future to easily add new disks to this group without unnecessary trouble (the logical drive will remain the same):

 pvcreate /dev/sda1 #   LVM- vgcreate media /dev/sda1 #  LVM- lvcreate -l 100%FREE -n media1 media #         vgchange -ay media #   LVM-  mkfs.xfs /dev/media/media1 #       mkdir -p /var/media #      mount /dev/media/media1 /var/media #      

In order to save changes after rebooting the system, you should also add an entry for the mount point in /etc/fstab :

 /dev/mapper/media-media1 /var/media xfs defaults 0 0 

Done!

Now it can be argued that we successfully transferred the system running on xfs to a new smaller disk. As a bonus, we began to use the old disk as a media storage.

UPDATE 04/02/2018

Since we were transferring the system to SSD, then, as advised in the comments, it would be good to switch on the periodic execution of the trim command after the transfer in the running system (garbage collector for SSD disks, which allows not losing performance over time). To do this, run the command:

 systemctl enable fstrim.timer 

This will enable trim on the new system once a week on any systemd system. In case you or your system do not use systemd , there is a comprehensive guide from DigitalOcean for almost any case.

Please leave your comments if you find a mistake or know a better way how to perform certain actions. I hope this manual will be useful to you!