Migrating KDE to a New SSD?

[PhysicistSarah]

I just got a 500GB SSD to enhance HDD performance and am interested in migrating the system over to it.

Since I use BTRFS and already have backup (On my external drive) snapshots, I would assume that this would be easier than just starting from scratch.

I have snapshots of @ and @home. How should I migrate my system over to the new SSD? I don't really know how restoring works in BTRFS as I have never done a restore. I would assume that it is similar, but the snapshots are read-only and I don't know how this affects the process.

Would it just be as easy as formatting the SSD as BTRFS and then restoring the @ subvolume to it since this contains all the system files? This is somewhat more complicated because my traditional HDD is 1TB, but the SSD is 500GB, so I can't just restore @home in its entirety.

Thanks for the suggestions

[jlittle]

Since I use BTRFS and already have backup (On my external drive) snapshots,

Using btrfs send and receive? With btrfs on the external drive?

This is somewhat more complicated because my traditional HDD is 1TB, but the SSD is 500GB, so I can't just restore @home in its entirety.

I don't understand that. Is your @home full? If @ and @home together are less than 500 GB, IIUC there's no problem. Perhaps you're thinking of cloning file systems with a low level tool; I'd avoid that approach.

How should I migrate my system over to the new SSD?...

If you have a desktop, just put the SSD in at the same time as the old HDD. But, now that I think about it, your mention of the external drive strongly suggests you're using a laptop.

The main tricks here are adjusting the boot loader, and /etc/fstab. Make sure you have a bootable USB device; the Kubuntu installer is such, and make an up to date backup. Backup the EFI partition, if you have one, too, maybe using fsarchiver.

Here's a rushed sketch of a plan:

• Put in the SSD, and partition it with an EFI partition (assuming the computer uses UEFI firmware), a swap partition if you use one, and the rest of the space with a btrfs partition.
• Restore the EFI partition.
• Mount the external drive, and use btrfs send/receive to copy @ and @home onto the SSD.
• Mount the @, say in /mnt/@, and the EFI partition, say in /mnt/efi and run sudo grub-install specifying --boot-directory=/mnt/@/boot and --efi-directory=/mnt/efi.
• Run sudo blkid to find the UUIDs and edit /mnt/@/etc/fstab to use them.

But I think it would be simpler, more flexible, and robust, if somewhat slower, and use more space temporarily, to:

• Put in the SSD and install Kubuntu to it, using btrfs and according to your preferences about swap. It doesn't take long to an SSD.
• Boot into the new install, but don't do much to it.
• Run sudo blkid to find the UUIDs.
• Mount the top level of the btrfs, say on /mnt/top. (Some would call that the root, but I've always found that confusing, because I'm used to / being synonymous with "root".)
• Go into /mnt/top and rename @ to @_x, and @home to @home_x.
• Use btrfs send/receive to copy @ and @home from the backup into /mnt/top.
• Edit /mnt/top/@/etc/fstab to have the correct UUIDs.
• Reboot, and sometime later you can delete the @_x and @home_x subvolumes.

[oshunluvr]

There are other ways to do this without even rebooting.

First off, don't consider any kind of regular copying using rsync or anything silly like that - this is not 1990.

I'll let JLitte or QQmike (if he joins the conversation) discuss EFI since I rarely use it and know little or nothing about it. GRUB is a separate matter and will require the same amount of work either way. One could always leave GRUB and it's boot device in place and use the SSD after booting to it rather than making it the boot device.


As far as the BTRFS subvolumes, there's no "restoring". The process of send|receive isn't a traditional 1990's backup container. It's a full file-to-file copy of the subvolume.

You can send|receive the subvolumes to the SSD (after partition and formatting of course). Reset the status of the received subvolumes to read-write. Edit the UUIDs inside the @ subvolume in fstab and in /boot/grub/grub.cfg, reboot to the new drive, and run update-grub and you're done. I think I even have a script somewhere that does the edits for you.

