Preparing for Dual Parity ....


danioj

Recommended Posts

In the wake of the expected addition of Dual Parity to the list of unRAID features this year I find myself pondering the implications and preparing for the release.

 

As my Sig suggests I have 2 servers. 1 Main and 1 Backup. Backup is a mirror of Main (at the user share level NOT disk level). I do NOT access Backup for content as a rule unless absolutely required. All access for content is made via Main. I have (once) used Backup for content when Main went down (and this is one of the reasons I mirror the shares so I can do a quick DNS swap and all clients will point to Backup if I want them to instead of Main) BUT as I said as a rule I don't.

 

Anyway, my dilemma is .... Do I need Dual Parity for the Backup Server? I obviously can see the benefit and certainly DO want it for the Main server because I want as little to no down time as possible there anyway. Yes there may come a time (if Main goes down again - which with Dual Parity will become less likely anyway) where the availability of Backup is as critical as the Main server is today BUT at that time Ill be doing my upmost to restore Main to normal operation anyway.

 

Personal preference and personal decision over need for availability aside (which I know this is) - what would others do in this scenario and what do you all think?

Link to comment

On my backup systems I run Windows server and drive pool. I purposely want them on a different OS that my main machines. But as to dual parity, to be completely honest since you have a full backup machine like me, it would probably be quicker to not use parity at all and if a disk fails, swap in a new disk and repopulate the missing content over what I assume is a gigabit network. No cache drive or slow parity writes required.

 

I'm building my new unRAID machines so I will use parity and will also be leaving a drive unassigned for when dual parity hits. But that's only because I'm lazy and find it easier to replace a failed drive, click a button and go on about my laziness :)

Link to comment

Interesting. I am using Parity (as unRAID implements it currently) in my Backup Server already. I do this because I want to protect against downtime of the Backup server (for my daily incremental backups which are unattended) and also data loss should one of the Backup Server disks fail. I would perhaps not care if the data amounts were low (ie 1-4TB) BUT should one of my Backup server disks fail (given I also mirror at the share and have no idea how unRAID distributes files a cross the disks) to restore the Backup from Main  after replacing the failed disk - I will have to copy the entire 23TB of my Main server over to the Backup again. Yes I have a Gigabit network but that still takes ages. In addition, in that time I would be down to relying on a disk not failing on the Main Server during that copy operation which (if it happened) could jeopardise my ability to make the Backup copy again if a failure then happened on my Main server. Yes the Main server is also Parity protected (which might be enough to get me through the copy operation to Backup server again) but that initially sounded like a viable worst case scenario when I built the setup and didn't want to experience it.

 

Do you think I am being too cautious? I guess if you do I have an 8TB drive acting as parity in my Backup server I could be using as space elsewhere. No wrong answer, just interested in your (and others) opinion?

Link to comment

why would you need to copy the entire server over again instead of just rsync'ing from the main share to the backup share?

 

