Can any of you UnRAID vets explain how, if at all, UnRAID's single and double parity differs from a traditional RAID5/6 configuration?  I ask because the math seems pretty clear with regard to the risks of additional disk failure during rebuilds with large (> 2TB) drives in traditional RAID arrays.  I'm wondering if UnRAID does anything different being that the data is not striped across multiple disks that would reduce the risks and rebuild times.

Can any of you UnRAID vets explain how, if at all, UnRAID's single and double parity differs from a traditional RAID5/6 configuration?  I ask because the math seems pretty clear with regard to the risks of additional disk failure during rebuilds with large (> 2TB) drives in traditional RAID arrays.  I'm wondering if UnRAID does anything different being that the data is not striped across multiple disks that would reduce the risks and rebuild times.

Big differences between unRAID and traditional raid systems are:

• Parity is always on a specific disk (or a specific second disk in the case of dual parity).  This means when updating a data disk only that disk and the associated parity disk(s) need to be spun up - all the other data disks can remain spun down.
  
• Each data disk is a discrete file system and all the data on it is accessible if that disk is moved to another system (as long as that system understands the file system type).  This means that one is far less likely to lose data in serious failure scenarios.
  
• When reading data only the disk(s) containing the data need to be spun up.
  

The downside of the chosen approach is that is not optimised for performance when writing. 

 

Rebuild time is unaffected as any rebuild always involves writing every sector on the disk being rebuilt.

Thanks for the detailed reply.

 

Given that rebuilds are no different than a traditional RAID5/6 array, I'm a little surprised to see so many UnRAID users using 4TB, 6TB, and even 8TB drives.  Is it just the simple fact that the risk of losing additional disks during a rebuild is not so bad considering only the data on those lost disks would actually be lost?

 

Also, how exactly does it work if you lose a disk beyond parity during a rebuild?  So say you have a failed disk, replace it, start a rebuild and then lose second disk during the rebuild.  The data is now lost off both failed disks and must be restored from backup, correct?

You seem to be associating the risk of additional drive failure with the rebuilding of a previously failed disk.  I don't see a direct correlation - extended periods of heavy activity are probably all the same - rebuild, parity sync, parity check, extended reads and writes, etc.  It sounds like you'd advocate limiting the duration of any extended period of heavy activity in order to minimize the risk of failure - e.g. use smaller disks.

 

I don't have the stats on whether failure occurs more often under heavy activity though it probably makes sense.  I'll add another perspective, though - I don't think you're taking into account that more disks = more chances for failure.  More disks, more drive bays, more cables, larger power draw, more heat, etc.  There are some clear advantages of managing a smaller number of large disks.  There are also some disadvantages, such as longer format and rebuild times.  I don't agree with the idea that large disks are inherently bad - it's all a matter of tradeoffs.

You seem to be associating the risk of additional drive failure with the rebuilding of a previously failed disk.  I don't see a direct correlation - extended periods of heavy activity are probably all the same - rebuild, parity sync, parity check, extended reads and writes, etc.  It sounds like you'd advocate limiting the duration of any extended period of heavy activity in order to minimize the risk of failure - e.g. use smaller disks.

 

I don't have the stats on whether failure occurs more often under heavy activity though it probably makes sense.  I'll add another perspective, though - I don't think you're taking into account that more disks = more chances for failure.  More disks, more drive bays, more cables, larger power draw, more heat, etc.  There are some clear advantages of managing a smaller number of large disks.  There are also some disadvantages, such as longer format and rebuild times.  I don't agree with the idea that large disks are inherently bad - it's all a matter of tradeoffs.

 

I'm not associating the risks of a failed disk only with data rebuilds, but that is the time I'm most interested in considering it's when I've ALREADY got a failed disk and a second or third failed disk means actual data loss.  Where as losing a disk during a parity check, extended read/write, etc. doesn't mean data lose unless of course a second/third disk fails during the corresponding data rebuild.

Well you should definitely look at unRAID's dual parity feature, currently in public beta.  It can tolerate the loss of a second drive.  If you are concerned about multiple drive failure during rebuild then yes - unRAID users gain confidence from the fact that you don't lose any data on unaffected drives, whereas with traditional striped RAID you are utterly screwed if you loose more drives than the protected pool can tolerate. 

 

