Hey all,

 

I just ordered the parts to build a massive 24 drive (I know 24 drives are not supported at this time). I currently have a 15 drive (1x parity, 14x data) that is running unRAID 4.7 and a second 7 drive (1x parity, 6x data) that is running 5.0 beta2.

 

My question is once I have all new hardware and begin migrating the 15 drive (plan to use 4.7 as the OS for the new build) and have that setup and assign the drives and have it back online, how do I go about adding in the other 6 data drives to preserve their data?

 

Thank you,

 

If the new server runs 5.0 then all the drives should be recognized and all that will be needed is to rebuild parity. I'm not sure about 4.7.

What's the most stable 5.0 beta that is available? It's difficult to put total trust into 5.0, though I've had beta2 for a while and have had no issues to report. So let's say I go with 5.0 for the new server. What are the steps to make this happen smoothly?

 

1. Upgrade to 5.0 on the 15 drive server.

2. Build new server and migrate 15 drive server to this hardware

3. PARITY CHECK on new hardware

4. Install 6 data drives into new server... then what? How do I keep the data on them?

 

Thank you,

 

4.7 should work. UnRAID will recognize drives it has previously formatted as good.

What's the most stable 5.0 beta that is available? It's difficult to put total trust into 5.0, though I've had beta2 for a while and have had no issues to report. So let's say I go with 5.0 for the new server. What are the steps to make this happen smoothly?

 

1. Upgrade to 5.0 on the 15 drive server.

2. Build new server and migrate 15 drive server to this hardware

3. PARITY CHECK on new hardware

4. Install 6 data drives into new server... then what? How do I keep the data on them?

 

Thank you,

 

 

If you want to add an already RFS formatted disk that contains data to an existing array, you CANNOT just add the disk.  If will CLEAR the disk and the data will be lost!

 

Here is a set of instructions that should work:

 

1.  Back up each of your memory sticks

2.  On the machine with the memory stick you will use on the new server, stop the array and remove all of the disks from the array configuration

3.  Edit your GO file to comment out any addons.

4.  Move all of your disks to the new server.  Insert your memory stick.

5.  Make sure all drive are recognized by BIOS / controller cards - resolve issues, configure to boot off flash

6.  Boot unRAID.

7.  Go to a telnet prompt and run the "initconfig" command.  (If using 5.0b6, select the "Utils" tab and click on "New Config", and follow directions).

8.  Assign your disks to the desired slots

9.  MAKE SURE YOU GET YOUR PARITY DISK ASSIGNED TO THE PARITY SLOT.  If you are using your other parity disk in the array, assign it to a data slot.

10.  MAKE SURE YOU DO NOT HAVE A DATA DISK ASSIGNED TO THE PARITY SLOT (final warning)

11.  If you are using 5.06a, make sure that none of the drives say MBR - unknown

12.  Start the array, parity will build

13.  Run a parity check

 

Keep in mind 5+ is still Beta and most will out right tell you its not intended for a full production surver at this time.

What's the most stable 5.0 beta that is available? It's difficult to put total trust into 5.0, though I've had beta2 for a while and have had no issues to report. So let's say I go with 5.0 for the new server. What are the steps to make this happen smoothly?

 

1. Upgrade to 5.0 on the 15 drive server.

2. Build new server and migrate 15 drive server to this hardware

3. PARITY CHECK on new hardware

4. Install 6 data drives into new server... then what? How do I keep the data on them?

 

Thank you,

 

 

If you want to add an already RFS formatted disk that contains data to an existing array, you CANNOT just add the disk.  If will CLEAR the disk and the data will be lost!

 

Here is a set of instructions that should work:

 

1.  Back up each of your memory sticks

2.  On the machine with the memory stick you will use on the new server, stop the array and remove all of the disks from the array configuration

3.  Edit your GO file to comment out any addons.

4.  Move all of your disks to the new server.  Insert your memory stick.

5.  Make sure all drive are recognized by BIOS / controller cards - resolve issues, configure to boot off flash

6.  Boot unRAID.

7.  Go to a telnet prompt and run the "initconfig" command.  (If using 5.0b6, select the "Utils" tab and click on "New Config", and follow directions).

8.  Assign your disks to the desired slots

9.  MAKE SURE YOU GET YOUR PARITY DISK ASSIGNED TO THE PARITY SLOT.  If you are using your other parity disk in the array, assign it to a data slot.

10.  MAKE SURE YOU DO NOT HAVE A DATA DISK ASSIGNED TO THE PARITY SLOT (final warning)