For some reason I had it stuck in my head that in a non parity protected array if one disk was removed then coping (I don't use Rsync but I use a Windows cool called SyncBak which has similar functions) I would have to do a whole copy. Fact is of course you're right, I was missing the big benefit of unRAID (one or more disks go, the others are still readable). Adding a new disk in that situation will just increase space available on the share - the Sync tool will notice that there are "Missing Files" on the share and just copy them over. Doh.

 

Hmmm. I am really thinking about moving the 8TB parity disk on my Backup server into my Main or Backup array as space now. I know Parity protected Backup is an added layer of security BUT with a complete backup Over two servers perhaps I am being too cautious and loosing a disk or even 2 on the Backup Server is not that big of an issue given I have a Parity Protected Main Server too. Perhaps the disk is best served as a data disk!

 

Food for thought.

Link to comment

I plan on using dual parity on my backup server first for 3-4 months.... If something wonky is to happen I do not want to catch it on my main machine or propagated to the data backup.

 

What you are planning to do sounds reasonable, especially when 6.2 is in BETA and is not stable. In the OP I was referring to plans post release of the stable version.

Link to comment

Honestly, I think you are being too cautious. Having a full server for back ups of your back up server is a lot already. I know some data is important, and I understand what you are saying. To me it also sounds like daily back ups of other boxes are overkill. I don't know exactly what you are backing up daily, but most computers are static enough that weekly backups should be more than enough. I do think that dual parity will be great though, and honestly I would (and will) put it into any server I run, the difference is I think running one back up server is enough. Don't take this as me knocking your set up in any way, just my take on things. I also hope this doesn't mean the back up gods will spite me soon for only running one back up.

Link to comment

Honestly, I think you are being too cautious. Having a full server for back ups of your back up server is a lot already. I know some data is important, and I understand what you are saying. To me it also sounds like daily back ups of other boxes are overkill. I don't know exactly what you are backing up daily, but most computers are static enough that weekly backups should be more than enough. I do think that dual parity will be great though, and honestly I would (and will) put it into any server I run, the difference is I think running one back up server is enough. Don't take this as me knocking your set up in any way, just my take on things. I also hope this doesn't mean the back up gods will spite me soon for only running one back up.

 

Thanks for sharing your take on things. I am leaning towards the fact that I might be being too cautious.

 

Each Server has 3 shares. Flash (Which is the Flash drive of each server) App (Which houses my Dockers and VM's) and NAS (Which is the root share of the Server).

 

But to clarify this is my schedule of things:

 

Mover Daily at 23:00 (Assumption is it takes no longer than 1 hour as Cache is <= 250GB)

SSD TRIM Daily @ 00:00

Parity Check  Monthly on the 1st at 3:30 (Assumption is it finishes before 23:00 that same day 19.5 Hours)

File Integrity Check Monthly on the 27th at 3:30 (Assumption is it finishes before 23:00 the same day 19.5 Hours)

 

Daily Backup of Flash and App (of both servers) to the Main Server at 00:00 and 00:15 (Assumption is Flash backup takes no longer than 45 mins and App no longer than 1 hour as App is <= 250GB)

Weekly Backup (Sunday) of Flash and App (of both servers) to the Main Server at 01:15 and 01:30 (Assumption is Flash backup takes no longer than 15 mins and App no longer than 1 hour as App is <= 250GB

** Daily and Weekly Backups of Flash and App are like snapshots and are stored separately and are for Backup and Main Servers. Each time they run they overwrite the previous.

 

Daily Backup of Main Server NAS share at 02:30 to the Backup Server NAS share (Assumption is it takes no longer than 1 hour as I only transfer <= 250GB per day)

**Daily Backup of Main NAS is from Main to Backup and is an Incremental Backup and doesn't delete (So essentially just backs up what is new to the array that day).

 

So In summary I always have a daily and weekly backup of both servers' flash and app shares available to me to help me with issues so I can restore to a previous daily or weekly version if I need. I also have a daily backup of my Main Servers' NAS share (and because I don't mirror - as in I don't delete - it caters for instances of accidental file deletion).

 

Note: Backups Bypass the Cache drive of the Main Server. No Cache Drive on the Backup Server.

 

Hmm - just copying this from my notepad and reading it again screams overkill. Couple with the fact that each Array is single disk Parity protected too perhaps I DID go overboard when I set this up.

 

Right, I almost have decided. Dual Parity on the Backup Server is even more so too much!

Link to comment

It's not that your being too cautious, everyone has s limit of what they feel comfortable with. As for my original comment above, it may have sounded odd when I said I would just replace the missing content. I was referring to just that specific drive that failed. Sounds like you were looking at it from having to replace the entire array. Now that we're on the same page I hope my comments make a little more sense :)

 

As I said I'll use the dual parity simply because I want to click a button within unRAID and have it do its thing. But I suspect replacing the failed drive and just copying over the missing data would actually be substantially quicker rather than a drive replacement, let unRAID rebuild the missing content, then run a parity check.

 

Im moving to unRAID for different reasons than most. I liked the fact it boots off s thumb drive freeing up a drive slot compared to Windows Server. I like the simple GUI accessed by any web browser rather than having to use Remote Desktop. Speaking of the GUI, it's very simple and straight forward. I like seeing all my drive temps right on one page. I like it showing me smart warnings with a small icon then clicking on that icon takes me to the actual smart data. So it took what I liked about Windows Server and made it more simple with w better interface. The parity drive is a benefit but I'm not real comfortable with only having one parity drive protecting my array. I use it because it's there but it's not critical for me like it is others users since I have full backups in a secondary server like yourself. Dual parity will make it better but I would really like to see LT catch up to other NAS OS's and offer three or four parity drives. When it comes to data protection, LT has dropped the ball and focused on other features unrelated to a NAS like dockers and VM's.

Link to comment

Clearly it's a personal decision r.e. whether to use dual parity in both arrays.

 

A few thoughts ...

 

(1)  I do NOT recommend using an unprotected array (no parity) for either server.  This completely defeats the purpose of a fault tolerant server.    If you wanted to do that, I'd say just use a Windows box and dynamic disks ... no need for a separate storage server.  [in fact, if you actually wanted to run with an unprotected array and have a fault tolerant backup server (with dual parity) that wouldn't be a bad configuration.]

 

(2)  Given that you have a complete mirror, it's certainly not unreasonable to add dual parity to the main server, but leave the backup with single parity.    Consider the use case:  The vast majority of your use is with the primary server;  the backup server is only accessed once/backup interval (day, week, etc.) ... so it's not nearly as critical.  And, with dual parity, the following should also be true:

 

  (a)  If a drive fails on the main server, it's VERY unlikely you won't be able to rebuild it without any access of the backup server, since even if you had a 2nd failure during the rebuild it would still be okay (thanks to dual parity).

 

  (b)  If a drive fails on the backup server, as long as the rebuild completes okay, all is okay.  In the unlikely event you had a 2nd failure during a rebuild, you could simply replace both failed drives; do a New Config; and then just do a SyncBack from the main server to the backup ... only those files actually needed will be copied (as you realized after thinking about it).    That should be a VERY unlikely occurrence.

 

(3)  Notwithstanding what I just said in #2, adding a 2nd parity drive to the backup server does provide yet-another layer of protection, which almost totally eliminates the likelihood of ever having to resync your two servers.  It just depends on whether you want to spend the $$ for that bit of additional "peace of mind"  :)

 

FWIW, my plan is to add dual parity to my primary servers, but NOT to my backup server.

 

As a bit of off-topic aside, vis-à-vis what I mentioned in #1, I have a friend who does exactly what I mentioned in that paragraph.  His complete media collection easily fits in 15TB or so, with modest growth; so he has 3 8TB drives installed in his primary Windows PC as a single dynamic volume (M:) of 24TB; and a backup UnRAID server with 8 4TB drives that he uses to store image backups of his OS; and backups of his data, laptops, and the M: drive on.    This actually works nicely ... and of course the write speeds to M: are FAR better than you'd ever see with an UnRAID box (well over 100MB/s).    Personally, I want my data fault tolerant immediately when I write new data ... so I don't use that kind of setup ... but it can and does work nicely as long as you're okay with the risk.    I'm also not sure what would happen if one of those disks failed ... if it was replaced I don't know if the content of the other component disks would still be there, or if the entire M: drive would have to be copied back from the backup server [Have never experimented with that -- I don't use dynamic disks in any of my Windows machines.].

 

 

 

 

Link to comment

Clearly it's a personal decision r.e. whether to use dual parity in both arrays.

 

A few thoughts ...

 

(1)  I do NOT recommend using an unprotected array (no parity) for either server.  This completely defeats the purpose of a fault tolerant server.    If you wanted to do that, I'd say just use a Windows box and dynamic disks ... no need for a separate storage server.  [in fact, if you actually wanted to run with an unprotected array and have a fault tolerant backup server (with dual parity) that wouldn't be a bad configuration.]

 

 

