Replacing Parity Drive - precautions to take?

Hi

 

I searched forums but didn't quite find a satisfactory answer;

 

I have an unRAID array comprising 8x 1TB drives (parity included) I want to start expanding the array and have a 4TB Seagate NAS drive to pop in as parity.

 

While not necessary for Parity, I will be pre-clearing this disk to give it a workout beforehand. However, I'm worried about possible problems during the replacement process.

 

I plan to stop the array, set unRAID not to auto start, shutdown server, add in 4TB drive, boot unRAID, assign 4TB to parity slot and let the rebuilt happen.

 

However, as this process will be somewhat stressful, reading all data on all drives and writing extensively to the new parity drive, my concern is what if something goes wrong in this process (either new parity or existing data drive red balls).

 

Would I be able to simply reassign my old parity drive at this point and resolve?

 

I just want to be sure I have a fallback strategy (apart from having backed up important data anyway ;-) )

 

Thanks

 

Peter

 

 

 

On 5/7/2014 at 7:15 AM, meep said:

Hi

 

I searched forums but didn't quite find a satisfactory answer;

 

I have an unRAID array comprising 8x 1TB drives (parity included) I want to start expanding the array and have a 4TB Seagate NAS drive to pop in as parity.

 

While not necessary for Parity, I will be pre-clearing this disk to give it a workout beforehand. However, I'm worried about possible problems during the replacement process.

 

I plan to stop the array, set unRAID not to auto start, shutdown server, add in 4TB drive, boot unRAID, assign 4TB to parity slot and let the rebuilt happen.

 

However, as this process will be somewhat stressful, reading all data on all drives and writing extensively to the new parity drive, my concern is what if something goes wrong in this process (either new parity or existing data drive red balls).

 

Would I be able to simply reassign my old parity drive at this point and resolve?

 

I just want to be sure I have a fallback strategy (apart from having backed up important data anyway )

 

Thanks

 

Peter

 

I like the way you think! Great question!

 

0. If the new parity disk is brand new or has never been tested, do a preclear on it.

 

1. Take smart reports of all drives. Look for reallocated sectors and pending sectors or anything that says failing now. If you haven't already, you might consider installing unmenu and bringing up the myMain smart view (see my sig). It will run the smart reports for you and highlight anything it detects as concerning. [Update - Use the unRAID GUI to check the smart reports. Ask on the forums if questions about smart issues.

 

2. Do a parity check on the existing array. A parity check creates about the same level of stress as the parity build.

 

3. Do the smart reports again and compare if anything important got dramatically worse. For example, if your first check had 4 reallocated sectors, and after that disk had 316 reallocated sectors, I'd be worried about that disk!

 

4. If all is good, stop the array and make a backup of the config directory of your USB stick.

 

5. Note the placement of all the disks and what slots they are assigned to.

 

6. Do a new configuration, and assign the new parity, all data disks to their respective slots. And assign the current parity to the next data slot (if you intend to use it as a data drive). (Update - select the option to allow you to do maintain the drive assignments. Replace the parity mapping with the new parity drive, and add the old parity as a data disk. You can also add additional disks if so desired.)

 

7. Start the array. Let parity build. Do not format the unformatted old parity disk. Do not write to the array. (Update - may have to stop Dockers and VMs that might do writes to the array. If you do writes, your lose the ability to recover if a drive fails during the rebuild. That is a low risk so it is up to you if you want to avoid the writes.)

 

8. Should something go wrong like a red ball, save the syslog (Update - generate the Diagnostics file), stop the array, shutdown the server, fix loose connection (often the cause of the red ball), restore the USB (config directory) backup, and reboot. The old parity will be back in its prior place and the red ball will likely be gone. Run a parity check. You may get a few sync errors early. It's ok. Go back to step 3. Or ask for advice on the forum if drive red balls again.

 

9. If all goes well with the build do a parity check.

 

10. If the parity check goes well, then format the old parity, delete the USB (config directory) backup (it is dangerous now and you never want to use it again), and write to the array all you want!

Edited September 3, 2017 by bjp999
Updates for new unRAID versions

Thank you so much for taking the time to put that together.

 

Very much appreciated. I feel safer now!

 

Peter

If it makes you feel better, I was pretty nervous when I replaced my parity drive too but it went flawlessly.

 

Quick question though...what unraid version are you running? 

[me=DaleWilliams]bookmarks this and adds it to his folder of 'unRAID Best Practices'. [/me]

Excellent step-by-step directions!

If it makes you feel better, I was pretty nervous when I replaced my parity drive too but it went flawlessly.

 

Quick question though...what unraid version are you running?

 

v6b5a on the server I'll be doing this on. (have 5.0.5 running on my backup server)

 

Why?

 

