Preventative measures

[squashem]

I have been using Unraid for the past couple of weeks and I really like it. I've been browsing the different threads here on the community forums and learning about Unraid. I can see myself using Unraid for a very long time because conceptually and useability wise, it seems much simpler. Simple is good : ).

 

I haven't yet had any drive failures, nor have I had any drive errors show up on my webgui. But I would still like to know what kind of initial signs or signals should I look for that will tell me that my drives are failing? I do not want to wait till the end to fix the issue. I would rather take preventive action than corrective action.

 

So can you guys please suggest any tips and tricks I can use to keep my array in tip top condition, or any checks I can make from time to time or any maintenance tools I can run regularly, or any other tuning I can do to keep my array performing optimally.

 

For instance .. for now, the TRIM plugin runs once a week. Parity Check runs once a month. Mover runs once a week. Anything else I can do?

 

I'm aware that inspite of all the preventive measures I may take, the array can still fail. But what kind of signs should I look for to tell me that the "end of days" for my array are near?

 

Thanks
 

[danioj]

Back in the day it was much harder than it is now with unRAID 6+ access to SMART data in the GUI and its ability to highlight variables which have reduced or are failing.

 

Also, I'd like to make 2 points first (and I know this is not quite in response to what you asked) which are important:

 

First and foremost keep a backup. Parity is NOT backup.

Second of all, the increase of a 2nd Parity drive in your system gives you additional protection in the event of drive failure(s)*

 

* You might question the need for this if availability is not an issue (e.g. you have a mirrored Backup server which you can switch to).

 

Note: TRIM is a tool for SSD's only and not for array (mechanical) devices. Unless of course your array is made up of SDD's but AFAIK unRAID does not officially support this (although I know some users have played with it) nor does (I believe) the TRIM plugin (which I assume you are using).

 

As for preventative actions. I do the following and I believe it is sufficient and is consistent with practice the majority of unRAID users follow:

 

- Parity check once per month.

- Turn on notifications to allow you to be notified (via whatever method you prefer) when SMART variables get iffy.

- Manually check SMART variables once per month.

 

There is also the extended keep disks spinning vs spin down argument (which I will not re-ignite here) which (depending which side of the fence you sit on) could extend / reduce the life of your disks.

 

https://forums.lime-technology.com/topic/10200-to-spin-down-or-not-to-spin-down-that-is-the-question/

 

In summary, if you keep doing what you are doing PLUS setup your notifications and add a bit of proactive checking I think you will be as proactive as the majority of unRAID users I know.

 

EDIT: I'd like to add a comment on your mover execution frequency. Unless you're running a protected BTRFS array as your cache device, then I don't think that running your mover once per week is sufficient (Even if you are using a protected BTRFS array as cache - I feel that this is still not good enough as BTRFS is IMHO widely not considered to be stable enough yet and I don't believe there are unRAID GUI tools to support restoring cache data). This is because your files are not protected by parity if they are not on the array and any cache device failure could result in data loss. My advice would be to run this at least (assuming daily use of the array of course) once per day. If the data is REALLY sensitive (and you wish to keep using Cache) then I'd even suggest running the mover more frequently (e.g. every 6 hours). Of course if your disks never spin down then you could even run it every hour as there would be no spin up penalty.

Edited March 8, 2017 by danioj

[squashem]

Thanks for the detailed response. I've set up my notifications and the mover is now set to run more frequently.

 

[trurl]

Just want to add. Connection issues are very much more common than bad drives, and they can cause a drive to be disabled (kicked out) and have to be rebuilt. Don't hesitate to ask on the forum if you are ever unsure how to proceed.