I still think using small disks to limit rebuild times, under any Raid package, is a rather narrow/limiting approach.  You'd be better served thinking about your backup strategy because no RAID setup is a replacement for an effective backup strategy.

In all RAID setups there is always the risk of losing yet one more disk while rebuilding; the issue being that "one more disk" pushes you beyond the limit of protection afforded by your array choice.

 

The nice thing about unRaid is that losing one more disk means you only lose one more disk. In a striped array losing one more disk could mean losing the entire array.

 

There is of course another way to increase your total protection and that is to only grow your array to the size / # of disks you are comfortable with before building another server. Hardware costs are not trivial, but given the honestly low system requirements for just a straight storage array system it isn't prohibitive.

 

Even better then if you are going to do that is to just use that second server as a no kidding backup server to the first since backups are 100% still required for important data regardless of RAID choice.

 

Which then of course brings up question about where/how a backup should exist like isolated power sources, isolation for ransom-ware resistance (if you aren't thinking about it, you should be) different physical location for natural disaster protection (house, city, geographic land mass) depending on how important your data is to you etc.

 

the point being, you need to really really REALLY sit down and consider what your likely failure scenarios are, what steps you're taking to prevent them, if those steps are truly going to be as effective as you think they are, and of course the cost/benefit analysis.

Thanks for the detailed reply.

 

Given that rebuilds are no different than a traditional RAID5/6 array, I'm a little surprised to see so many UnRAID users using 4TB, 6TB, and even 8TB drives.  Is it just the simple fact that the risk of losing additional disks during a rebuild is not so bad considering only the data on those lost disks would actually be lost?

 

Also, how exactly does it work if you lose a disk beyond parity during a rebuild?  So say you have a failed disk, replace it, start a rebuild and then lose second disk during the rebuild.  The data is now lost off both failed disks and must be restored from backup, correct?

 

I believe you are missing one major point:  The primary Parity Drive or two MUST be as large or larger than any other drive in UnRaid.  Thus your scenario of having lost data beyond Parity is a non-issue.  Yes it is possible to lose a large drive and I suppose suffer a loss of Parity while rebuilding the array (lost data) but each of the drives data is independent (i.e. not striped) thus your only loss would be the potentially the bad drive.  All other drives would be readable by a proper XFS/RFS system (so the data would be intact).  Creating a new parity would be equally simple assuming the remaining data was intact, just create a new "unraid" with parity and check.

 

Dave

Also, how exactly does it work if you lose a disk beyond parity during a rebuild?  So say you have a failed disk, replace it, start a rebuild and then lose second disk during the rebuild.  The data is now lost off both failed disks and must be restored from backup, correct?

I'll let the 6.2 beta participants offer their feedback, which should be more precise than mine.  That said, it may help to understand how unRAID handles a disk failure.  unRAID implements real time parity.  When a drive fails, unRAID begins emulating it - in real time.  It will look and feel to the user like the drive is still there - no data is lost or unavailable.  It is advisable to immediately put a new disk into the system so that unRAID can start rebuilding a physical disk.  Under unRAID 6.2, if a second drive fails during a rebuild - unRAID should start emulating it, too - just like the first failed disk.  If a third drive fails then unRAID will no longer have the information to emulate or rebuild the failed drives and you'd be back to just the data on your drives.

I appreciate everyone who has chimed in on this thread. 

 

I don't have a dog in the fight as I currently have my media server setup with SnapRAID and have a second backup server that mirrors that server.  I'm quite happy with it.  So I'm not looking to make an argument one way or the other I'm just looking to better understand the pros and cons of UnRAID as I've never used it.  I believe some very good points were made in this thread and I think I have a much better understanding as to how UnRAID's parity works now.

One point that has not been emphasised much is that true disk failures (I.e. Where a disk can no longer even be physically accessed) are comparitevly rare.      Much more common is an intermittent failure dues to issues such as cabling, power etc.  In such cases even though a disk might have been disabled by unRAID due to the write failure and thus flagged for rebuild, in practise since each disk is its own discrete file system it can be handled outside the array and the data from before the write failure is still intact.