When it is put like that, clearly you are correct. There is a reason I am using unRAID for the Backup Server (given I am only utilising it for a single VM and 1 docker only because I can) and that is Fault Tolerance. I am STILL undecided on the need for Dual Parity on the Backup Server BUT I don't think I will remove the single Parity drive from the Backup server.

 

(2)  Given that you have a complete mirror, it's certainly not unreasonable to add dual parity to the main server, but leave the backup with single parity.    Consider the use case:  The vast majority of your use is with the primary server;  the backup server is only accessed once/backup interval (day, week, etc.) ... so it's not nearly as critical.  And, with dual parity, the following should also be true:

 

  (a)  If a drive fails on the main server, it's VERY unlikely you won't be able to rebuild it without any access of the backup server, since even if you had a 2nd failure during the rebuild it would still be okay (thanks to dual parity).

 

  (b)  If a drive fails on the backup server, as long as the rebuild completes okay, all is okay.  In the unlikely event you had a 2nd failure during a rebuild, you could simply replace both failed drives; do a New Config; and then just do a SyncBack from the main server to the backup ... only those files actually needed will be copied (as you realized after thinking about it).    That should be a VERY unlikely occurrence.

 

(3)  Notwithstanding what I just said in #2, adding a 2nd parity drive to the backup server does provide yet-another layer of protection, which almost totally eliminates the likelihood of ever having to resync your two servers.  It just depends on whether you want to spend the $$ for that bit of additional "peace of mind"  :)

 

For the sake of $299 AUD (Price of an 8TB drive here in Australia) I get Dual Parity (assuming of course LT release Dual and not n Parity) and that actually seems like a really good deal for the absolute peace of mind. I'm getting closer ....  :)

 

FWIW, my plan is to add dual parity to my primary servers, but NOT to my backup server.

 

