May 14, 201412 yr I have just setup my unRAID server and for now it is going pretty smooth. I am a little paranoid by nature and absolutely want to avoid data failures If possible - the data drives are pretty safe in unRAID as long as the Parity drive is alive, and when the Parity drive is alive I can always rebuild the data array in case I loose a drive. No matter what way I turn it there is only one drive failure protection. To me it looks like it's the parity that takes the heaviest hits, as it always syncs when new data is added, therefor it must be the one that should fail first. Is there any way to RAID1 the parity drive and would it make sense doing so?
May 14, 201412 yr Yes, it is possible to RAID1 the parity disk with a hardware RAID card. I have a RAID0 4T parity made from 2 3T drive. This leaves 2T left over that I use to create a 1T RAID1 pair. It is separately mounted and not a part of my array. I think your assessment that because the parity disk is getting more writes it will fail first is flawed. First we typically don't write that much to our arrays. Second, I think that disks work better when they are used and that the idle drives are more apt to fail. I have never heard of a disk literally wearing out from overuse. And we have not seem, based on real world use, that the parity disks are failing at a faster rate than any other. The #1 indicator of drive death is manufacturer and model. Seagates, since the 1.5T days, have had very poor longevity. The Backblaze drive study shows 28% of their 2T drives failing each year. Contrast that with Hitachi (now HGST) which shows 2%. The 4T Seagates are showing promise as far as reliability (still not as good as HGST) and I bought my first pair of Seagates in 5 years recently. I am hopeful they hold up! Every other disk in my server is Hitachi or HGST. So I don't recommend RAID1 to protect parity. I recommend being picky about the drives you pick.
May 14, 201412 yr Author Yes, it is possible to RAID1 the parity disk with a hardware RAID card. I have a RAID0 4T parity made from 2 3T drive. This leaves 2T left over that I use to create a 1T RAID1 pair. It is separately mounted and not a part of my array. I think your assessment that because the parity disk is getting more writes it will fail first is flawed. First we typically don't write that much to our arrays. Second, I think that disks work better when they are used and that the idle drives are more apt to fail. I have never heard of a disk literally wearing out from overuse. And we have not seem, based on real world use, that the parity disks are failing at a faster rate than any other. The #1 indicator of drive death is manufacturer and model. Seagates, since the 1.5T days, have had very poor longevity. The Backblaze drive study shows 28% of their 2T drives failing each year. Contrast that with Hitachi (now HGST) which shows 2%. The 4T Seagates are showing promise as far as reliability (still not as good as HGST) and I bought my first pair of Seagates in 5 years recently. I am hopeful they hold up! Every other disk in my server is Hitachi or HGST. So I don't recommend RAID1 to protect parity. I recommend being picky about the drives you pick. I read the same study a long time ago and there for my current setup is two Hitachi 5K3000 2TB drives as data drive for a total of 4TB with a 5K3000 3TB drive as parity. Whenever I am going to fill on more drives to my Silverstone DS380 I have to switch to something else because the 5K3000 line is no longer to be found It hurts me a little as these drives seem to be the perfect fit in between price/reliability/power use and noise. Thank you for the heads up about drives working better when they are actually spinning instead of being idle. Thats very useful info!
May 14, 201412 yr I think that disks work better when they are used and that the idle drives are more apt to fail. I have never heard of a disk literally wearing out from overuse. And we have not seem, based on real world use, that the parity disks are failing at a faster rate than any other. My experience with Seagate ST3000DM001 drives would tend to disprove this. I have a unRAID server that is composed of those drives exclusively now but it was a mix of 2 & 3TB Seagate drives originally. I also have several SageTV servers that had the ST3000DM001 drives as recording drives and were set to ALWAYS have the drives spun up so I wouldn't get recording problems in SageTV. Both the unRAID server drives and the SageTV drives were purchased in the same time frame. I tended to order multiple drives at the same time and split them between the SageTV servers and the unRAID server. Well after a while I was getting drives on my SageTV server failing (lost about 2-4TB of recordings too ). So because of that and the fact that my 3TB Red unRAID server (all drives were same and drive count was 18) was running out of space I started buying 4TB Red drives and swapping out the 3TB Reds with the 4TB Reds. Once I had enough 3TB Reds as spares I put them in place of the ST3000DM001 SageTV recording drives. Then I swapped the ST3000DM001 drives for the 2TB Seagate drives in the unRAID server. NONE of the original 3TB Seagate drives in the unRAID Server have died yet. I now have about 8-10 of the Seagate SageTV recording drives sitting on my livingroom floor that will either end up in the landfill if out of warranty and unusable or RMA'd to Seagate if not out of warranty or used as off line backup if not completely dead. Of those 8-10 bad drives two don't show up in bios at all and the rest have a habit of throwing pending sectors or have actually reallocated sectors and may end up as off line backups. NOTE all the ST3000DM001 drives were precleared 3 cycles before use even though the majority of them didn't originally end up in an unRAID server. So long story short. With ST3000DM001 drives I have had better luck in a unRAID server with the drives spun down then those being written to frequently and always spinning. I will see if the 3TB Reds suffer the same fate. I suspect they won't which will just prove that for other drives your theory may be correct but with the ST3000DM001 drives my experience shows they are better off spending most of their life sleeping.
May 14, 201412 yr Thanks Bob. I prefaced my remarks with "I think" because there is little or no data on such things. It is very helpful to hear these personal experiences! Sage is a very dynamic environment and puts extremely high usage on drives. I am not shocked that they would fail quicker than a sleeping drive (already noting that Seagate drives of this vintage are at the bottom of the reliability scale). I was comparing a drive that sleeps almost all the time with one that goes for a run every day or two. . But you are correct in pointing out that mine was very much an oversimplification.
May 14, 201412 yr AT0MAC- I hear you on your fears regarding the parity drive, but one thing to remember... If you lose the parity drive, the data is still available on the data drives and if necessary you can always mount on say a windows box to get that data off. If you lose a data drive, then you can rebuild data from parity drive. If you lose a data and a parity at the same time (or your parity is invalid), then yes you have a problem where you will lose the data on that data drive. What i have been doing is backing up files that i consider critical that i NEVER want to lose to another location. I think thats why you will read about alot of people running multiple unraid servers. One is primary, and the other is where the primary gets backed up to. Of course, does that mean i should have a backup to the backup server? Or maybe i just like building unraid servers!
May 14, 201412 yr Have I missed something, can the parity not be rebuild with the data drives anymore?
May 14, 201412 yr Have I missed something, can the parity not be rebuild with the data drives anymore? Parity can most definitely be built from the data drives.
May 15, 201412 yr Right. I was just saying if you lose a parity drive, then worst case scenario, you still have the data on the data drives.
May 15, 201412 yr AT0MAC- I hear you on your fears regarding the parity drive, but one thing to remember... If you lose the parity drive, the data is still available on the data drives and if necessary you can always mount on say a windows box to get that data off. If you lose a data drive, then you can rebuild data from parity drive. If you lose a data and a parity at the same time (or your parity is invalid), then yes you have a problem where you will lose the data on that data drive. What i have been doing is backing up files that i consider critical that i NEVER want to lose to another location. I think thats why you will read about alot of people running multiple unraid servers. One is primary, and the other is where the primary gets backed up to. Of course, does that mean i should have a backup to the backup server? Or maybe i just like building unraid servers! IF you have a specific set of data on your array that you consider to be more valuable then others, then you could simply make a crontab job that copies that info to a different disk share.. Every night I copy my family photos and personal documents to another data disk (that way I have 2 disk failure protection for that data), I even do a copy every week to yet another disk (thus giving me 3 disk failure protection), I also do a monthly copy of this data set to yet ANOTHER disk.. So basically I can loose up to 4 drives in my array while stile retaining my most important data (if 2 or more disks fail at the same time I might loose data, can be a day, can be a week or can be a month). Ofcourse that only works for your most important data and it also only helps with DRIVE failures... Should your power supply kill on your or you get an electrical storm frying stuff then everything is gone... This is why I copy these files manually twice a year to a stand alone drive and put it with my parents 100km away.. For this most important data I am now moving towards cloud storage, that will take away the largest part of the whole issue..
Archived
This topic is now archived and is closed to further replies.