Migrating existing drives from motherboard SATA to Dell perc H310 (IT-mode)

[particularpanda]

TL;DR: How can I safely migrate existing Unraid array data drives to a Dell PERC H310 in IT mode without risking data loss? The drives are currently connected through motherboard SATA ports and passed as Proxmox QEMU/SCSI to an Unraid virtual machine.

 

As a learning experience, I recently build my first server, which runs on Proxmox. The data hard drives are connected via the 4 onboard SATA ports. With the intention of installing additional drives and utilizing the benefits of SMART monitoring in Unraid, I acquired a Dell PERC H310 from eBay and successfully flashed it to IT mode. My goal now is to transfer the existing data drives from the motherboard SATA ports to the H310 PCIe card, ensuring that I do not compromise the integrity of my Unraid array or lose any data.

 

As it stands, the data drives are presented to Unraid as SCSI devices through Proxmox, appearing as 0QEMU_QEMU_HARDDISK_drive-scsiX - 10 TB (sdX). In a preliminary test, I moved one of the drives to the H310. Unraid then indicated that scsi6 was missing. Upon selecting the drive connected to the H310 from the dropdown menu, I was met with the warning: "All existing data on the drive will be OVERWRITTEN...". It is possibly straight forward, but how do I migrate my existing array without risking data loss? I already cross referenced hardware ids in both proxmox and unraid.

[JorgeB]

1 hour ago, particularpanda said:

as Proxmox QEMU/SCSI

SATA to H310 IT mode would be plug an play, not sure about QEMU/SCSI, depends if the complete device is passed through transparently, if yes it should work, if not it won't.

[particularpanda]

In Unraid, the drives only appear as:

 

0QEMU_QEMU_HARDDISK_drive-scsi1 - 10 TB (sda)

0QEMU_QEMU_HARDDISK_drive-scsi2 - 10 TB (sdb)

0QEMU_QEMU_HARDDISK_drive-scsi3 - 10 TB (sdc)

 

so non-transparent.
 

Moving one of the drives to the H310, that is parsed to Unraid, unmasks the drive and it appears with correct hardware id, “WD…”.
 

Can I safely recreate the array from the same disks, but with these new hardware ids? And if so, how do I proceed?

[JorgeB]

1 hour ago, particularpanda said:

Moving one of the drives to the H310, that is parsed to Unraid, unmasks the drive and it appears with correct hardware id, “WD…”

That's expected, if the ID is the only thing that changes you can do a new config, but it may be difficult to find out which drive is which.

[particularpanda]

Thank you! I am a little cautious about proceeding, simply because I am not that familiar with Unraid nor the "New Config" tool, and I cannot lose my data.

 

From my understanding of the documentation (https://docs.unraid.net/unraid-os/manual/tools/), I would assume that I could make a small test just to familiarize myself with the process. As such, I would:

1. Move one of the four existing array disk (0QEMU_QEMU_HARDDISK_drive-scsi4 - 10 TB (sdd), that is not the parity disk and EMPTY according to the interface) from its current MB SATA-port to the Perc H310.
2. After boot, create a new config with "keep all assignments" although one drive would be missing, Click "Apply".
3. Return to main-tab, where I then assign the missing or danling disk ( previously:  OQEMU_... - 10 TB (sdd),  and now:  WDC_WD100EFX..._<disk_serial> ) to its original position in the array.
    
4. Then, I am unsure about whether, "Parity is valid", should be checked or not?
   My logic is: It is the same drive - that has been moved - and consequently changed name. I would assume that formating, partioning, etc is unchaged from my otherwise sparse knowledge of linux and how unraid operates.
    
5. Start the array. Check that all looks good.
6. Proceed with the next drive, that would have important files.
7. Repeat with third drive - also having important files.
8. And lastly, the parity drive.
9. FINISHED.

It was not clear to me from the documentation, how to safely perform this kind of migration. Quite possible there is a much smarter way? 

 

Thanks, appreciate your help.

 

[JonathanM]

If the data layout is unchanged, then parity would be valid.

 

However... I'm not sure how to figure that out without just doing what you said. I don't see any issue with your plan, I would definitely check the box stating parity is valid, that way there will be a parity check triggered instead of a parity build. If there are zero errors and the disk mounts, then you will be good to go. If there are immediately a wallop of parity errors and the disk doesn't mount, cancel the check, stop the array, unassign the disk, and start the array and see if the emulated disk mounts. If it does, then a rebuild on all the drives, one at a time, would fix it.