During the week, I have decided to replace the old HP Microservers I bought during 2020 with 5 HP EliteDesk 800 G2 minis mirroring the Lenovo M72e cluster I bought at in February of 2022 to build a home-lab, but admittedly still have not finished setting up. As the micro-server has 4 3.5” drive bays, in which my backup disks are currently housed, moving to a ultra small form factor with no drive bays presents a challenge. I found the Icy Bay IB-RD3620SU3 online which allows me to connect the drives via USB 3 or eSATA. It also does RAID internally, offloading it from the host system and reducing the amount of data that needs to be sent over the USB/eSATA connection (c.f. software-raid on the host).
I was a little disappointed in the condition that the box arrived in from SCAN. I bought the item from them as they were one of the cheapest and the cheapest of the places I’ve shopped with before but the box, which arrived wrapped in bubble wrap and a plastic shipping bag, has numerous dents and dings and, despite being sold as new, had clearly been previously opened (the “quality seal” was broken and the bags inside unsealed).
Products arriving in poor/damaged condition has become a recurrent theme for me with SCAN, I think I am going to have to stop buying from them - I previously had a brand-new hard-disk delivered, wrapped only in a anti-static bag, bubble wrap and shipping bag (no clam-shell, or cardboard, container to protect the disk) delivered with a dent on its corner. Unsurprisingly that disk was dead-on-arrival and had to be returned. That all said, this product did not show signs of use and appeared to have everything needed present so it was most likely a return from a previous customer under distance selling rules and fit to be resold as new. Despite the damage to the cardboard box, it has done its job and protected the contents.
The enclosure comes with some helpful labels for the disk and a slightly scary warning not to change the order of the disks - made more scary by the manual telling the user they might need to swap the disks in the event of a failure, depending on which disk fails (it seems that it always resyncs RAID from the disk in the
2 position to that in the
1 so if disk
2 fails, disk
1 must first be swapped into the disk
2 position and the replacement installed as disk
It also comes with two “handles”, screws and a mini screw-driver with which to attach them to the hard disks. I think this is just as much effort as a tray would have been, so they do cause me to question the “Trayless - easy assembly” claim on the box and marketing materials for the enclosure.
After powering off my existing system, I pulled one of the RAID disks out (this was to protect it, in case I made an error) and booted it back up, I fired up
gdisk and used it to wipe the partition table (
x for ‘extra functionality (experts only)’ then
z for ‘zap (destroy) GPT data structures and exit’) of the remaining RAID disk.
I then powered off the system, removed the drive I had just zapped and replaced the disk I took out earlier. The zapped drive, I installed in the Icy Box enclosure. I attached the drive label to the “handle”, to make it easy to deal with replacement drives in the future (label stays with the handle if swapped to another disk).
Once the disk was installed, I placed it alongside my incumbent server to set it up and powered it on for the first time.
I then changed the Icy Box enclosure to
Raid 1 mode. This is done by pushing and holding the
mode button until the light flashes, pressing
mode until the
Raid 1 setting is selected and then pressing and holding the “confirm” button (which is unlabelled, behind a small cover on the rear of the enclosure) until the system turns itself off.
Raid 1 mode, I attached it via USB 3 to the server and powered the server back on. The system will have the degraded raid volume marked
inactive, which also has the knock-on effect of not starting the VM that uses it (a good thing, in this case).
This is the point I discovered the enclosure does not appear to start if it is in
Raid 1 mode and only has one disk - or more precisely, it appears in the OS (with the capacity of the one installed drive) then disappears after about 15 seconds. I initially thought it was a problem with the device’s built-in power synchronisation (which is supposed to put it to sleep 15s after the host goes to sleep) but this behaviour continued even after turning off that feature.
To get around this, I decided to clone the existing RAID array (in its now degraded state), migrate the 2nd disk to the enclosure and restore. I began by creating a new temporary volume
backup-temp on my NAS (which barely had enough free space for this) and mounted it using NFS:
apt install nfs-client mount -t nfs isolinear:/data/backup-temp /mnt
(Note the path exported wasn’t obvious or visible in the ReadyNas UI - I had to run
showmount -e isolinear to find it.)
I then started the RAID array (note it will start it read-only, but that’s fine for cloning) and made an image of it with
mdadm --manage /dev/md125 --run apt install pv pv -tpreb /dev/md125 >/mnt/backup-disk.img
Once this was complete, I stopped the array again with
mdadm --manage /dev/md125 --stop, used
gdisk to wipe the other RAID disk and powered off the system. I removed the disk and installed it into the enclosure.
After powering on the enclosure, it exhibited the same “appear for a few seconds than turn the disks off and disappear from the OS” behaviour. I found a page that has some insight, which has disappeared from its original source but at the time or writing was still in Bing’s cache:
To check if there is any connection made, please do the following while both HDDs are installed:
- Set the Sync mode to Off
- Set the RAID Mode to Single
- After selecting the RAID mode, press and hold the confirmation button at the rear panel until the device shuts down.
- Switch the RD3620SU3 on and check if there is any change in the disk manager
Setting it back to single and confirming caused both disks to appear in the OS and remain there. Setting it back to
Raid 1 at this stage and it seemed to work (it did not attempt a rebuild, so I presume it does “RAID” via some sort of copy-on-write mechanism). I set the power synchronisation back to enabled, so it will automatically go into standby when the attached host is turned off.
Next, I partitioned the RAID (logical) disk that the enclosure presents (
lsblk is your friend here!) to the OS using
parted according to how I partitioned these disks originally:
$ sudo parted /dev/sdc GNU Parted 3.4 Using /dev/sdc Welcome to GNU Parted! Type 'help' to view a list of commands. (parted) mklabel gpt (parted) mkpart Partition name? ? backup-raid File system type? [ext2]? ext4 Start? 0% End? 4.5T (parted) print Model: H/W RAID 1 (scsi) Disk /dev/sdc: 8002GB Sector size (logical/physical): 512B/512B Partition Table: gpt Disk Flags: Number Start End Size File system Name Flags 1 33.6MB 4500GB 4500GB ext4 backup-raid (parted) quit Information: You may need to update /etc/fstab.
I re-mounted the NFS share (read-only to ensure I didn’t accidentally damage the image) and restored the image to the USB disk:
mount -t nfs -o ro isolinear:/data/backup-temp /mnt pv -tpreb /mnt/backup-disk.img > /dev/disk/by-partlabel/backup-raid
To pass the new disk through to the virtual machine, in place of the old one, I opened up
virsh and edited the domain’s XML by running
edit starfleet-archives. In the XML file, I replaced the existing:
Because the VM’s device did not change, just the source, no changes were needed within the VM.
When I was happy the restore had completed and was working, I remounted the NFS share read/write and removed the image before deleting the share entirely from the NAS:
mount -o remount,rw /mnt rm /mnt/backup-disk.img