The no-rebooting way takes longer (in computer time, not your time) but happens in the background. Simply add the new SSD BTRFS partition to your current file system. Then "remove" the old partition from the file system. This will move the subvolumes, retain the UUIDs, and you won't even have to reboot. Way easy, just more processing time. I've done this several times without issue.

[oshunluvr]

If you go the send|receive route:

Send the read-only snapshot to the backup locations;

btrfs send <source_mount>/@ | btrfs receive <target_mount>
btrfs send <source_mount>/@home | btrfs receive <target_mount>

Change the snapshots to read-write;

btrfs property set -ts <target_mount>@ ro false
btrfs property set -ts <target_mount>@home ro false

These commands will change edit the UUIDs in the subvolumes. Get the new UUID after you create the target file system;

sed -i 's/<OLD_UUID>/<NEW_UUID/g' @
sed -i 's/<OLD_UUID/<NEW_UUID/g' @home

BTRFS send|receive is non-destructive so you'll still have the previous subvolumes intact at their current locations to act as backup in case something goes wrong. Once you're booting to the SSD, you can delete or retain them as backups.

[oshunluvr]

If you go the add-remove partitions route:

Assume;

/dev/sda1 is your current btrfs file system.
/dev/sdb1 is your SSD partition that you're going to move to.

Mount the root file system;

mount /dev/sda1 /mnt/here

Add the SSD partition to the file system;

btrfs device add /dev/sdb1 /mnt/here

Balance the data so the metadata and system is duplicated on both partitions;

btrfs balance start /mnt/here

When balance is complete, remove the old partition;

btrfs device delete /dev/sda1 /mnt/here

When remove is complete, wipe out the old partition so BTRFS doesn't try to add it back in later;

wipefs /dev/sda1

*Alternately here, you could reformat the partition to generate a new unique UUID.

The length of time this will take will depend on how much data you have. The balance and remove commands will take time and you must wait for each one to complete before the next step.

I used this method on my server to move to a new drive from two old drives. I had 2x2TB drives in a single BTRFS file system with almost 4TB of data in 12 subvolumes. Moving each subvolume would have taken a lot of my attention. Instead, I added a new 6TB drive to the file system, balanced the file system, and removed each of the 2TB drives one at a time. This much data took over night to do. Eventually as I needed more space, I added an additional 6TB drive to the second one, then a couple years later eventually moved to a single 10TB drive keeping the 2x6TB drives as backup space.

[oshunluvr]

Obviously the above commands in both posts would require sudo or a root shell.

[PhysicistSarah]

BTW, just a heads up, we're getting a snowstorm and I have to travel to school, so I might not reply for a while (Depends, things might get hectic and I might not have much free time), but I'll try to watch an reply to the thread.

I never thought to use send | receive in reverse. In hindsight, that's really obvious

I would have to see what to do about the EFI partition before doing anything.

Thanks for the great posts though!

[oshunluvr]

Stay warm and off the roads!

[wartnose]

What happened to GreyGeek? Thought he would have pounced on a BTRFS thread. Hope he is OK.

[mr_raider]

I've done this many times, in an EFI setting. Honestly I prefer using clonezilla. It images and copies the whole drive including the EFI partition.

Sent from my ONEPLUS A6003 using Tapatalk

[Snowhog]

What happened to GreyGeek? Thought he would have pounced on a BTRFS thread. Hope he is OK.

See his 'fond farewell': https://www.kubuntuforums.net/showth...-Fond-Farewell

[PhysicistSarah]

Hmm, I can't imagine a point in my life where I would leave the internet for any significant amount of time.

Wish him the best

[oshunluvr]

Hmm, I can't imagine a point in my life where I would leave the internet for any significant amount of time.

Wish him the best

A generational difference no doubt

[PhysicistSarah]

A generational difference no doubt

Maybe, maybe not.

I just like knowing whats going on, chatting with friends occasionally and researching things.

Also hacking around on KDE

[PhysicistSarah]

Just curious, re-creating the EFI partition just involves making a 500GiB fat32 paritition in GParted and setting the appropriate flags right? I don't want to format my /dev/sda drive and discover that something went wrong with the EFI