When you say system drive this will also have your efi system partition (usually FAT-formated as that’s the only standard all UEFI implementations support), maybe also a swap partition (if not using a swap file instead) etc… so it’s not just copiying the btrfs partition your system sits on.

Yes clonezilla will keep the same UUID when cloning (and I assume your fstab properly uses UUIDs to identify drivees). In fact clonezilla uses different tools depending on filesystem and data… on the lowest level (so for example on unlocked encrypted data it can’t handle otherwise) clonezilla is really just using dd to clone everything. So cloning your disk with clonezilla, then later expanding the btrfs partition to use up the free space works is an option

But on the other hand just creating a few new partitions, then copying all data might be faster. And editing /etc/fstab with the new UUIDs while keeping everything else is no rocket science either.

The best thing: Just pick a method and do it. It’s not like you can screw up it up as long if your are not stupid and accidently clone your empty new drive to your old one instead…

I would recommend using this as an opportunity to build out and use a backups system. Whenever I get a new laptop, for example, I just make a(nother) backup on the old laptop and restore whatever I want to the new one. If there are any files I want that are normally excluded from backups, I either tweak my rules to include those files/put them in a different directory and repeat the process or just make a new manual external backup copy temporarily.

If you have good backups then your new drive can be populated from them after creating new partitions. Optionally, you can also take this opportunity to reinstall the OS, which I personally prefer to do because it tends to clean up cruft.

Also, if you go this route, your data on your old drive is 100% intact throughout the process. You can verify and re-verify that all the files you want are backed up + restored properly before finally formatting the old drive for use in the NAS.

Clonezilla can clone BTRFS without issues

Afterwards on the system use sudo btrfs filesystem resize max / to make it use that space. Maybe add a balance.

Do you have pci-e slots? An nvme to pcie card is cheap - it’s pretty much just passing from one connector shape to another.

I had a similar case.
My minipc has a microSD card slot and I figured if it could be done for a RPI, why not for a mini PC? :P

After a few months I bought a new m2nvme but I didn’t want to start from scratch (maybe I should’ve looked into nix?)
So what I did was sudo dd if=/dev/sda of=/dev/sdc bs=1024k status=progress
And that worked perfectly!

Things to note:

• both drives need to be unmounted, so you need a live OS or another machine.
• The new drive will have the same exact partitions, which means the same size, so you need to expand them after the copy.
• PS: this was for a drive with ext4 partitions, but in theory dd works with the bytes so it shouldn’t be an issue what fs you use.

Personally, if the NAS is up and running, I’d migrate the home directory and anything else important from the desktop to that, and intend to network host those folders; set aside the 1TB, install the 2 TB, and do a fresh install and see if I can still get to everything happily.

Alternatively–if you want to preserve stuff locally–new drive in an enclosure, attach to desktop, boot from an install USB, fresh install to 2TB, reboot from 2TB, mount 1TB, migrate data, install 2TB. I don’t think there should be a UUID problem doing that, but even if there was you could still boot from the install stick and try manually fix it

Is your system drive really that: just a system drive? Then you’d better install it from scratch and have a clean, shiny and new system.

Backup a few settings maybe. Or maybe not.

If you’re feeling adventurous:

• You can use a thumb drive to boot.
• Verify the device path for your normal boot disk and for your new drive using gnome disks or similar. In this example I’ll call them /dev/olddisk0n1 and /dev/newdisksda
• really, really don’t mix up the in file and out file. In file (if) is the source. Out file (of) is the destination.
• sudo dd if=/dev/olddisk0n1 of=/dev/newdisksda bs=128M
• or, of you want a progress indicator: sudo pv /dev/olddisk0n1 > /dev/newdisksda
• wait a long time

Not that this is the recommended method if you’re new to the terminal, but it’s totally viable if you have limited tools or are comfortable on the command prompt.

Unless you’re using three new disk on the same system, you don’t have to worry about UUIDS, though they will be identical on both drives.

Your system is likely using UUIDs in fstab. If so, you don’t have to worry about fstab. If not, there’s still a damned good chance you won’t have to worry about fstab.

To be sure, check fstab and make sure it’s using UUIDs. If it’s not, follow a tutorial for switching fstab over to using UUIDs.

It would probably be more reliable to partition and format the new drive manually and use rsync to copy everything over. Updating /etc/fstab with the new UUIDs isn’t a big deal (though you can also manually specify the partition UUIDs at time of format - mkfs.btrfs --uuid ...) (you didn’t say what file system your /boot partition was using, so I don’t want to guess).