Swapping out an old 2TB pcie 3 drive for a newer 2TB pcie 4 drive.
I was leaning towards using dd, after shrinking the partition on the source drive so it doesn't also 'copy' all the empty space.
Have you done this recently? What was your method?
Or is there a CachyOS/kde tool I may be unaware of?

all 33 comments

sorted by: hot top controversial new old
[–] 29 points 3 weeks ago (3 children)

For my personal workstation, it's such a rare thing I always use that an excuse to start from scratch again. If it's like a business system or something, usually build a new system and migrate data and services to it gradually.

I so rarely do in-place upgrades of system drives unless it's a recovery or something.

  • source
  • hideshow 6 child comments
  • [–] 4 points 3 weeks ago*

    Pretty much this. I’d copy anything I want to keep onto a temporary drive, (cloud storage, a USB drive, second SSD, etc), then use it as an excuse to refresh my install. Then just copy everything from that temporary storage after my new install is finished.

  • source
  • parent
  • [–] 3 points 3 weeks ago

    True. Starting with a fresh install can be more of a performance boost than buying a new drive. Add them together though and your computer is going to feel like future tech. I'd also just reinstall, unless its a server or a pain to rebuild.

  • source
  • parent
  • [–] 3 points 3 weeks ago*

    I'm about to do just that, but a bit overwhelmed. Over the many years of using Debian (not a heavy user though, only some slow progressing self host projects), there are many utilities or programmes I installed that I wouldn't remember, is there an easy way to identify what is not "base" Debian and list them, so I'd reinstall them?

  • source
  • parent
  • [–] 13 points 3 weeks ago* (1 child)

    Last time I did this I used btrfs.

    Add the new drive to the system, create partitions, add the new volume and then remove the old one, btrfs moves all the blocks to the new drive.

    The ESP partition is small enough and FAT- enough to just use cp.

  • source
  • hideshow 2 child comments
  • [–] 6 points 3 weeks ago (1 child)

    Huh.

    I never thought of using that feature of btrfs that way. Brilliant.

  • source
  • parent
  • hideshow 2 child comments
  • [–] [S] 3 points 3 weeks ago (1 child)

    Yeah, I think i'll give this a go

  • source
  • parent
  • hideshow 2 child comments
  • [–] 3 points 3 weeks ago*

    I would add that a slightly better way would be to do it in raid1 mode instead of single mode.

    That way you can move the data over by running a balance, instead of by removing the old volume, which would survive the process being interrupted by a reboot or whatever else.

    Then after the balance you can remove the old volume and turn the new one back into a single volume.

  • source
  • parent
  • [–] 11 points 3 weeks ago*

    btrfs device add /dev/newdrive /

    btrfs device remove /dev/olddrive

  • source
  • [–] 9 points 3 weeks ago (1 child)

    disk destroyer? I prefer just formatting and rsync-ing things. Unless I care about preserving metadata.

  • source
  • hideshow 2 child comments
  • [–] 7 points 3 weeks ago

    Clonezilla Live USB ftw

  • source
  • [–] 6 points 3 weeks ago* (last edited 3 weeks ago) (1 child)

    Anything important is already stored elsewhere, so I just install clean.

  • source
  • hideshow 2 child comments
  • [–] 3 points 3 weeks ago (1 child)

    Honestly dd is perfect. Like you say, shrink the partition down first, DD to the new disc, swap discs. That's it.

  • source
  • hideshow 2 child comments
  • [–] 3 points 3 weeks ago

    Adjust partition size if neccessary, then cp /dev/sda /dev/sdb.

  • source
  • [–] 3 points 3 weeks ago

    Reinstalling because I use ZFS.

  • source
  • [–] 2 points 3 weeks ago*

    I usually use Clonezilla and have it verify the data after cloning. It works for local drives, but it can also clone a drive over the network by running it on both the source and destination system, which is very useful for remote servers (eg moving a VPS to a different location).

  • source
  • [–] 2 points 3 weeks ago* (last edited 3 weeks ago)

    I always use dd or ddrescue. Takes 20min to open the computer, connect the drives, boot from usb, copy everything and you'd be done. Also super easy. Just pay a lot of attention before hitting enter. One small mistake and you copy it the wrong way around. Or overwrite your old drive in some other way.

  • source
  • [–] 1 point 3 weeks ago

    Same thing you suggested, plus a btrfs scrub to check integrity when finished. I suspect btrfs provides a more elegant mechanism for this, which I have been too lazy to look up.

    I could never reinstall ... I end up customizing so extensively that a few years ago, I centralized all of my customizations in a VM image that I clone if I do need a fresh install.

  • source
  • [–] 1 point 3 weeks ago (1 child)

    I have a bunch of scripts to install my systems. Anything important is already backed up to my storage system.

  • source
  • hideshow 2 child comments
  • [–] 1 point 3 weeks ago

    Personally, when I get a new SSD I:

    • Format as 4Kn (for 'Better' or 'Best' performance)
    • Reinstall my preferred distro with a seperate home subvolume/partition (and tmp, var, etc. often with nodev,nosuid,noexec set)
    • Copy my /home across, and parts of /etc.
  • source
  • [–] 1 point 3 weeks ago* (1 child)

    Out of curiosity, what are you doing that the difference between the two is woth that effort? Or is the pcie3 drive bottom of the barrel maybe?

  • source
  • hideshow 2 child comments
  • [–] 1 point 3 weeks ago

    Gparted works great as well, just umount drive and copy

  • source
  • [–] 1 point 3 weeks ago
    [–] 1 point 3 weeks ago* (last edited 3 weeks ago)

    There's a way to do it without shrinking the partition and dd until last used block.

    I use this to copy my Linux setup for a nas down to a 4 gig ISO for redeploy.

    Have to check my notes...

    Edit: Checked Notes

    #Use-case of fdisk taking the approach that fdisk is used, and assumption is your "sudo fdisk -l " produced:

    Disk /dev/sda: 64.0 GB, 64023257088 bytes
    255 heads, 63 sectors/track, 7783 cylinders
    Units = cylinders of 16065 * 512 = 8225280 bytes
    Sector size (logical/physical): 512 bytes / 512 bytes
    I/O size (minimum/optimal): 512 bytes / 512 bytes
    Disk identifier: 0x0000e4b5
    
    Device Boot Start End Blocks Id System
    /dev/sda1 * 1 27 209920 83 Linux
    Partition 1 does not end on cylinder boundary.
    /dev/sda2 27 525 4000768 5 Extended
    Partition 2 does not end on cylinder boundary.
    /dev/sda5 27 353 2621440 83 Linux
    /dev/sda6 353 405 416768 83 Linux
    /dev/sda7 405 490 675840 83 Linux
    /dev/sda8 490 525 282624 83 Linux
    

    The two things you should take note of are

    1. the unit size, and
    2. the "End" column.

    In this case you have cylinders that are equal to 8225280 Bytes. In the "End" column sda8 terminates at 525 (which is 525[units] * 16065 * 512 = ~4.3GB)

    dd can do a lot of things, such as starting after an offset, or stopping after a specific number of blocks. We will do the latter using the count option in dd. The command would appear as follows:

    sudo dd if=/dev/sda of=/your_directory/image_name.iso bs=8225280 count=526

    Where -bs is the block size (it is easiest to use the unit that fdisk uses, but any unit will do so long as the count option is declared in these units), and count is the number of units we want to copy Note that we increment the count by 1 to capture the last block).

    Note to display units in cylinders: fdisk -l -u=cylinders /dev/sda Note for newbies of dd that of= can be a device you write to i.e. /dev/sdc, rather than a path to an iso image.

  • source
  • [–] 1 point 3 weeks ago

    this is why i use lvm's.

    i add the new drive to the lvm and afterwards remove the old drive from the lvm.

  • source
  • [–] 1 point 3 weeks ago

    I use a decent cloning tool like foxclone, dd isn't really the right tool for that kind of thing IMO.

  • source