Pretty sure I know how to use rsync to clone my home directory and update /etc/fstab. However, being unfamiliar with NVMe drives, I thought I’d throw out a quick ask as to any pitfalls I should be aware of and or anything “I don’t know that I don’t know”.
.
Also checking Arch Wiki of course 
…down the road, I’m also contemplating moving the base OS to a SSD (currently using an old HDD). I’ll probably use clonezilla live for that part.
Just make sure you have the naming correct for the nvme drive is all i can think of.
Edit: Depending on what you are doing exactly?
Example: /dev/nvme0n1
…just migrating my home directory to an NVMe drive.
I think you can even do that easily with the cp command. All you would need to do is partition and format the drive first.
Both cp and rsync can be used, just need proper options to copy file permissions too.
Ya… that’s where i get lost. 
options and permissions!
Why keep the system on the slower disk?
Personally, I would move it all to the new faster drive.
Contemplating just wholesale moving everything and just creating a separate /home partition.
I recall that it was once considered a good practice to keep /home on it’s own partition or a separate drive altogether in the event of a major failure of the OS so you have the ability to re-install while preserving your personal data. Used to do that as a matter of course but, as Linux OS’s got more reliable, I worried about it less.
Reinstalling Steam would involve extra steps to save the already installed games, but still doable.
Sounds like a good plan.
That’s how I do it…and as for moving …I use dd. Boot your system with a bootable disc or USB, find your old drive & the new drive (I use gparted) —then dd everything from old to new. Command looks like:
dd if=/dev/sda of=/dev/sdb bs=4096 conv=notrunc,noerror,sync status=progress
Where sda is the old drive & sdb is the new drive -insert the correct values for your drives, when it finishes shut down, remove your old drive & reboot. The new drive will have all of the identifiers of the old drive.
The beauty of dd is that it copies verbatim…permissions and all.
Sometimes a separate /home partition may be a good idea.
But sometimes having it separate can cause problems, because you usually decide in the beginning how big the partitions will be. And that can be challenging to predict, especially if the root partition was selected too small to begin with. Packages tend to grow given enough time.
Anyway, I think a reasonable backup system should in most (if not all!) cases be the best way of preserving one’s personal data. If backups are in order, a separate /home partition may be just extra work that doesn’t help really anything.
Of course everyone can do as they wish. Just thinking about alternative ways of handling things.
Yea, this is why I was thinking make them separate physical drives. Just move /home initially, then upgrade my old HDD to a SATA SSD and move the main OS to that. All that being said, my idea of a separate partition may be outdated as you suggest. It does come from a time when I was playing around with RedHat 4.2 when kernels were complied from source and catastrophic (albeit self-inflicted) OS failures were relatively common.
I’m going to educate myself on dd, thanks 
I’m assuming it gets the boot partition and everything?
It is possible to simply copy (with cp or rsync) a full system (=all files) to another drive. I’ve done that successfully a few times. Of course owners and permissions must be preserved for all files too (e.g. cp -a ...).
I’ve even copied a system from a virtual machine into native hardware using cp.
The things that will need work after the copy are (at least)
/etc/fstab (UUIDs changed)grub-install with proper parametersgrub-mkconfig -o /boot/grub/grub.cfgAnyway, whatever you do, remember to do backup (your precious personal data) first.
Ok, reading up on dd… My destination drive is twice as big as my source drive so, I’d have to resize it when it was done. I suspect I’d also need to update /etc/fstab as well since the device identifier will change. On the other hand, It won’t destroy data on the input drive so, I can always boot back to that if things go sideways.
Resizing will NOT change any identification…at least it won’t change anything that fstab uses. You can grow or shrink the individual partitions without UUID changes. If you do a complete disc copy, grub will be moved with all its booting intact.
People seem to be afraid of dd because it is SO literal… I really like using dd for that very reason.
The BIG thing you need to remember is to REMOVE the old drive completely from the system BEFORE you reboot…you WILL have 2 drives that are EXACTLY the same…you can easily see where that would head.
Also—I have tried lots of different commands for dd…the one I posted above works every time & gives feedback to you while it is working…a BIG plus.
As far as resizing goes…I do all the manipulation on the new drive before I reboot (from the USB or whatever you booted with)…After dd is done, resize/create new partitions/whatever next, then mount the new drive. Using gparted, you can get the UUID for a new partition (in information) & modify fstab to add a /home. Then it’s just a matter of coping your old home over to the new home, making sure that permissions are maintained…that is a job for rsync or cp.
Remember, during this time you would have 2 copies exactly the same available to you (old drive & new drive) so if you flub up—you have a backup copy available. That goes for the whole operation,as long as you have the old drive available—you can make mistakes without harm…just REMEMBER which drive you are going from & to (if=old drive of=new drive).
Ok so, I get a bootable USB that’s got dd and gparted available. Let’s say I’m NOT going to create a separate partition for /home. All I want to do is resize the destination drive before rebooting.
Since I’m moving from an HDD to a NVMe drive, don’t I still have to manually edit fstab so that it has the correct UUIDs for / and /efi before attempting to reboot on that drive?
If you dd the whole drive…NO. dd will copy everything EXACTLY from the old drive to the new drive----including the correct UUIDs. As far as dd is concerned—a drive is a drive.
dd is a command that can be run on any modern (and not so modern) Linux system…almost every bootable I’ve used has gparted available (it’s just a GUI parted)…so copy & resize can be done with almost anything…I use a bootable current version of Linux Mint for most of the mods I do for people…easy & has all the tools.
Ok then, thanks. I just grabbed and tested gparted live and dd is available on it. From what I’ve been able to learn on the dd command itself, your block size looks pretty reasonable. Other options make sense as well. Was also considering clonezilla, and it seems like a good tool but, this looks do-able.
…
As for the “separate partition for /home”. Other forums are convincing me that’s no longer as important as it used to be. If anything, a separate partition for /var might be a better thought to keep a badly behaving script from loading up my logs files. That’s a thought for another day though ;).
Should have the new drive tomorrow.