Hard Drive Replacement

[JoHubb]

I run Kubuntu as my usual distro. My system is triple boot with Mint and Win10.

I have a total of six drives, 5HDD, 1SSD containing a lot of stored music, video and photo files. The SSD has the Windows 10 boot file.
Three of these drives are close to 16000 hrs usage and sometimes one of them makes an odd noise. I fear that one day it will crash.

I have backed up all my important data but the thought of re configuring all these drives the way I have them now fills me with dread.

So, I plan to make clones (replacements) of the hard drives one by one. I would be grateful for advice on how best to do this. I am not sure about MBR and how to make sure that when the cloned replacement drives are slotted in they will run properly.

Thanks!

[Don B. Cilly]

They should work just fine.
Just make sure you match the UUIDs of the disks with what you have in /etc/fstab.
To see the UUIDs use:
sudo blkid

And... I know I keep saying this and everyone thinks I'm crazy, but...

Something that would immediately tell you if something is wrong with the fstab would be to boot in "text" mode.
The output is too fast to read, but if something "hangs", you notice it immediately.
In the case of mismatched UUIDs, you'll see something like: "a start job started by dev-disk-by ..." which hangs for minutes.

To do boot in text mode, edit /etc/default/grub.
Change
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
to
GRUB_CMDLINE_LINUX_DEFAULT=""
and then do
sudo update-grub

[JoHubb]

They should work just fine.
Just make sure you match the UUIDs of the disks with what you have in /etc/fstab.
To see the UUIDs use:
sudo blkid

Many thanks!

Maybe I am underestimating the complexity of the cloning process.

It seems from this that some partitions have their own UUIDs. Which UUID to use when I clone an entire disk?
I've done this in Windows but maybe it isn't as straightforward in Linux.

[Don B. Cilly]

Well, if you clone them, the UUID should get cloned too.
I was just mentioning that if you do get problems - they can occur - booting in text mode is the easiest way to spot them, and checking fstab for mismatches the... most likely way to fix them.

[EDIT] You know how I know this? Not long ago, I cloned a disk because it was failing.
But I didn't disconnect the old one. Which led to two disks having the same UUID. No end of trouble.
Mainly thanks to this forum, I sorted it out, but it was rather messy for a while :·)

[jlittle]

Be clear about the difference between drives (aka "disks", even when they're not disks) and file systems, aka partitions. A drive can have several partitions, and typically does. Both drives and file systems have UUIDs.

*buntus do not use the drive UUID for anything as far as I am aware. fdisk -l will show it as the "Disk identifier". But Windows might for its purposes, maybe for boot and licensing. fdisk in expert mode can set it, as can the windows "diskpart" utility, but I have no idea how advisable this would be; it's really a windows thing. When a new partition table is written to a disk, a new disk identifier is generated.

blkid shows file system UUIDs. If you clone a whole disk all the partitions get cloned along with their UUIDs. If you clone a partition, its UUID is cloned. If you have a file system and its clone in a system when it boots it's bad, with both OS and user really confused. Like Don B. Cilly I've made that mistake. There's lots of ways to write a new UUID to a partition; I like using gparted.

Crucially, by default grub uses UUIDs to find itself and the OS to boot. Linux by default mounts drives via /etc/fstab using the UUIDs. Use sudo update-grub to make grub aware of changes to UUIDs, and you can edit /etc/fstab if necessary.

(I hate UUIDs, they've caused me pain over the years. Neither grub nor /etc/fstab need to use them, they can use labels, which are much easier for humans to use and remember. My Kubuntu uses labels, but I can because I manually maintain my grub configuration. Labels have the same pitfalls as UUIDs if you clone a drive or partition.)

[jlittle]

Three of these drives are close to 16000 hrs usage and sometimes one of them makes an odd noise.

I suggest you check the SMART (Self-Monitoring, Analysis and Reporting Technology) info for your drives. The KDE partition manager can show at least some of it, otherwise the command smartctl can show it.

[GreyGeek]

....*buntus do not use the drive UUID for anything as far as I am aware. ...

https://help.ubuntu.com/community/UsingUUID

Linux prefers to use UUID (Universally Unique Identifier), LABEL, or symlinks to identify media storage devices on a system. Using device assignments (like /dev/hd*# or /dev/sd*#) is not preferred since these can change between system boots:

• [*=left]all filesystems should be specified by UUID=<id> or LABEL=<name> for each partition.
  
  [*=left]all physical devices should be specified by a symlink, like /dev/cdrom for a cd drive and /dev/disk/by-id/... for each physical hard drive.

The files for which UUID is most critical:

• [*=left]/boot/grub/menu.lst
  
  [*=left]/etc/fstab
  
  [*=left]/etc/initramfs-tools/conf.d/resume

Back a few years ago when I was testing the BTRFS I added 2nd HD so I could experiment with RAID 1. Then I pulled my CDROM and put in an HD Caddy so I could add a third drive to this laptop. When I did that /dev/sda swapped places with what should have been /dev/sdc and my primary drive became /dev/sdc. The drive in the HD Caddy became /dev/sda. I started getting msgs about redundant drive labels which annoyed me. Investigating that msg I learned about why one does NOT use /dev/sdX to referrence drives in a modern Ubuntu (or any Linux). You *may* get away with it but it will eventually bite you in the nether regions.

[Don B. Cilly]

Yeah well. I was oversimplifying.
But then, considering the OP's

Maybe I am underestimating the complexity of the cloning process.

maybe we don't want to overcomplicate things either. At least not yet :·)

I would say, as long as you don't have duplicate disks in the box, all should be well.
Clone a disk, with all the filesystems and partitions, swap it - take out the old one - and the system should not even notice it.

In case there are some - which you'll notice - /etc/fstab is probably the place to look, and blkid will give you the information to fix it.

[oshunluvr]

I you need to "un-clone" the UUIDs'' this should do it:

sudo tune2fs /dev/sdXX -U random /dev/sdXX

replace XX with the device letter/partition number.

I think the "cleanest" process would be to make the clone then change the UUID on the original file system. Then reboot or re-mount. You'd be using the clone right away without hassle and the source file system would be untouched except for it's new UUID.

[Don B. Cilly]

Gparted can do that.
The KDE partition manager can't.
It's a good thing to have both, IMO.