Cloning drive to new ssd

Is there a good way to clone a whole install to a new ssd?

I’ve tried clonezilla and it didn’t really work… it just copied the boot partitions and my home and root folders, but nothing else so it couldn’t boot fully.

I tried using DD with “dd if=/dev/sda of=/dev/nvme0n1 bs=128K conv=noerror,sync status=progress”

And the same thing happen… I’m guessing it’s because of btrfs? I did run the command off a live USB… should I have done it while booted into my main install instead?

Thank you for your time.

create a snapshot of your current filesystem. You can do this with the following command:

btrfs subvolume snapshot -r / /snapshot

This will create a read-only snapshot of your filesystem called /snapshot.

Once you have created the snapshot, you can use the btrfs receive command to copy it to the new ssd. You can do this with the following command:

btrfs receive /dev/nvme0n1 /snapshot

This will create a copy of the snapshot on the new ssd.

That will not deal wirh any /boot partitions.

Personally i would install fedora to the new ssd then copy the data from old to new disk for /home. And check config changes in /etc.

1 Like

Well, what if i do a fresh install on the drive then do btrfs receive /dev/nvme0n1p3 /snapshot?

Then the boot partitions should be there and only copy everything to the nvme0n1p3 partition right?

I’d very much rather have a carbon copy of everything if possible. Lol

If you use the SSD unformatted with the dd command you likely copy the alignment of one drive (the existing) onto the SSD resulting in a drive error and also potentially lost data.
For the ESP and boot partitions, you should recreate them first on your new drive, then make the rest of it a BTRFS volume. When using the btrfs tools you must be sudo, but they will not copy the ESP and /boot (which is ext4) partitions. They are only good for copying the subvolumes mounted at /, /var, and /home. So you can dd the firsdt two partitions (ESP and /boot) as usually dev/sda1 and /dev/sda2 if it was the default install, specifically to the SSD first then use the BTRFS subvolume commands. I just did a backup of my home using btrfs subvolume snapshot and btrfs send/receive as follows …

sudo btrfs subvolume snapshot -r /home /home/fedora-home/btrfs-top-lvl/home20230818

to make the snapshot of /home stored in /home/fedora-home/btrfs-top-lvl/<nameofsnapshot>

Then to send it to my USB backup drive …

sudo btrfs send home20230818 | btrfs receive /run/media/ssnow/butterback

So I’d have to run btrfs subvolume snapshot -r / /snapshot, but for Home and Var as well?
btrfs subvolume snapshot -r home /snapshot
btrfs subvolume snapshot -r var /snapshot

just doing / wouldn’t just do the whole btrfs partition?

Sorry for not understanding clearly, I’ve never used the features of btrfs.

How I’m understanding this so far, I use dd for the 2 smaller partitions on the unformatted drive, then btrfs snap shot on the other 3 volumes after making the rest of the drive a btrfs partition?

The drives are (the main drive) /dev/sda and (The new drive) /dev/nvme0n1

Yes that would seem the most straight forward.

No, the fact that the separate subvolumes of the single btrfs partition are treated as separate partitions more or less negates that.

So if you want the original layout with all configuration and user setup as is without a fresh installation as the method, the best way is to do a send/receive of a read only snapshot of the desired subvolume(s) to be copied. You can also snapshot the subvolumes (a full one, not a clone) to the new drive. In both approaches, it will require that you get into the Grub boot to change the UUID of the target boot systems since the UUID of the subvolume will be new. As well as changing the UUID’s off all the mount points in /etc/fstab to reflect their new id’s. If this seems too arduous (and it is a task), I recommend the fresh install with your same user. After install on the SSD, mount the old drive at a temporary mount point off of your home say, and you can actually do a full RW snapshot to the new SSD top level btrfs volume of your preferred /, /var and /home. Once you have the snapshots on your new drive you can check their info for the UUID to copy that into the /etc/fstab file, using sudo btrfs subvolume show <path to subvolume>. The paths can be found with sudo btrfs subvolume list <path to device with volume>
Use the show command to determine the actual UUID you are looking for, and using cat to look at your fstab file as it is should help you see how the mount points are specified currently and where you will need to change it.
It is important to keep in mind that I have never done this at this level, only ever doing it with /home while / and /var I did install again, along with any application I wanted back. The handy stuff for me was the configuration was still there along with SSH key’s etc… from my /home, and of course my data. And even in this method you will need to modify the Grub2 menu entries.
So if you choose fresh install, you can just mount the old drive and copy over the desired files as well.

So going back to your original idea, you could do the dd command for the ESP and ext4 partitions and then make the btrfs partition on the ssd. Then just mount that SSD btrfs volume to a path of your choice. Snapshot everything over to it from your existing setup. Go into the mounted new SSD and find the subvolume info you need and change fstab file accordingly. You could them chroot into this mount point to test if this is your original system, and change the Grub2 menu entry at this time, then simply reboot into the new system.

This link should help with this effort …

Oh my, that is a large task.

I do have a better understanding of how btrfs works though thank you for explaining, it was very helpful. How ever, I think it’d be equal amount of work to just reinstall and start over lol

I just really don’t want to reinstall my games and set everything back up the way I like it. It’s such a pain.

I’ll read up more about btrfs and snapshots. Thank you very much for your time.

Yeah, fortunately most configuration settings of user level are captured on snapshotting the home subvolume, but even adding var shouldn’t be that cumbersome. Then it would not require a Grub2 menu modification, just an fstab file modification which then makes the task far less intimidating. Potential areas to note would be file ownership of the new home. That (snapshotting /home and /var) would capture almost all/if not all of your added packages and your current system setup. There should be minimal cleanup afterwards.