Jump to content
JimPhreak

Backup UnRAID server specs

65 posts in this topic Last Reply

Recommended Posts

I'm looking to build an UnRAID server that I will use to make weekly or monthly backups of my main UnRAID server to a different location via rsync over a VPN connection.

 

My question is what kind of hardware specs should I be looking at since it's just a backup and will be power off a majority of the time?  My main UnRAID server has the following specs:

 

- SuperMicro X10SLM-F

- Intel i3 4130 CPU

- 8GB ECC DDR3 RAM

- 6x 3TB WD Reds

- 1x 3TB Hitachi 3K Deskstar (cache drive)

 

This server is for storage and shares only so it's obviously overkill.  I have a beefy VM server that runs Plex for multiple file transcoding, etc.  So I'm thinking I can probably get away with a less beefy server for my backup server than my main UnRAID server is, I'm just unsure of how beefy I need it.

 

Budget is $1,000 including the drives.

 

Any suggestions would be very much appreciated.

Share this post


Link to post

... Budget is $1,000 including the drives ...

 

Might be a bit tight, but should be doable.  That budget level likely eliminates using 6 or 8 TB drives, but you could build a nice backup system with 4TB WD Reds.  Newegg has a 4-pack for $599 right now (one of today's "Shell Shocker deals" ... so you could get 5 of them for $769, which would give you 16TB of capacity -- a bit over the 15TB you have on your main server.

 

To keep things as low cost as possible, here are a few things that would work ...

 

Motherboard ($70):  http://www.newegg.com/Product/Product.aspx?Item=N82E16813157547

CPU ($46):  http://www.newegg.com/Product/Product.aspx?Item=N82E16819116974

Memory ($40):  http://www.newegg.com/Product/Product.aspx?Item=N82E16820148758

 

So excluding the case, power supply, and UnRAID license you could do this for $925 with a very nice Haswell-based system.    That's going to put you a bit over your target by the time you buy a quality power supply and a case, but not by much.

 

You could reduce the cost somewhat by using WD Green series drives instead of the Reds ... they're just under $140 each right now for the 4TB units, so you could buy 5 for $700 -- about $70 less than the Reds (I think the Reds are worth the difference, but the greens are still very nice drives).

 

 

 

Share this post


Link to post

... Budget is $1,000 including the drives ...

 

Might be a bit tight, but should be doable.  That budget level likely eliminates using 6 or 8 TB drives, but you could build a nice backup system with 4TB WD Reds.  Newegg has a 4-pack for $599 right now (one of today's "Shell Shocker deals" ... so you could get 5 of them for $769, which would give you 16TB of capacity -- a bit over the 15TB you have on your main server.

 

To keep things as low cost as possible, here are a few things that would work ...

 

Motherboard ($70):  http://www.newegg.com/Product/Product.aspx?Item=N82E16813157547

CPU ($46):  http://www.newegg.com/Product/Product.aspx?Item=N82E16819116974

Memory ($40):  http://www.newegg.com/Product/Product.aspx?Item=N82E16820148758

 

So excluding the case, power supply, and UnRAID license you could do this for $925 with a very nice Haswell-based system.    That's going to put you a bit over your target by the time you buy a quality power supply and a case, but not by much.

 

You could reduce the cost somewhat by using WD Green series drives instead of the Reds ... they're just under $140 each right now for the 4TB units, so you could buy 5 for $700 -- about $70 less than the Reds (I think the Reds are worth the difference, but the greens are still very nice drives).

 

 

Thanks for the suggestions, it's very much appreciated.  Where do you see that shell-shocker deal for the 4TB WD Reds?

Share this post


Link to post

... Where do you see that shell-shocker deal for the 4TB WD Reds?

 

This link may not be persistent -- the Shell Shockers are time-limited and this one is good until 10AM Pacific time (about 2 hrs and 25 minutes from now):

 

http://www.newegg.com/Special/ShellShocker.aspx?utm_medium=Email&nm_mc=EMC-SD032015&cm_mmc=EMC-SD032015-_-SD031015-_-item-_-22-236-599&et_cid=16380&et_rid=52760&et_p1=

Share this post


Link to post

... Where do you see that shell-shocker deal for the 4TB WD Reds?

 

This link may not be persistent -- the Shell Shockers are time-limited and this one is good until 10AM Pacific time (about 2 hrs and 25 minutes from now):

 

http://www.newegg.com/Special/ShellShocker.aspx?utm_medium=Email&nm_mc=EMC-SD032015&cm_mmc=EMC-SD032015-_-SD031015-_-item-_-22-236-599&et_cid=16380&et_rid=52760&et_p1=

 

Ahhh, sweet thanks for the link.

 

Will there be any issues with me doing rsync between two servers with different hard drive setups?  Just wondering how the split levels would transfer over if I have 5 data drives in one server and only 4 in the other.  The reason I ask is I can just duplicate my current setup (6x3TB WD Reds) for $80 less than getting 5 x 4TB WD Reds.  I still have 5.65TB of space left on my main server so I'm not sure how soon I'll need more space.  Probably a few years.

Share this post


Link to post

The advantage of duplicating the servers exactly with the same size disks in all slots, is that you can rsync disk1 to disk1. Then in the case of a worst case disorder you just take disk7 from the backup server and replace disk7 in your production server.

 

That's what I do.  I have a mix of drive sizes but for the disks that are rsynced to a backup server, disk7 matches disk7 in the backup server in size.  There was one time due to user error that multiple drives from the backup server were put back into the production server with no fuss and no drama.

Share this post


Link to post

The advantage of duplicating the servers exactly with the same size disks in all slots, is that you can rsync disk1 to disk1. Then in the case of a worst case disorder you just take disk7 from the backup server and replace disk7 in your production server.

 

That's what I do.

 

Ah, I do like having that ability.  Thanks for confirming that.

Share this post


Link to post

The advantage of duplicating the servers exactly with the same size disks in all slots, is that you can rsync disk1 to disk1. Then in the case of a worst case disorder you just take disk7 from the backup server and replace disk7 in your production server.

 

That's what I do.

 

Ah, I do like having that ability.  Thanks for confirming that.

I would expect that moving in a disk from another server, even if it has identical files, would invalidate parity, though.

Share this post


Link to post

Anyone have a PSU recommendation?  This server will probably be powered on once a week for backups, and then shut down.

Share this post


Link to post

Agree that using a matching set of disks has the "advantage" of being able to sync the individual disks.  I do my backups by share [e.g. "Movies",  "TV Shows", etc.] and don't worry about matching the individual disks.    That allows you to either use larger disks for your backup server (thus needing fewer disks and potentially a smaller chassis)  or smaller disks for your backup server (letting you use your older disks that you've upsized on your main system).

 

But I certainly understand the attraction of having matching disks.

 

Share this post


Link to post

Agree that using a matching set of disks has the "advantage" of being able to sync the individual disks.  I do my backups by share [e.g. "Movies",  "TV Shows", etc.] and don't worry about matching the individual disks.    That allows you to either use larger disks for your backup server (thus needing fewer disks and potentially a smaller chassis)  or smaller disks for your backup server (letting you use your older disks that you've upsized on your main system).

 