(btw, just noticed your name - I've just started book 6 of Wheel of Time).

Nice!  Enjoy the books (at book 6 its still excellent though it does have a drop off at times).

 

Just making sure that you are on at least version 5 or better as 4.x didnt support drives larger than 3 TB if i remember correctly.

I got as far as step 3 and have concerns over SMART status. Discussion commenced here;

 

http://lime-technology.com/forum/index.php?topic=33306.0

Great instructions, thanks for posting!

 

I would submit these changes:

 

6. Assign the new drive as parity, without starting over with a new configuration. (especially helpful if you have a lot of drives.)

 

10. Use JoeL's preclear_disk.sh script to clear the old data drive. (You should be able to safely skip the pre- and post-read steps, since you've been using the drive, and you ran your SMART reports previously, didn't you)

 

11. Stop the array, assign the old parity disk (now cleared) to your next array, restart the array, format that drive & enjoy.

 

 

Does anyone see any issues with these changes?

Great instructions, thanks for posting!

 

I would submit these changes:

 

6. Assign the new drive as parity, without starting over with a new configuration. (especially helpful if you have a lot of drives.)

 

10. Use JoeL's preclear_disk.sh script to clear the old data drive. (You should be able to safely skip the pre- and post-read steps, since you've been using the drive, and you ran your SMART reports previously, didn't you)

 

11. Stop the array, assign the old parity disk (now cleared) to your next array, restart the array, format that drive & enjoy.

 

 

Does anyone see any issues with these changes?

 

This is not necessary and eliminates some of the value and safety of the procedure I documented. By putting the old parity in the array before the parity build but not formatting it, you eliminate the need to preclear it but still have your recovery options.

 

Please re-read the procedure and ask questions if there is still confusion.

Ah, I see your angle. By calculation the new parity disk with whatever "junk" was on the old parity disk, it's accurate, and will be kept up to date as new data is written once that disk is put on use for data purposes. Makes sense.

I saw the part about adding the old parity disk into the array as data before confirming the new disk was good for parity, and got concerned about that.

Oh well, I guess I'll have to do an additional pre clear run on my old parity disk. This way works, but takes a bit more time.

 

Thanks again for your great write up. I have it linked in my unRaid notes.

 

FreeMan

I believe that if you do not make any changes to the data or old parity drives and something goes wrong with the parity sync you can pop the old parity back in and rebuild what ever drive has failed.

 

 

Sent from my iPad using Tapatalk

Ah, I see your angle. By calculation the new parity disk with whatever "junk" was on the old parity disk, it's accurate, and will be kept up to date as new data is written once that disk is put on use for data purposes. Makes sense.

I saw the part about adding the old parity disk into the array as data before confirming the new disk was good for parity, and got concerned about that.

Oh well, I guess I'll have to do an additional pre clear run on my old parity disk. This way works, but takes a bit more time.

 

Thanks again for your great write up. I have it linked in my unRaid notes.

 

FreeMan

 

Great!

Hello, I have a quick question.

My current parity is sdb.

The new parity (that I plan to connect) is sda.

Does it matter in which sata slot I connect the parity disk?

Or should I connect the new parity at exactly the same slot as the old one?

 

What I want to do is make sda the new parity disk and then make sdb data disk...

 

Hello, I have a quick question.

My current parity is sdb.

The new parity (that I plan to connect) is sda.

Does it matter in which sata slot I connect the parity disk?

Or should I connect the new parity at exactly the same slot as the old one?

 

What I want to do is make sda the new parity disk and then make sdb data disk...

The disk names (sda, sdb. etc) are assigned in the order in which the disks initialize upon bootup.  They can change from one boot to the next.  DO NOT BE FOOLED INTO THINKING /dev/sdb is always the parity disk...

 

On newer unRAID versions unRAID uses the model/serial number of the disk when making assignments.  (that never changes for any given disk)

Older versions of unRAID used the disk-controller-PCI port ID to track a given disk.  (Until it was learned that too chane change when identical multiple disk controller boards can also initialize in different order upon boot-up)

 

So... when deciding on replacing disks, and re-assigning disks, use the model/serial number of the disks to make your assignments, not the disk device names.

 

Joe L.

Joe thanks for your reply.

What about the physical connections (sata ports) on the motherboard?

Does it matter which is which, when replacing parity or adding data disks?

I guess not since the assignment is being done through the web management...

Of course I will double check the disk model/serial.

Joe thanks for your reply.

What about the physical connections (sata ports) on the motherboard?

Does it matter which is which, when replacing parity or adding data disks?

I guess not since the assignment is being done through the web management...

Of course I will double check the disk model/serial.

This does not matter as long as you are on unRAID v5 or v6.  It DID matter on v4 and earlier.

Just want to make sure, when I select the NEW parity drive it says "Wrong" and near the bottom it says Stopped "Upgrading Parity", that is correct right?  All I need to do now is hit start and it should start rebuilding that parity correct?

 

thanks

Yes and yes.