Linux RAID-1 [8]: Setting up the replacement array

As I mentioned last time I have bought the 2 TB disks so that I can have a RAID-1 array in the main computer that is big enough to hold all of my stuff, meaning the second computer (and by extension, its screens and desk) will be effectively redundant. So here I am essentially repeating the steps of the earlier instruction sequence of the previous articles in this series.
After backing up my stuff, I shut the computer down, found the faulty disk from the 1 TB array and removed it from the PC. The other half of the array was left in the computer and reconnected while the two new disks were put into the other bays. With everything plugged in the computer was turned back on again and should have come back up straight off but it was not so easy as the 1 TB disk was now plugged into a different port, so a mdadm –assemble –scan command sequence was needed to get the 1 TB array back online. After another reboot everything is now where it is supposed to be so /home is back going again, and the two new disks are ready to be made into a new array.
The new disks are /dev/sdb and /dev/sde this time, so first thing to do is to partition them, using gnome-disk-utility, with one partition on each disk. Then we issue this command to create the array:
sudo mdadm –create –verbose /dev/md1 –level=mirror –raid-devices=2 /dev/sdb /dev/sde

After that we can see that /dev/md1 is online in GDU. Now have a look at /proc/mdstat and it tells us that /dev/md1 is resyncing and will be finished in about three hours. This does not preclude it from being used, however. So our next step is to format the 2 TB partition, mount it and then rsync the existing home drive to it. At the same time we can start to move data across from the 2nd computer, but before we do that, the 2nd computer needs to have its own local backup, so that is also started with another rsync.

Next is to save the details of the array for mdadm 
mdamd –detail –scan >> /etc/mdadm/mdadm.conf

I then rebooted and on running a blkid see the new array renamed to md127. Then we put it into /etc/fstab as the mount point for /home, and change the old disk to /oldhome. So the fstab first looks like
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
UUID=f49e5734-6c56-4f17-81b1-6423e4045e75 /               ext4    errors=remount-ro 0       1
UUID=cd9d465e-5574-4afd-85a6-851ace3959b7 none            swap    sw              0       0

UUID=6f1ea562-fb78-44ea-9262-d4234886064d /home           ext4    defaults        0       2

and now it will look like

UUID=f49e5734-6c56-4f17-81b1-6423e4045e75 /               ext4    errors=remount-ro 0       1
UUID=cd9d465e-5574-4afd-85a6-851ace3959b7 none            swap    sw              0       0
UUID=6f1ea562-fb78-44ea-9262-d4234886064d /oldhome        ext4    defaults        0       2

UUID=dfc4fa75-63e1-49ad-9a82-d9d0b826db3f /home           ext4    defaults        0       2

Now reboot is the simplest step to follow next. On coming back up after the reboot, everything is mounted correctly and some simple checks show that stuff is where it’s meant to be.

In this case the final step is to move – over the network – the files from the 2nd computer. Leaving it only with the VirtualBox and Google Drive folders in its home drive for when I do my study in there. At some point in the future I will remove the md0 RAID array and its disk from the system.

The relocation of data from both sources was completed during the day and during the next night all of the data from the old 1 TB array (oldhome) was again copied into the 2 TB disks, this time as a move rather than a copy, in order to clean up the 1 TB array, the new array having proved its operational capability. Actually this is what I should have done the first time instead of rsyncing from oldhome to home. The hidden folders (dot folders) on oldhome will get moved into a backup folder rather than pasted over into home as a lot of contents will have changed unlike the visible folders.