But I certainly understand the attraction of having matching disks.

 

Just a follow up because I am curious too, if say disk 3 were to fail in your primary server, you would recover the missing data by installing the new (precleared) disk in the primary server and then using rsync to "rebuild" the data at the share level from the backup server? This would do so while preserving parity?

 

Is the only con to this not being able to physically move the disk from the backup sever to the primary server?

 

Share this post


Link to post

Agree that using a matching set of disks has the "advantage" of being able to sync the individual disks.  I do my backups by share [e.g. "Movies",  "TV Shows", etc.] and don't worry about matching the individual disks.    That allows you to either use larger disks for your backup server (thus needing fewer disks and potentially a smaller chassis)  or smaller disks for your backup server (letting you use your older disks that you've upsized on your main system).

 

But I certainly understand the attraction of having matching disks.

 

Just a follow up because I am curious too, if say disk 3 were to fail in your primary server, you would recover the missing data by installing the new (precleared) disk in the primary server and then using rsync to "rebuild" the data at the share level from the backup server? This would do so while preserving parity?

 

Is the only con to this not being able to physically move the disk from the backup sever to the primary server?

No this approach as you have described it would not preserve parity.

Share this post


Link to post

Actually doing an rsync from the backup server to the primary server for a share WILL preserve parity -- PRESUMING parity is valid on the primary server.

 

Consider the scenarios:

 

