Hi
@0x0 welcome to the forums.
I am currently building a small freeNAS machine and I am planning to encrypt the HDDs.
I myself use encryption for one of my pools but please beware that encryption is a tool that can just as easily lock you out of your data as it can anyone trying to steal it. It it worth understanding exactly what FreeNAS encryption does and does not do.
What it does: FreeNAS encryption encrypts your pool by encrypting the underlying disks. In order to use the pool you must unlock it, thus unlocking the disks. Once unlocked the pool is available for use in shares etc and the data is accessible just as if you had not used encryption in the first place. The benefit of encryption is that if someone were to get access to your drives while locked (such as when the system is off) they could not access the data without your decryption keys and passphrase if you used one. Do note that the encryption keys are stored unencrypted on your boot device and without a passphrase the pool is automatically unlocked by your system. If this worries you, you should add a passphrase to your pool such that the key AND the passphrase are both required on reboot or after you manually lock the pool.
What it does not do: FreeNAS pool encryption does not protect your data while the pool is unlocked. It does not ensure data is encrypted while being sent to/from clients. It does not protect you from man-in-the-middle attacks, ransomeware, or a clever hacker getting access to your system while your pool is unlocked. FreeNAS pool encryption is intended to protect your data while "at rest". If someone stole your drives or you returned them your data is safe without your key and passphrase.
I'm planning to use 2 SSDs in RAID1
I'm going to nit here a little, but I promise it is ultimately helpful. FreeNAS uses ZFS and ZFS does not use
RAID1. ZFS is a software raid solution which stores your data in pools which are made of vdevs which are made of disks. You can stripe many vdevs into a pool to increase storage size. If a single vdev fails your entire pool fails. To add data safety vdevs are built using a variety of redundant arrays of disks.
mirror vdevs use 2 or more disks which contain identical copies.
RAIDZ1 vdevs strip data across all disks and can tolerate a single drive failure but more than a single drive failure brings down the vdev and thus your pool.
RAIDZ2 and
RAIDZ3 vdevs are just like
RAIDZ1 but can tolerate 2 and 3 drive failures respectively.
Using the correct terminology helps prevent miscommunicating on the forums. Which is why I nit over the wording. I assume since you're referring to only two disks you mean that you'd use a
mirrored vdev for your data pool.
If you haven't already you may find it interesting to check out the resources section of these forums. There are a lot of useful discussions there regarding terminology and how FreeNAS works.
Now I'm wondering what would happen if the SSD died? Am I just screwed then? Or could I just install freeNAS onto a new SSD, replace it with the old one and all my data can be accessed again and all my settings will be the same as before?
If you keep regular backups of your system configuration then yes, you can just replace the SSD, upload the config and you're off to the races with the exception of a few small things such as some easily regenerated ssh keys.
IMPORTANT NOTE: A system config backup DOES NOT back up any encryption keys in your system. You MUST back those up immediately upon creation or changes. The User Guide provides excellent advice regarding this.
So I'm wondering if I should buy another SSD and put the two in RAID1 or if there is maybe a way of backing the SSD up to a USB flash drive once a week or somehting like that.
Many people
mirror their boot devices to provide some additional protection against a drive failure and avoid the hassle of downtime and reinstalling the os.
Should be OS drive be redundant when using encryption?
To answer your posts main question, if managed properly using an encrypted pool does not put additional pressure on the need for redundant OS devices.
Some users might rightfully say that using redundant boot pools decreases the likelihood that you'll accidentally lose your encryption keys to your pool if you forget to back them up and the boot device dies. They are correct, and many users on these forums have lost ALL of their data because their boot device died in an unrecoverable way and took their encryption keys with them.
As correct as this argument is, I would strongly strongly strongly urge you NOT to rely on redundancy of your boot pools to keep your encryption keys safe in your build and management plan. If you have a need for an encrypted pool you should be sure you understand how it works, how to replace drives on an encrypted pool, how to export/import drives in an encrypted pool, and how and when to backup encryption keys before you make use of an encrypted pool. I spent well over a week creating and destroying test pools to make sure I understood encryption before I started using it. Since then I've spent hours and hours playing with edge cases and exploring how the GUI handles an encrypted pool and keys during disk replacement, import/export, etc. There are quirks but from all of my testing the only way to keep your data safe is to always keep backups of your keys and to understand which operations automatically change your keys and thus require backing them up again.
Finally I'll leave you with this bit of advice that is often forgotten. No level of redundancy in a
vdev is a substitute for a backup. If your server catches fire, is stole, etc all backups on that machine are gone. An ideal backup system involves an on-site and off-site backup. It is up to you to decide what backup strategy fits your budget, risk tolerance, and data.
Sorry to ramble somewhat. I realize I mentioned a lot here that only scratches the surface. You'll find a lot more information on the forums about any specific thing. Also happy to answer any specific question about the above or have someone correct any mistakes I may have made.
