On January 12, 2023 1:56:36 AM EST, Simon Matter simon.matter@invoca.ch wrote:
On 01/11/2023 01:33 PM, H wrote:
On 01/11/2023 02:09 AM, Simon Matter wrote:
What I usually do is this: "cut" the large disk into several pieces
of
equal size and create individual RAID1 arrays. Then add them as LVM
PVs
to one large VG. The advantage is that with one error on one disk, you wont lose redundancy on the whole RAID mirror but only on a partial
segment.
You can even lose another segment with an error on the other disk
and
still have redundancy if the error is in another part.
That said, it's a bit more work to setup but has helped me several times in the decades ago.
But is your strategy of dividing the large disk into individual
RAID1
arrays also applicable to SSDs? I have heard, perhaps incorrectly,
that
once a SSD fails, the entire SSD becomes unusable which would
suggest
that dividing it into multiple RAID1 arrays would not be useful?
Follow-up question: Is my proposed strategy below correct:
- Make a copy of all existing directories and files on the current
disk
using clonezilla.
Install the new M.2 SSDs.
Partitioning the new SSDs for RAID1 using an external tool.
Doing a minimal installation of C7 and mdraid.
If choosing three RAID partitions, one for /boot, one for /boot/efi
and
the third one for the rest, do I go with the default mdraid version,
ie
1.2 I believe?
I think at least /boot/efi must be on an mdraid version which has its metadata at the end of the partition, I'm not sure about /boot. That said, I think the installer should take care here but I'm not sure it already does on C7.
- Copying the backup above with contents of the the existing disks,
ie not
just /root and /home but all other directories and files to the new
disks
from the clonezilla backup. Note that the new disks will be larger.
I can't comment on clonezilla as I've never used it. Tar and rsync are my friends when doing such things. I think you may have to take special care for boot related stuff like things in /boot and boot/efi. The other thing to care is for hardware related stuff like UUIDs generated in /etc/udev. The whole undertaking is not trivial.
- Change the boot sequence in the BIOS and reboot.
That's EFI, yes? I still fell like a greenhorn with EFI :)
Regards, Simon
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Upon further thinking, I am wondering if the process below would work? I have now have two working disk setups in the same computer and depending on the order of disks in the BIOS I can boot any of the two setups.
My existing setup uses one disk and no RAID (obviously), LUKS and LVM for everything but /boot and /boot/efi, total of three partitions. The OS is Centos 7 and I have made a complete backup to an external harddisk using rsync ("BACKUP1").
The new one uses two disks, RAID1, LUKS and LVM for everything but /boot and /boot/efi, total of four partitions (swap has its own partition - not sure why I made it that way). A minimal installation of Centos 7 was made to this setup and is working. In other words, UUIDs of disks, partitions and LUKS are already configured and working.
So, I am now thinking the following might work:
- Make a rsync backup of the new disks to the external harddisk ("BACKUP2").
- Delete all files from the new disks except from /boot and /boot/efi.
- Copy all files from all partitions except /boot and /boot/efi from BACKUP1 to the new disks. In other words, everything except /boot and /boot/efi will now be overwritten.
- I would expect this system not to boot since both /etc/fstab and /etc/crypttab on the new disks contain the UUIDs from the old system.
- Copy just /etc/fstab and /etc/crypttab from BACKUP2 to the new disks. This should update the new disks with the previously created UUIDs from when doing the minimal installation of CentOS 7.
What do you think?