11.  If you are using 5.06a, make sure that none of the drives say MBR - unknown

12.  Start the array, parity will build

13.  Run a parity check

 

 

So when I begin moving all the drives from both servers into the new one, the only drive that I have to be sure to assign properly is the Parity drive, is that correct? That will be the parity drive from the '15 drive arrary' as it's 2TB. I do not plan to add the '7 drive array' parity until I get everything up and running.

 

So the initconfig command will allow me to bring in all these data drives and then reconstruct new parity, correct?

Correct.  I like your idea to keep the 7 drive server's parity drive untouched until you are sure everything is going well.  I would also make very careful notes about which drives are part of which server right now (one list of serial numbers for the 15 drive server including disk slots, and another list for the 7 drive server....or just screenshots of both devices pages).  That way if sh*t really hits the fan you could revert to your old configuration of two separate servers and still have parity protection on at least one of them (the 7 drive one).

 

While you are moving the drives you can also take that opportunity to appease any OCD tendencies, such as installing all your largest disks into the disk1, disk2, etc slots and leaving your smallest disks towards the end.  I would also suggest making sure that each of your disk assignments in unRAID corresponds in a logical manner to the drive's physical location in your server.  Assuming you are using a Norco 4224, I would suggest:

 

Parity  | Disk1  | Disk2  | Disk3/cache  < Top row of Norco 4224

Disk4  | Disk5  | Disk6  | Disk7

Disk8  | Disk9  | Disk10 | Disk11

Disk12 | Disk13 | Disk14 | Disk15

Disk16 | Disk17 | Disk18 | Disk19

Disk20 | Disk21 | empty  | empty          < Bottom row of Norco 4224

 

None of this actually matters as far as unRAID is concerned, but it can be very helpful to you months from now when you find out that disk6 has died, and you need to know which physical drive that refers to...

 

BTW, I like putting the parity in the top left slot and the cache in the top right so that both are directly connected to the motherboard.

 

 

So when I begin moving all the drives from both servers into the new one, the only drive that I have to be sure to assign properly is the Parity drive, is that correct? That will be the parity drive from the '15 drive arrary' as it's 2TB. I do not plan to add the '7 drive array' parity until I get everything up and running.

 

So the initconfig command will allow me to bring in all these data drives and then reconstruct new parity, correct?

 

teamhood -

 

Yes. The only real reasons to try to keep you data disks assigned to the same disk slots is to not have to update your user share settings (which you'll likely have to tweak anyway), and to keep things familiar for yourself.  Neither is critical, but still might be a reason to maintain the order.

 

BTW, the parity drive from the second array can be added to the array if you plan to add it soon anyway.  It will save time.  So long as you don't format it, none of its contents are changed.  So the new parity would be built to include this other parity, and to use it all you'd have to do is format it.  No preclearing necessary.  I use this trick every time I update parity.  For it to be useful you can't write to the array until after parity is built and verified.

 

Raj -

 

You're a sick man.

First off, run a parity check on both arrays before disassembling them.

 

You have 2 arrays that total 20 data disks. You have to build parity once to add all the disks. So, if you feel lucky then stab all 20 data disks into the new box and assign them to disk slots and then start the array. You could also re-arrange the drives however you want at this time. Just make sure a data disk is not set as parity.

 

Otherwise, stab in the disks and the flash from either array and get the new box working. There should be no need to use initconfig or build parity since it's already a valid array. You just assign the drives to the same disk slots and they'll all have green balls and the array can start. If you want to test the server, you can move these disks around to different case slots to ensure they all work. You'll just have to re-do the disk assigments when you move them.

 

Then, stick in the data disks from the second array, assign them to the array, run initconfig and start the array which kicks off a parity build.

 

The only real difference between 4.7 and 5.0b6 as far as the base array working is in the way the 2 versions handle the disk assignments. 4.7 will likely have to be re-told which disk goes where any time they are moved in the hardware. 5.0b6 will likely recognize the drives and should keep track of them as they move. By this, I mean say you put the small array into the new case and then decide to test the hardware so you try 4 drives in each row of the case. In 4.7 you will have to use the device page to assign them back to their disk slot each time. In 5.0b6 it will likely recognize them automatically. So, in the end there is no major technical reason 4.7 or 5.0b6 is any better as you do this array combining. 4.7 might just take a little more work as you assign disks.

 

FYI, you can assign just the data disks and start the array once. If a disk appears as unformatted then it's possible you have the parity mixed in there. It's an easy test to make sure you didn't mix something up.

 

Peter