As a bit of off-topic aside, vis-à-vis what I mentioned in #1, I have a friend who does exactly what I mentioned in that paragraph.  His complete media collection easily fits in 15TB or so, with modest growth; so he has 3 8TB drives installed in his primary Windows PC as a single dynamic volume (M:) of 24TB; and a backup UnRAID server with 8 4TB drives that he uses to store image backups of his OS; and backups of his data, laptops, and the M: drive on.    This actually works nicely ... and of course the write speeds to M: are FAR better than you'd ever see with an UnRAID box (well over 100MB/s).    Personally, I want my data fault tolerant immediately when I write new data ... so I don't use that kind of setup ... but it can and does work nicely as long as you're okay with the risk.    I'm also not sure what would happen if one of those disks failed ... if it was replaced I don't know if the content of the other component disks would still be there, or if the entire M: drive would have to be copied back from the backup server [Have never experimented with that -- I don't use dynamic disks in any of my Windows machines.].

 

You're arguments are very valid BUT like you note above it comes down to what I want to pay for what I get. When I consider I have the scalability already in both Servers and the addition of this new feature by LT in unRAID means basically for $299 AUD I get the peace of mind knowing that on both Servers I have the possibility of 2 disks failing. Which - if you think about it - means I would need 6 disks across 2 servers to fail to get to a position of data loss - and assuming I act quickly (which I would) I can't imagine is probable at all.

 

I really like that idea! And all for < $600 AUD. Sounds like a good deal!

Link to comment

Damn those disks are expensive! I know it's rare to have a two disk failure but I have actually had it happen (not on unRAID). Replaced the disk and had another failure during the rebuild. Don't know if something like that will strike twice with the same person but dual parity should put that issue into the past.

 

I think whatever decision you make, it will be the right one for you. Everyone's risk tolerance is different.

Link to comment

Damn those disks are expensive! I know it's rare to have a two disk failure but I have actually had it happen (not on unRAID). Replaced the disk and had another failure during the rebuild. Don't know if something like that will strike twice with the same person but dual parity should put that issue into the past.

 

I think whatever decision you make, it will be the right one for you. Everyone's risk tolerance is different.

 

Slightly off topic, but I have to address what you said about drive cost.

 

Really you think $299 AUD for 8TB is expensive? Thats ~$37.30AUD per TB! I think that is cheap as hell!

 

I just checked Amazon (http://www.amazon.com/Seagate-Archive-Internal-Hard-Drive/dp/B00XS423SC) and the same drive is $239 USD which on today's exchange rate is $344 AUD so i figure even in comparison to USD price it is a good deal! Per TB in USD is $29.80 USD!!

 

Anyway ....

 

You're right. Its all down to each of us to decide what we want and what we will deal with. In short for me uptime is paramount and I never want to get into a situation where data loss is a reasonable possibility! I can live with 1 in million (I say that figuratively and without doing the math of course for those reaching for the calculator) but not beyond that!

 

Link to comment

I absolutely agree that 8TB drives are CHEAP !!    Adding two provides a level of fault tolerance that will, as Daniel noted, reduce the real likelihood of data loss to about as close to zero as you can reasonably get.    The likelihood of SIX drives failing before you had corrected a single drive failure is exceptionally small !!

 

BTW, if you think $30 or so per TB is expensive, you clearly haven't been messing with computers long enough  :) :)

 

I paid approximately $173,076,923.08 per TB for my first hard drive  :)

[in today's dollars it would be over $700 MILLION per TB !!]

 

Link to comment

Na, you took it wrong too. I wasn't referring to the cost per GB. It wasn't even a blanket statement. Was referring the cost of a drive, not specifically a 8TB drive.

 

I never paid what you paid. The most expensive I paid was back in maybe 2001 or which was like $400 for a 320 GB. And I thought that was bad.

 

Just wait a few years and we will say the same thing about we can't believe we paid $XXX for a 10TB drive. How did we ever get by with so little storage!!

Link to comment

My first PC was one of these I built in Dec 1974:  http://www.oldcomputers.net/altair-8800.html

 

I started with 4KB of static RAM for $300, but later added a 64KB card that cost about $1000

 

It had a cassette interface that let you store data on cassette tapes -- a significant pain.

 

In all, I spent ~ $2500 or so on that machine (probably $12,000 or so in today's dollars).

 

I had MANY other systems throughout the 70's ... IMSAI, Digital Group, NorthStar, a Heathkit H11 (a small PDP-11 microcomputer), CompuPro, etc.    It was a VERY expensive hobby, but I thoroughly enjoyed it, and did a good bit of consulting on the side that helped pay for it.  Probably spent ~ $25,000 or so in that decade.    Today's gear seems virtually free compared to what it used to cost  :)

 

 

 

 

 

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.