Case Migration Questions

[mikedpitt420]

My unRAID server has outgrown the chassis it's currently occupying, and my PSU I don't think is capable of supporting a 13th drive. So I've purchased an Antec Twelve Hundred full tower with 12 front facing 5.25" drives. They are from top to bottom. I've also purchased 6 iceydock 3-in-2 SATA Backplane cages, so there will be a total of 18 front facing drives, and room for two internally mounted SSD's for a cache pool. In the process of moving all of my drives into this new case, it's going to require that I change around some of the SATA ports. What is the best process in this case? Do I just let unraid boot and think something is horribly wrong and then reassign the drives ? Would it be better to start in maintenance mode? Also, I have the Unassigned Devices Plugin managing a single out of the array drive for MythTV recordings solely, how do I reassign this without disturbing the VMs etc. Maybe I am making more of a deal out of this than I should, but I just want to make sure I don't do this incorrectly. The only real change is rearranging several of the SATA signal ports. Should I just stop the array and take a screenshot of the disk #s, then start in maintenance mode and reassign the drives?

Thanks very much in advance

[tdallen]

unRAID 5/6 identifies drives by serial number.  Unless the Icydock backplanes mangle the serial number (rare, but it happens) you should just be able to plug in the drives and USB and fire it up.  Taking a screenshot of the current setup is a good idea, as is backing up the USB with the array stopped.  Not sure about Unassigned Devices.

[mikedpitt420]

Thank you very much. I have posted in the Unassigned Devices plugin page to ask if this also will basically just auto detect via serial #. As it looks now from the MAIN page, all the serial #s are what I would expect to see from each manufacturer so I think they'll be fine. I failed to mention I am already using two of these same model iceydock 3-in-2 cages in my current setup, I just ordered 4 more as that's what this new chassis allows. I planned on doing a copy of /boot/config with the array stopped, and taking a screenshot of MAIN just in case I need it down the line. Is there any reason to copy the entire contents of the USB?

 

Thanks again very much for taking the time to respond.

 

[tdallen]

Is there any reason to copy the entire contents of the USB?

It probably isn't necessary, but it's fast and easy and gives me the ability to reconstruct a USB very quickly without redownloading the original distribution files and piecing things together.

 

Format USB, copy Last Known Good USB files over, run makebootable and good to go.  This only works if the array is stopped when you do the USB backup, though - otherwise super.dat will be empty.  It also only helps if you do before any change - if you make array changes between backups then you're invalidating the ability to recover to a backup.

[trurl]

Is there any reason to copy the entire contents of the USB?

It probably isn't necessary, but it's fast and easy and gives me the ability to reconstruct a USB very quickly without redownloading the original distribution files and piecing things together.

 

Format USB, copy Last Known Good USB files over, run makebootable and good to go.  This only works if the array is stopped when you do the USB backup, though - otherwise super.dat will be empty.  It also only helps if you do before any change - if you make array changes between backups then you're invalidating the ability to recover to a backup.

There was a bug that would sometimes make super.dat empty, but it is not typically empty when the array is running. The reason stopping is recommended before copying super.dat is because it contains the running/stopped status of the array. If you boot from a super.dat that says your array is running you will get the automatic correcting parity check due to unclean shutdown.

[tdallen]

Thanks for the clarification, trurl.

[mikedpitt420]

Just to document this for anyone in the future. Case migration and rearranging all of my SATA signal cables caused absolutely no issue whatsoever. Some drives were changed from being plugged into a controller card to the motherboard directly, and vive versa. The 4 port PCI SATA controller card I utilize, the Adaptec 1430SA, as well as the Iceydock 3-in-2 RAID backplane cages do report the correct drive serial #s to unRAID so they are identified.  After swapping chassis / case, PSU, and completely changing almost every SATA signal connection, unRAID booted as normally expected. All dockers and VMs worked as they did before, even with an out of the array drive being managed by the Unassigned Devices Plugin. The only noticeable change was the sdX designation, which of course can change from boot to boot adding or subtracting drives. I've had a good laugh poking fun at some of my older "hardware RAID die hards" and "FreeNAS die hards" (not to down talk either of them, I just like unRAID a lot more for several of my own personal reasons) asking if their Media NAS OS of choice could tolerate the same thing With dual parity coming in 6.2, and the addition of Turbo Write,  their arguments for any type of superiority are getting smaller and smaller

Thanks again for all the help