Time for FreeNAS Server Redundancy - Cutting Corners

[HeloJunkie]

OK so my hobby system is running 3 x 6 Drive vdevs (4TB drives), soon adding a 4th vdev using 8TB drives (as soon as the drives arrive) all running RAIDZ2. While this is my 'hobby' system, it would sure stink to lose all the media I have stored on my system due to anything, so I have decided to look at firing up a second FreeNas box to backup my primary FreeNAS server.

I know the 'purest' answers to my questions are to build the second server the same as I did my first (see configs below in my signature) using best practices, but my goal is a less costly, mostly offline backup. I want to fire up my backup FreeNAS system about once a week, do an rsync between systems and then shut back down. If I lose the pool on my primary, I can fix the glitch and restore from the backup FreeNAS server. The backup FreeNAS server will never be used to serve data to anyone or anything other then to restore my primary machine.

My primary machine talks via NFS to a single machine - a plex media server. No other shares or mount points are used.

So....I understand best practices and know them well, but since this is a BACKUP system only, I was wondering about the following:

1) Do I have to keep to the 20% available overhead rule to keep ZFS happy or can I use 5 to 10% instead for space savings
2) Can I get by with 32GB RAM as opposed to 64GB or 128GB calculated via best practices.

What I DON'T want is a crippled system as a result of trying to save a few $$$ on a backup solution, but at the same time this is not a production system so can FreeNAS run with less ram and less overhead drive space if it is not being used as a primary system.

Thanks for any insight!

 

[JohnDigital]

1) I would keep AT LEAST 10% free space at all times. This is the point when FN will give RED light and issue/email critical alerts, and performance really starts to take a hit. However, this is from solaris ...

Code:

Keep pool space under 80% utilization to maintain pool performance. Currently, pool performance can degrade when a pool is very full and file systems are updated frequently, such as on a busy mail server. Full pools might cause a performance penalty, but no other issues. [...] Keep in mind that even with mostly static content in the 95-96% range, write, read, and resilvering performance might suffer.

2) For your sake 32GB might even be overkill, certainly it is plenty for what you want to do (no overhead). Its no secret that FN loves RAM and in any case, give it as much as you can. But IMHO 32gb will be more than enough for this menial task.

 

[HeloJunkie]

John -

Thank you for this information, exactly what I was looking for but could not really find!

 

[JohnDigital]

Sure thing, good luck!

 

[styno]

Don't do an rsync when you can use the built-in replication tasks based on snapshots.
When you start the backup system, the replication will automatically resume where it stopped last time.
I am doing exactly the same thing, it's easy and maintenance free.

 

[Arwen]

Actually, for a backup NAS, 16GB of RAM might be more than enough. Just allow the option to
move to higher amount of RAM without removing RAM. Meaning, don't fill up all your slots with
16GB, (unless it makes great financial sense). Remember, ZFS loves RAM for it's READ Cache!
Pure backup NASes are write mostly.

As for redundancy, you may be able to get away with RAID-Z1, even with larger disks. As long
as you maintain it well, (scrubs, replace disks as needed), then any lost backup pool should not
be a problem. Your primary should still have all the data.

Last, you may be able to use very large disks in you backup NAS. For example, the Seagate 8TB
Archive SMR disks were at one point cheaper than any other 8TB disks. Not great performers,
especially on writes. But, if you are limited to 1Gbps Ethernet and understand backups potentially
taking a bit of time, might work out good. I have a single Seagate 8TB Archive SMR disk for my
backups, (using single disk ZFS pool). It works great, but not fast.

 

[nojohnny101]

I'll echo what @Arwen said. I went with the "lean but stable" approach with my backup solution after research and reading on the forum. I have never seen unexplained errors or "instability" while running 8GB of ECC RAM. I also am running RaidZ1 because while my backup server is located remotely, it is only a 5 minute drive away and I can live with the risk of it failing during a resolver or something of that nature. I chose RaidZ1 because I wanted to maximize space efficiency on the backup server.

I would also recommend for whatever board you get for the backup server, make sure it has IPMI. That will be indispensable when troubleshooting remotely.

 

[Arwen]

...
I would also recommend for whatever board you get for the backup server, make sure it has IPMI. That will be indispensable when troubleshooting remotely.

@HeloJunkie
Yes, I agree with @nojohnny101, get IPMI if at all possible.

 

[HeloJunkie]

@styno and @Arwen - Thank you for your input. It is appreciated. My backup server is not remote, it sits in the same office where I am dispatched from so I see it all the time, so not too worried about IPMI although all of the SuperMicro boxes I have do have the IPMI built in already.

As to the Seagate hard drives, have you had any issues with them? I have heard horror stories about Seagate drives. I run only the WD Red drives myself, having just purchased an additional 6 - 8TB drives for less than $300 each. When I look at the Seagate drives, it looks like they are running about $229 each, so not a huge amount of savings over the Reds, but for a backup solution maybe worth a try, but not if their failure rate is too high.

Also, you both mentioned Z1 as a method to save space, and I guess as a backup solution, that could be a way to save some $$ as well, I just need to noodle on it as the thought of only a single parity drive makes me cringe. Again I realize that this is just a backup solution so it may be worth the risk.

 

[nojohnny101]

I have seagate 3TB drives (see sig) in my replication target box. I have had one die, it just dropped off completely, no warnings (can't find the thread, but I think I posted about this). They are about 6 months old.

I'm only one stat though, hardly a statistic.

 

[styno]

Oh no, I would never use 8TB drives in RaidZ1, not even for a backup server.

 

[HeloJunkie]

@styno - Agreed, I came to the same conclusion. I am running the 8TB drives in a Z2 configuration in a 6 drive vdev.