Run parity check before replacing a failing harddrive?(SOLVED)

[LeSamourai72]

Thanks in advance for the help.

 

I've been running an unraid server for just about 10 years. Not currently familiar with best practices and my searches are coming up empty.

 

I've replaced drives in the past, but usually just to increase the total array size.

 

Recently a drive has started reporting read errors (4800-ish errors, Reallocated Sector Count Raw Value=8) and it passes short & extended SMART self tests.

 

If I was just replacing a healthy drive for a larger drive, I would usually 1) run a Parity check beforehand, 2) replace the drive with larger drive, 3) let the rebuild process run it's course, then 4) run another Parity Check.

 

At this moment, I can't remember if it's OK to run a Parity Check with a currently failing drive.

 

I should also add that I've been lax with keeping up a regular schedule of Parity Checks and haven't run one in over a year (yeah, not smart I know).

 

Running 6.5.1 and I've attached diagnostics as it seems like the thing to do.

 

Thanks again for the help and glad to see UNRAID's success flourishing over the years.

 

-L

tower-diagnostics-20210104-2243.zip

[Vr2Io]

1 hour ago, LeSamourai72 said:

if it's OK to run a Parity Check with a currently failing drive.

It should no meaning to do parity check under disk disable or emulate, after rebuild also no meaning too.

[itimpi]

3 hours ago, LeSamourai72 said:

At this moment, I can't remember if it's OK to run a Parity Check with a currently failing drive.

You do not want to run a correcting check with a failing drive as if you are getting read errors you are likely to end up corrupting parity for the sectors corresponding to the read errors.   This is one reason why it is recommended that any periodic scheduled checks should be set to be non-correcting.

 

I would suggest that your best approach is probably to simply rebuild onto a new drive but keep the old drive intact in case you need to get any data off it.   

 

If before you rebuild you start the array with the suspect drive unassigned then Unraid will emulate the missing drive.  Whatever shows up as the contents of the emulated drive is what you will end up with after a rebuild as all the rebuild process does is make a physical drive match the emulated one.

 

Once you have things sorted you should certainly run non-correcting periodic parity checks to monitor array health.   You can use the Parity Check Tuning plugin to minimise the impact by making sure the check is only running during idle periods (although you would have to upgrade to at least Unraid 6.7.0 to be able to run the plugin).

[LeSamourai72]

Thank you for the helpful suggestions.

 

I was eventually going to install a larger hard drive in place of that particular (currently failing) drive anyways, so now is the time and I have a clear plan of action. 

 

For what it is worth, I was always reticent to run correcting parity checks and now I remember why.

 

I've been meaning to upgrade to a more recent UNRAID version, and that plugin sounds like as good a reason as any to do it sooner than later.

 

The 'problem' with running such a vanilla UNRAID server like mine (mainly just for media storage, nothing fancy), is it just works; most of my efforts are upgrading drives and replacing fans, as well as a power supply or two (nearby lightning strike, which also took out the mother board; not an UNRAID issue, just force majeure).

 

I think we can consider this issue solved unless anyone else has something to add.

 

Cheers,

 

-L

 

[trurl]

Lots of new features on V6 that make it a much better NAS than V5, including Notifications that can alert you by email or other agent as soon as a problem is detected such as SMART issues.

[FreeMan]

I will say this: It seemed like a huge jump to go from unRAID v5.x to v6.x (and I was certainly very late to that party!) but it is really, really worth it!.

 

If nothing else, with v6 you get notifications in the WebGUI (if you don't turn on email or push notifications) of OS updates, and it's a click and about 3-4 minutes for a near flawless update to the latest release version. If only these guys worked for Microsoft, Windows updates might not be such a pain!