T O P

clone from hdd to ssd

clone from hdd to ssd

ropid

The way I do things is I manually create the partitions and filesystems and use `cp -a` to copy the files. Then I fix /etc/fstab and boot loader config on the new drive to make sure it's pointing to the new UUIDs. With BIOS instead of UEFI it's also required to write a bootloader into the MBR sector. I forgot how that's done. You could use this chance to look into how full system backups using `cp -a` or `rsync` work. You can then use your backup to restore to the new drive. The dd command copies the raw drive and will give you errors if the drive sizes aren't exactly the same. It also writes all of the empty space which causes that "destroys endurance of the ssd" problem that you heard about. That isn't a super bad issue if you only do a dd copy occasionally. Don't forget to run `sudo fstrim -a` later on the new system to TRIM the empty space on the filesystems. The drive will get its normal performance back after the fstrim.


stormcloud-9

> The way I do things is I manually create the partitions and filesystems and use `cp -a` to copy the files. Just FYI, when doing it this way: * UUIDs change * You lose reflinks * You lose hardlinks * You lose some file attributes It's much simpler/safer to transfer the raw block device.   > The dd command copies the raw drive and will give you errors if the drive sizes aren't exactly the same. Correction: will give you an error if the destination is smaller. Will work fine if same size or larger.   > It also writes all of the empty space which causes that "destroys endurance of the ssd" problem that you heard about. You would have to do this for a few years before you exhausted the lifespan of the SSD.


ropid

The `cp -a` command works better than you think! You don't lose hardlinks, the copy will have them. You don't lose any attributes. About the UUIDs change, this is important. You have to manually fix /etc/fstab and boot loader config in the copy. I started using PARTLABEL in the configs instead of UUID to make this a bit easier. Reflinks are a bit unusual because ext4 doesn't have them. If you use btrfs, you perhaps know about btrfs send/receive and can use that over cp or dd. The interesting thing to me about cp -a really is that it's a bit of an introduction to how restoring from a full backup using rsync works. After I saw that doing it was actually pretty simple, at least in the sense that all steps are straight-forward with no hidden details, I got over inhibitions I had about setting up an rsync backup. About lifetime of an SSD in practice, on my Samsung 970 EVO drive here, manufacturer warranty runs out after 600 times rewriting the full drive. Another idea about this: using 'cp' over 'dd' might not be any better, it can't help if a drive is quite full. I experimented like this to make sure about cp -a and hardlinks: mkdir dirA cd dirA touch file1 ln file1 file2 ln file2 file3 cd .. ls -l dirA cp -a dirA dirB ls -l dirB The cp -a command managed to create a dirB with similar hardlinks as the original dirA. I also tried copying to a different filesystem and I tried copying a more complicated directory tree.


2cats2hats

> I hear dd destroys the endurance of the ssd. Where did you hear/read this? dd if /dev/sdX of=/dec/sdY bs=2048 && sync X and Y represent drive numbers.


StrangeAstronomer

When you're done, don't forget to enable 'trim'. On my system (fedora) I have : # systemctl status fstrim.timer ● fstrim.timer - Discard unused blocks once a week Loaded: loaded (/usr/lib/systemd/system/fstrim.timer; enabled; vendor preset: enabled) Active: active (waiting) since Mon 2021-05-24 16:27:02 AEST; 4 days ago Trigger: Mon 2021-05-31 00:18:18 AEST; 1 day 16h left Triggers: ● fstrim.service Docs: man:fstrim