(1)  Disk3 on the primary server fails, but it's the ONLY disk that failed.    In that case, I'd simply put in a new disk for #3, and let UnRAID do it's thing to rebuild the disk.  Done ... no need for any data from the backup.

 

(2)  Disk3 on the primary server fails, but you don't want to do a rebuild [Perhaps you have a pre-cleared disk that's smaller than the failed disk but large enough for the data it had on it].    You could, in that case, do a New Config with the new disk and do a parity sync.  You now have good parity.    You would then rsync the shares that had data on the failed disk, and the data would all be restored ... and parity would be preserved throughout that process.

 

(3)  Disk3 and some other disk both fail ... so a drive rebuild isn't an option.    In this case, you could simply replace both of the failed disks;  do a New Config and a parity sync;  and then do rsyncs for the involved shares -- again, parity will be preserved during the rsyncs.

 

Share this post


Link to post

Actually doing an rsync from the backup server to the primary server for a share WILL preserve parity -- PRESUMING parity is valid on the primary server.

 

Consider the scenarios:

 

(1)  Disk3 on the primary server fails, but it's the ONLY disk that failed.    In that case, I'd simply put in a new disk for #3, and let UnRAID do it's thing to rebuild the disk.  Done ... no need for any data from the backup.

 

(2)  Disk3 on the primary server fails, but you don't want to do a rebuild [Perhaps you have a pre-cleared disk that's smaller than the failed disk but large enough for the data it had on it].    You could, in that case, do a New Config with the new disk and do a parity sync.  You now have good parity.    You would then rsync the shares that had data on the failed disk, and the data would all be restored ... and parity would be preserved throughout that process.

 

(3)  Disk3 and some other disk both fail ... so a drive rebuild isn't an option.    In this case, you could simply replace both of the failed disks;  do a New Config and a parity sync;  and then do rsyncs for the involved shares -- again, parity will be preserved during the rsyncs.

(1) of course preserves parity but has nothing to do with the backup server.

 

(2) does not actually preserve parity. It rebuilds parity with a New Config. After that, anything you write to it preserves parity however it is done, including rsync from the backup.

 

(3) similar to (2)

 

Each of these are pretty far removed from his original description.

Share this post


Link to post

I interpreted the question as to whether an rsync from the backup server to the primary drive would have any impact on parity -- and the answer is clearly no, it will not.  If parity is valid, it will be preserved.  Clearly if you don't have valid parity at that time, you still won't  :)

 

Share this post


Link to post

I'm glad this discussion got started because it's helped me understand some of the different ways to go about restoring your data when you've got a good backup option.  I'm definitely going to consider all of it when I start setting up my backup.

 

In terms of the backup server itself, I think I've decided to go with the 6x3TB WD Red drives and the Celeron G1820. 

 

Just still looking for the following:

 

- good MB to use that will support 7 drives (otherwise I'll probably leans towards another Serveraid M1015 to support extra drive and for future upgrade needs)

- PSU (thinking 400w range?)

- Chassis (want to keep small footprint but haven't looked extensively for this yet)

 

Also have a question on the cache drive for the backup server.  First off, needed?  Secondly, how big?  My main server has a 3TB cache drive but I realize that's way overkill (only 2 drives I had laying around for my cache were 3TB Hitachi Deskstar 7k3000 drives, the other is a cold spare).

Share this post


Link to post

This is a pretty good thread.

 

All the talk about backup servers has got me thinking.  What if instead of syncing the servers, you wanted to do a true incremental backup from one server to the other?  I'm of course thinking about those times when the drives are fine, but you've accidentally deleted a file or changed a file and need an old version of it back, if you don't realize that before a sync is scheduled you'd be screwed.  With what I'm thinking, maybe you'd be able to go into a console of some sort and restore an older version of it. 

 

I know software like this exists, but the question is, is there a version that would work on an unraid server?  Maybe as a docker? 

 

 

Share this post


Link to post

A quality 400-450w power supply will be plenty.

 

I don't see any reason to use a cache ... I presume your backups are going to be effectively unattended, so it shouldn't matter just how quick the writes are ==> and for that matter, if you're doing it over a VPN it's likely that the limiting factor is going to be your internet upload speed anyway.

 

 

Share this post


Link to post

As far as a case goes, here are two good alternatives ...

 

For a microATX, look at the Fractal Design Mini ... it's amazingly quiet and very well made.

http://www.newegg.com/Product/Product.aspx?Item=N82E16811352011

 

For mini-ITX the Lian-Li PC-Q25B is hard to beat, although it's becoming difficult to find (not sure if it's going to still be available in the future).   

http://www.newegg.com/Product/Product.aspx?Item=N82E16811112339&cm_re=Q25B-_-11-112-339-_-Product

http://www.ebay.com/itm/Lian-Li-PC-Q25B-Black-Aluminum-Mini-Tower-Mini-ITX-Computer-Case-/271796619646?pt=LH_DefaultDomain_0&hash=item3f4857497e

 

 

 

Share this post


Link to post

r.e. my earlier thoughts on a cache drive (not necessary) ...

 

I just noted your other thread discussing this -- where you mention that you have 75Mb upload speeds from your primary server.  That's a VERY good upload speed, but is still less than 1/3rd the speed that UnRAID can write data without a cache ... so clearly there's NO reason to use a cache drive in your backup server.

 

Share this post


Link to post

A quality 400-450w power supply will be plenty.

 

I don't see any reason to use a cache ... I presume your backups are going to be effectively unattended, so it shouldn't matter just how quick the writes are ==> and for that matter, if you're doing it over a VPN it's likely that the limiting factor is going to be your internet upload speed anyway.

 

As far as a case goes, here are two good alternatives ...

 

For a microATX, look at the Fractal Design Mini ... it's amazingly quiet and very well made.

http://www.newegg.com/Product/Product.aspx?Item=N82E16811352011

 

For mini-ITX the Lian-Li PC-Q25B is hard to beat, although it's becoming difficult to find (not sure if it's going to still be available in the future).   

