I wrote this a while back and meant to post:

 

1.   “Doh!”  I didn’t mean to delete those files!  Stupid mistakes still ranks #1 in terms of losing data.  If only we could protect ourselves from ourselves. 

 

2.  Trying to resolve a problem in the heat of moment without giving yourself time to weigh the options and discuss with forum members.  (Knowing what to do in the event of a drive failure is very important to a successful outcome.  Following your instincts when you are scared and stressed almost guarantees you are going to make a mistake that will cost you data.  A cool head can overcome almost any single failure. )

 

3.  Press the restore button thinking that it is going to help you restore data.  (Although this can make data loss more likely, even if you press the restore button at a bad time there is still a good chance that you can restore your data if you don't start the array. )

 

4.  Running with bad parity.  (Some users never perform a final parity check after the array is all set up to ensure the integrity of the array.  There was an unRAID bug several versions ago that could cause drives to not be cleared properly and resulted in corrupted parity.  Run periodic parity checks!  It is the only way to know parity is good.  It also has positive side benefits).

 

5.  Discovering you have bad sectors on other disks when trying to rebuild a failed or upsized disk.  (It is much more likely for a drive to develop a bad sector than for it to fail.  The drive itself, with some help from unRAID, can fix bad sectors if you run parity checks.  But if you don’t, and experience a true drive failure, trying to rebuild it and getting sector errors on another disk will make the recovered disk inaccurate in some very hard to figure out ways.)

 

6.  Have a drive that is known to be formatted show up as unformatted but press the format button anyway.  (unRAID can mistakenly report a drive as unformatted in certain situations.  If you know the drive IS formatted, don’t reformat it!  If you accidently do reformat, seek guidance in the forums.  Data recovery is still possible in many cases.)

 

7.  Install a new beta on your production array and not know how to handle unexpected errors.  (Be careful installing beta versions of unRAID on production arrays.  The chances of losing data as a result are low, but the beta may contain bugs that make it look as though there are serious issues with your array and push you to take corrective actions (like pressing restore or format) that you would not otherwise do.  If you wish to experiment with betas, know there is a risk.  Consider waiting several days for other users with test arrays to report positive experiences before taking the plunge.)

 

8.  Let the computer overheat - e.g., don’t install enough fans, leave in hot location, overnight guest throws a blanket on the server to kill the noise (this actually happened!), etc..  (Heat is a major issue for all electronics, and computer equipment is especially vulnerable to premature failure due to operating at high heat.  Pay particular attention to getting your drive temps below 45C if at all possible.  Otherwise you are asking for trouble!)

 

9.  Not realize that a drive has failed for a very long time and then have a second drive fail.  (Unraid will simulate a failed disk, and it may not be easy for you to determine if this has happened if you are not checking the management page periodically.  Worse, a drive can be spun down and fail and you might not know for a very long time (until another drive fails) that it has failed.  Another good reason to run monthly parity checks.  The chances of two drive actually failing at the same time without some underlying cause is very low, but the chances of two drives failing before you realize is substantially higher.)

 

10.  Accidently assign a data drive to the parity slot and start the array.  (This is a rather deadly mistake.  The only way to recover from such a blunder is to immediately stop the procedure and run the reiserfsck tool to rebuild the directory structure.  Chances for complete data recovery are low, but chances of significant data recovery are high.)

 

Outstanding!  Nominated for the Best of the Forums wiki page!

 

 

 

(would 'ensure the integrity of the array' be better than 'ensure that the array is integral'?)

Outstanding!  Nominated for the Best of the Forums wiki page!

I second the motion...

Added to newbie section.

This was great. Thanks for your time in getting it together.

VERY NICE POST. Mitigation comments inline:

 

1.  “Doh!”  I didn’t mean to delete those files!  Stupid mistakes still ranks #1 in terms of losing data.  If only we could protect ourselves from ourselves.

 

In theory a recycle bin could be added. Know of no device that does this though.

 

2.  Trying to resolve a problem in the heat of moment without giving yourself time to weigh the options and discuss with forum members.  (Knowing what to do in the event of a drive failure is very important to a successful outcome.  Following your instincts when you are scared and stressed almost guarantees you are going to make a mistake that will cost you data.  A cool head can overcome almost any single failure. )

 

Mitigating stupidity isnt possible

 

3.  Press the restore button thinking that it is going to help you restore data.  (Although this can make data loss more likely, even if you press the restore button at a bad time there is still a good chance that you can restore your data if you don't start the array. )

 

unRAID should mitigate this with sanity checks and better explanations.

 

4.  Running with bad parity.  (Some users never perform a final parity check after the array is all set up to ensure that the array is integral.  There was an unRAID bug several versions ago that could cause drives to not be cleared properly and resulted in corrupted parity.  Run periodic parity checks!  It is the only way to know parity is good.  It also has positive side benefits).

 

unRAID should mitigate this with scheduled and required parity checks.

 

5.  Discovering you have bad sectors on other disks when trying to rebuild a failed or upsized disk.  (It is much more likely for a drive to develop a bad sector than for it to fail.  The drive itself, with some help from unRAID, can fix bad sectors if you run parity checks.  But if you don’t, and experience a true drive failure, trying to rebuild it and getting sector errors on another disk will make the recovered disk inaccurate in some very hard to figure out ways.)

 

unRAID should mitigate this with scheduled and required sector checks.

 

6.  Have a drive that is known to be formatted show up as unformatted but press the format button anyway.  (unRAID can mistakenly report a drive as unformatted in certain situations.  If you know the drive IS formatted, don’t reformat it!  If you accidently do reformat, seek guidance in the forums.  Data recovery is still possible in many cases.)

 

unRAID should mitigate this by fixing the bug.

 

7.  Install a new beta on your production array and not know how to handle unexpected errors.  (Be careful installing beta versions of unRAID on production arrays.  The chances of losing data as a result are low, but the beta may contain bugs that make it look as though there are serious issues with your array and push you to take corrective actions (like pressing restore or format) that you would not otherwise do.  If you wish to experiment with betas, know there is a risk.  Consider waiting several days for other users with test arrays to report positive experiences before taking the plunge.)

 

User should mitigate this by common sense.

 

8.  Let the computer overheat - e.g., don’t install enough fans, leave in hot location, overnight guest throws a blanket on the server to kill the noise (this actually happened!), etc..  (Heat is a major issue for all electronics, and computer equipment is especially vulnerable to premature failure due to operating at high heat.  Pay particular attention to getting your drive temps below 45C if at all possible.  Otherwise you are asking for trouble!)

 

unRAID should mitigate this with temperature triggered events.

 

9.  Not realize that a drive has failed for a very long time and then have a second drive fail.  (Unraid will simulate a failed disk, and it may not be easy for you to determine if this has happened if you are not checking the management page periodically.  Worse, a drive can be spun down and fail and you might not know for a very long time (until another drive fails) that it has failed.  Another good reason to run monthly parity checks.  The chances of two drive actually failing at the same time without some underlying cause is very low, but the chances of two drives failing before you realize is substantially higher.)

 

unRAID should mitigate this by audible and email warnings.

 

10.  Accidently assign a data drive to the parity slot and start the array.  (This is a rather deadly mistake.  The only way to recover from such a blunder is to immediately stop the procedure and run the reiserfsck tool to rebuild the directory structure.  Chances for complete data recovery are low, but chances of significant data recovery are high.)

 

unRAID should mitigate this by checking and warning before allocation of the drive.

 

 

To my eye the majority of these extremmely valid Top 10 could be partially/completely mitigated/de-risked by unRAID. Perhaps after the current beta makes stable thres a case to be made for the next version to focus on these.?

(would 'ensure the integrity of the array' be better than 'ensure that the array is integral'?)

 

(Done)

 

NAS - I agree with your mitigation strategies. I think Tom should look to address common ways that uses have lost data in the past by implementing some protective code to prevent (or at least discourage) these common mistakes.

Should this be a sticky? It's a informative guide of what not to do.