Cloning an SSD remotely.

[Whoever]

Please tell me if this will work. I have a CentOS 7 system that is in a datacenter. It's not a rack-mount system: the motherboard is an old (probably about 12 years old) and doesn't have UEFI. The hard drive (SSD) in the system is failing, so I am trying to prepare a new hard drive that can be swapped into the system.

I have done the following:
Grabbed the first 512 bytes of the SSD and copied this onto the new SSD.

With this 512 bytes, the partition table showed /boot as a primary partition and the second partition was a PV.

Used mkfs to make a new filesystem in the first partition, using the same filesystem type (XFS).

Copied all the files from /boot on the running system to the new filesystem for /boot.

Deleted the second partition and created a new partition taking up the remainder of the space. Used pvcreate and vgcreate to make a volume group with the same name as the source. Added logical volumes, again with the same names as the source and made filesystems (xfs) in the new logical volumes. There is a /home filesystem, but it is empty.

Used rsync to copy the contents of / to the new centos-root logical volume. I used the "-x" option to keep this to only the / filesystem, but this means that the /dev /sys and other filesystems are completely empty.

The / filesystem is mounted using the path /dev/mapper/centos--root, so I should not need to worry about the UUIDs not matching.

I have a couple of concerns:
1. I seem to recall that grub uses the space between the boot record and the start of the first partition. Is this true? If so I may have missed this data. How should I resolve this?
2. I used a Linux Mint system to do this, so there is a possibility that the xfs filesystem may not be backwards compatible with the older CentOS kernel.

[TrevorH]

1. I seem to recall that grub uses the space between the boot record and the start of the first partition. Is this true? If so I may have missed this data. How should I resolve this?

It does. Dump all the space from the start of the disk to the start of the first partition. Or probably better, reinstall grub on it on the target machine once it's installed.

2. I used a Linux Mint system to do this, so there is a possibility that the xfs filesystem may not be backwards compatible with the older CentOS kernel.

A distinct possibility. Try running xfs_info against both filesystems and see if they are the same.

If it were me I'd try to get the new disk installed alongside the old one and then dd old to new, get old removed and reboot from new.

[Whoever]

2. I used a Linux Mint system to do this, so there is a possibility that the xfs filesystem may not be backwards compatible with the older CentOS kernel.

A distinct possibility. Try running xfs_info against both filesystems and see if they are the same.

New:
~# xfs_info /dev/sdc1
meta-data=/dev/sdc1 isize=512 agcount=4, agsize=65536 blks
= sectsz=512 attr=2, projid32bit=1
= crc=1 finobt=1 spinodes=0 rmapbt=0
= reflink=0
data = bsize=4096 blocks=262144, imaxpct=25
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0 ftype=1
log =internal bsize=4096 blocks=2560, version=2
= sectsz=512 sunit=0 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0

Old:
# xfs_info /boot/
meta-data=/dev/sda1 isize=512 agcount=4, agsize=65536 blks
= sectsz=512 attr=2, projid32bit=1
= crc=1 finobt=0 spinodes=0
data = bsize=4096 blocks=262144, imaxpct=25
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0 ftype=1
log =internal bsize=4096 blocks=2560, version=2
= sectsz=512 sunit=0 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0

If it were me I'd try to get the new disk installed alongside the old one and then dd old to new, get old removed and reboot from new.

That requires two trips to the datacenter. It's only 7 miles down the road, but I really try to minimize the number of times I go there.

[TrevorH]

That requires two trips to the datacenter. It's only 7 miles down the road, but I really try to minimize the number of times I go there.

Take a warm jumper and wait. Directly cabled up, two SSD's ought to copy at a minimum of 250MB/s and might go as fast as 500. At 500MB/s even 1TB would be done in 35 minutes. Maybe an hour if it runs at the slower speed. Most datacentres have a crash cart that you can borrow with monitor/keyboard/mouse (I've been asked to leave a debit card in a sealed envelope at at least one to make sure I brought it back!).

[Whoever]

That requires two trips to the datacenter. It's only 7 miles down the road, but I really try to minimize the number of times I go there.

Take a warm jumper and wait. Directly cabled up, two SSD's ought to copy at a minimum of 250MB/s and might go as fast as 500. At 500MB/s even 1TB would be done in 35 minutes. Maybe an hour if it runs at the slower speed. Most datacentres have a crash cart that you can borrow with monitor/keyboard/mouse (I've been asked to leave a debit card in a sealed envelope at at least one to make sure I brought it back!).

Time for an update:
Eventually, I brought the machine home (it's a Mini-ITX system, so quite small).

I tried cloning the hard drive: first in a USB hard drive dock that has a clone function, which I gave up on after several hours, and then using dd. With dd, it copied about 23GB in a few minutes than hung up with a stream of errors (even with conv=noerror). However, this was enough to copy the bootloader and the /boot partition.

Using a CentOS installation USB in recovery mode, I created the root ("/"), home and swap logical volumes/filesystems and then on my normal desktop, populated the root filesystem. This then booted, but would not let me log in, so one more trip to my desktop to add the file /.autorelabel and, after relabeling, it booted and allowed me to log in.