http://www.newegg.com/Product/Product.aspx?Item=N82E16811112339&cm_re=Q25B-_-11-112-339-_-Product

http://www.ebay.com/itm/Lian-Li-PC-Q25B-Black-Aluminum-Mini-Tower-Mini-ITX-Computer-Case-/271796619646?pt=LH_DefaultDomain_0&hash=item3f4857497e

 

r.e. my earlier thoughts on a cache drive (not necessary) ...

 

I just noted your other thread discussing this -- where you mention that you have 75Mb upload speeds from your primary server.  That's a VERY good upload speed, but is still less than 1/3rd the speed that UnRAID can write data without a cache ... so clearly there's NO reason to use a cache drive in your backup server.

 

Thanks for the recommendations and for the info regarding the cache drive.  I may put a cache drive in it for a week when I actually bring the backup server to the same location as my main server so that I can do a quicker initial backup since I have about 10TB to backup.  Then once it's initially synced, I will remove the cache since the incremental backups after that won't be that big to require one.

Share this post


Link to post

Thanks for the recommendations and for the info regarding the cache drive.  I may put a cache drive in it for a week when I actually bring the backup server to the same location as my main server so that I can do a quicker initial backup since I have about 10TB to backup.  Then once it's initially synced, I will remove the cache since the incremental backups after that won't be that big to require one.

 

I get what you are going for here, but in your case I think a cache might slow down your transfer process. The issue is that no cache drive you can buy will be able to hold the full 10 TB you plan to transfer (and likely your cache will be much smaller than 10 TB). The way the cache drive works is that all data is first written to that cache (unless you have the share set to not use the cache) and then at a specified time once a day that data is copied to the array. It doesn’t really speed up the transfers to the array it just hides it from the user by making it a two step process, where the user only sees the first faster transfer.

But this is where your problem arises, if you fill the cache you won’t be able to continue copying data to the array, this either means you have to divide your initial transfer into many smaller transfers that are less than the size of your cache and then manually invoke the mover script to free the space again (but also making you not only wait for the transfer to the cache but also wait for the data to be written to the array) or only transfer a smaller amount then your cache each day (you’ll only feel this transfer) and not feel the write to the array.

If you want to speed up the initial transfer your best bet is to do it without enabling a parity disk on the backup server. Once the initial transfer is complete then enable your parity disk and calculate parity for the first time.

 

Share this post


Link to post

Agree with gundamguy => adding a cache for the initial backup would almost certainly make that backup take LONGER than it would without it.

 

You could, as he suggested, simply do the entire initial backup without a parity drive assigned (so the writes would be at "disk speed") => the only disadvantage of that is there's no fault tolerance until you get the parity drive assigned and the parity sync done.

 

Share this post


Link to post

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.