Learning about NAS

[Mclegendary]

Right now I have a very basic understanding of NAS software and hardware, so if anyone could link me to a good article explaining about how it works, file systems, RAID, and NAS hardware that would be awesome.

[Vitalius]

Hmm... where to start...

I can't think of articles that explain each of those off the top of my head, but I can sort of give a summary of each thing and probably google from there (me, not you). 

What is a NAS?

A NAS (Network Attached Storage) is just a bare bones server that is exclusively used for file storage over a network (that's the important bit that makes a NAS unique). There are NASes with more functionality than that, but they are more than just a normal NAS (NAS IN DISGUISE!)

What is a File System?

A File System is essentially how an operating system manages files on a storage device. i.e. how they are organized, what kind of error checking is used, whether they are compressed/encrypted or not, etc. Examples of file systems: NTFS, UFS, ZFS, CIFS,. 

NTFS is New Technology File System which is a Microsoft/Windows specific File System. UFS is Unified File System which is used generally by Linux and FreeBSD systems as is ZFS (Zetabyte File System) which is very powerful in that it utilizes check sums and built-in encryption (among other things) to make sure your data is correct and secure. 

CIFS is sort of special in that it is usually used for "over a network" sharing as it stands for "Common Internet File System" which basically lets it mount devices across a network and is usually used in Windows systems. Whereas, AFP (Apple Filing Protocol) and NFS (Network File System) are used in Macs and Linux machines respectively.

What is RAID?

RAID is called Redundant Array of Inexpensive Disks (originally at least) and there are 2 distinctly different types of RAID. Parity and non-parity. Non-parity RAID is RAID 0 and RAID 1.

RAID 0 isn't really RAID because it offers no redundancy (i.e. one of your disks die, you lose all your data on that RAID array), which is why it's 0 (as in, not). It only offers major performance increases but raises your chances of losing your data. RAID 1 is mirroring data perfectly (or as perfect as it can) between two drives and it is Redundant (i.e. one disk dies, the other lives along with all your data).

RAID 1 is storage expensive. Say you have two 4TB drives and you RAID 1 them. You "lose" 4TB of space effectively, but you gain integrity (your data is more safe). RAID 0 is integrity expensive. You lose safety in your data living should a drive die but you gain performance.

Parity RAID is a trade off between performance and storage while maintaining integrity (in certain situations). Parity calculations are done to record what data is on each disk and these calculations are stored on each disk. If one disk dies, it can be rebuilt using the calculations. This is CPU intensive and is always occurring as data is being written to the drives. 

The Parity RAID options are 5, 6, and 7. RAID 5 allows one disk to die and you keep your data. 6 allows two to die and 7 allows three to die. Then you would rebuild the array and rock on.... if everything worked fine. However, that isn't always the case. 

There is a complex reason why Parity RAID should never be used with consumer grade HDDs and you can find my post on that explanation here.

Parity RAID usually gives around 1-2 HDD's standalone read/write capability in terms of performance. i.e. most HDDs get 40-80 MB/s on average read/write performance, so at most you can expect between 40 and 160 MB/s from a RAID 5-7 array (it just depends on a lot of factors and it could be lower or higher than even that, but that's a good estimate imo).

I generally avoid it due to the CPU hit and the time consuming issue of rebuilding the array after a drive inevitably fails. I'd rather just have RAID 1 or do daily backups. That's just me though.

There are also two categories of RAID outside of Parity VS Non-parity, and that is Hardware VS Software RAID. Those two are self-explanatory in terms of what they are, however they are different from each other in terms of pros VS cons.

Hardware RAID is more expensive, since you need a RAID card, but as a trade-off, usually, the RAID card handles the Parity calculations for you instead of putting that on your CPU. However, it locks you into a certain product, because you usually need that specific RAID card to access your data. Your card dies and you don't have a replacement usually means you lost everything.

Software RAID is cheap (i.e. free). It puts the brunt of managing the RAID on the hardware (i.e. CPU for Parity), but you can usually just reinstall the OS or whatever program and re-import your stuff. 

One unique thing to also know is that ZFS uses a special kind of RAID called RAIDZ1, RAIDZ2, and RAIDZ3 (which are RAID 5, 6, and 7 respectively). There are slight differences between Z1 and 5 (along with the rest) but they aren't that important to know beyond "it makes them more efficient and redundant". 

Types of NAS hardware...

Now, NAS hardware is a strange term. A NAS is just a PC built for a specific purpose (i.e. sharing storage over a network). Now, there is hardware explicitly built for servers and storage of course, but you only need that in special situations. Most home users can rock on with normal PC parts that any PC could use.

But to understand what is important in NAS hardware, you need to understand what's important in your NAS OS. The OS decides the File System. The File System decides the performance requirement of the hardware. It can be as simple as FreeBSD/Linux UFS or Windows NTFS, to as complicated as FreeBSD/Linux ZFS. Some OS' have multiple options (such as Linux and FreeBSD with UFS and ZFS).

For UFS/NTFS/etc, you can basically just use a normal PC to host it. Anything really will work. The only consideration that needs to be made for those types of File Systems is the HDDs and the Controllers (i.e. the SATA controllers on the motherboard, or the RAID controllers if you buy one). Here is wpirobotbuilder's guide on SPoF which is very relevant to controllers. Most prefer the easier/simpler route in building a NAS simply for the sake of simplicity/ease of use. I can understand that.

For ZFS, you need lots of strong hardware. By strong, I mean reliable and powerful. So server enterprise hardware is preferred, but you can get by with prosumer hardware as well. You only need to go this route if your data is very important (i.e. work or personal life related, things you can't lose and go by unscathed). You can go this route if you just love being generally awesome and DIY.

What else is there to consider?

There are other things you can use to get the same or similar effect as a NAS. An example is iSCSI. It basically mounts a HDD in another machine on a network as if it's connected to the PC you are on. So, like, from your OS' perspective, the HDD may as well be connected directly to that PC even though it's not. This is useful for a variety of reasons (monitoring HDD health with SMART info access for example). 

A SAN (Storage Area Network) is not the same thing. A SAN is basically the inverse of a NAS (thus the acronym flip). It connects multiple storage devices on a network (say you have multiple NASes, you would connect them together with a SAN). 

How does it work?

 

I'm assuming when you ask this question, you mean "how does a NAS share storage over a network?"

Basically, the NAS runs the OS which handles the File System. Then it uses a protocol to share that storage over a network. Devices authenticate to that machine with their username and password and then they can access the files. 

More specifically, something like Windows Server shares storage out on a network with CIFS (the protocol used to share the storage) to share it's NTFS (the file system the OS uses to manage the files themselves) storage. Then someone with an account on this Server using CIFS authentication accesses the storage. 

Or FreeNAS (based on FreeBSD) handles ZFS to manage the files, then uses whatever network protocol to share the files in a similar manner as the Windows machine does above. AFP, NFS, or CIFS depending on the client machine (the one accessing the share).

 

Mclegendary, OK, I'm done. Let me know if you want to know anything else.

[alpenwasser]

One day we're going to need to start paying Vitalius for these kinds of posts.

Just two things:

 

UFS is Unified File System which is used generally by Linux and FreeBSD systems as is ZFS (Zetabyte File System) which is very powerful in that it utilizes check sums and built-in encryption (among other things) to make sure your data is correct and secure. 

UFS isn't really used on Linux. Since many vendors have made their

own extensions to UFS over the years and there isn't really a strict

standard for it, making an open implementation which can read/write all

different vendor versions of UFS isn't really feasible. There is some

compatibility, but not full.

Linux tends to use ext2,3,4, XFS, JFS or ReiserFS (with ext4 probably

being the most popular these days, and ext2 originally being inspired

by UFS).

Not very important within the context of this topic, but I thought I'd

mention it.

Secondly: Last I checked (i.e. last week ), the open versions of

ZFS do not yet have integrated encryption. The FreeBSD encryption

on ZFS uses GELI I believe, not an integrated ZFS encryption system

(same goes for FreeNAS' encryption feature according to what I've read).

It's on the feature list according to their github account, but not

yet implemented. Oracle's proprietary ZFS stack however does seem to

have this built-in encryption.

[Vitalius]

UFS isn't really used on Linux. Since many vendors have made their

own extensions to UFS over the years and there isn't really a strict

standard for it, making an open implementation which can read/write all

different vendor versions of UFS isn't really feasible. There is some

compatibility, but not full.

Linux tends to use ext2,3,4, XFS, JFS or ReiserFS (with ext4 probably

being the most popular these days, and ext2 originally being inspired

by UFS).

Not very important within the context of this topic, but I thought I'd

mention it.

Secondly: Last I checked (i.e. last week ), the open versions of

ZFS do not yet have integrated encryption. The FreeBSD encryption

on ZFS uses GELI I believe, not an integrated ZFS encryption system

(same goes for FreeNAS' encryption feature according to what I've read).

It's on the feature list according to their github account, but not

yet implemented. Oracle's proprietary ZFS stack however does seem to

have this built-in encryption.

I figured that was true about Linux, I just wasn't sure and figured it was close enough for a general explanation. 

I'm not sure why, but when I boot up FreeNAS and check the console, this is what I see for my drives that are mounted:

Apr 28 09:48:30 FREENAS kernel: GEOM_ELI: Device da0p1.eli created.Apr 28 09:48:30 FREENAS kernel: GEOM_ELI: Encryption: AES-XTS 256Apr 28 09:48:30 FREENAS kernel: GEOM_ELI:     Crypto: hardwareApr 28 09:48:30 FREENAS kernel: GEOM_ELI: Device da1p1.eli created.Apr 28 09:48:30 FREENAS kernel: GEOM_ELI: Encryption: AES-XTS 256Apr 28 09:48:30 FREENAS kernel: GEOM_ELI:     Crypto: hardwareApr 28 09:48:30 FREENAS kernel: GEOM_ELI: Device da2p1.eli created.Apr 28 09:48:30 FREENAS kernel: GEOM_ELI: Encryption: AES-XTS 256Apr 28 09:48:30 FREENAS kernel: GEOM_ELI:     Crypto: hardwareApr 28 09:48:30 FREENAS kernel: GEOM_ELI: Device da3p1.eli created.Apr 28 09:48:30 FREENAS kernel: GEOM_ELI: Encryption: AES-XTS 256Apr 28 09:48:30 FREENAS kernel: GEOM_ELI:     Crypto: hardware

So, while I know you can import these volumes directly into FreeNAS without a password (as I don't have password encryption set currently), it's encrypted to any non-FreeNAS machine. 

Maybe it's just a thing to FreeNAS with ZFS (and not ZFS explicitly), or I'm misunderstanding these console updates. Either way, it doesn't do much beyond preventing someone who doesn't know about FreeNAS accessing it (probably no one who would steal the physical drives honestly) and yeah, I forgot that isn't true for non-FreeNAS machines.

[alpenwasser]

I figured that was true about Linux, I just wasn't sure and figured it was close enough for a general explanation.

Yeah, as said, it's not that relevant within the context of this

thread, but since I was here anyway I thought I might as well

elaborate.

I'm not sure why, but when I boot up FreeNAS and check the console, this is what I see for my drives that are mounted:

Apr 28 09:48:30 FREENAS kernel: GEOM_ELI: Device da0p1.eli created.Apr 28 09:48:30 FREENAS kernel: GEOM_ELI: Encryption: AES-XTS 256Apr 28 09:48:30 FREENAS kernel: GEOM_ELI:     Crypto: hardwareApr 28 09:48:30 FREENAS kernel: GEOM_ELI: Device da1p1.eli created.Apr 28 09:48:30 FREENAS kernel: GEOM_ELI: Encryption: AES-XTS 256Apr 28 09:48:30 FREENAS kernel: GEOM_ELI:     Crypto: hardwareApr 28 09:48:30 FREENAS kernel: GEOM_ELI: Device da2p1.eli created.Apr 28 09:48:30 FREENAS kernel: GEOM_ELI: Encryption: AES-XTS 256Apr 28 09:48:30 FREENAS kernel: GEOM_ELI:     Crypto: hardwareApr 28 09:48:30 FREENAS kernel: GEOM_ELI: Device da3p1.eli created.Apr 28 09:48:30 FREENAS kernel: GEOM_ELI: Encryption: AES-XTS 256Apr 28 09:48:30 FREENAS kernel: GEOM_ELI:     Crypto: hardware

So, while I know you can import these volumes directly into FreeNAS without a password (as I don't have password encryption set currently), it's encrypted to any non-FreeNAS machine. 

Maybe it's just a thing to FreeNAS with ZFS (and not ZFS explicitly), or I'm misunderstanding these console updates. Either way, it doesn't do much beyond preventing someone who doesn't know about FreeNAS accessing it (probably no one who would steal the physical drives honestly) and yeah, I forgot that isn't true for non-FreeNAS machines.

Hm, interesting. I'd estimate that the "Crypto: hardware" thing refers

to encryption extensions on the CPU being used?

As for encryption's purpose: So, you can take your disks, move them

to another FreeNAS machine and you'll be able to access your data

without entering a password? And if you do enable password protection,

you'd need to enter one each time you boot the machine?

If you enable disk encryption in Linux (well, FreeBSD too last I tried

it), you will need to enter a password in order to be able to mount

the disks each time (not in any way related to your user account btw.,

completely separate thing). You could also use a key file instead of

a password (or both, I think), but I've never tried that so far.

[Vitalius]

Yeah, as said, it's not that relevant within the context of this

thread, but since I was here anyway I thought I might as well

elaborate.

Hm, interesting. I'd estimate that the "Crypto: hardware" thing refers

to encryption extensions on the CPU being used?

As for encryption's purpose: So, you can take your disks, move them

to another FreeNAS machine and you'll be able to access your data

without entering a password? And if you do enable password protection,

you'd need to enter one each time you boot the machine?

If you enable disk encryption in Linux (well, FreeBSD too last I tried

it), you will need to enter a password in order to be able to mount

the disks each time (not in any way related to your user account btw.,

completely separate thing). You could also use a key file instead of

a password (or both, I think), but I've never tried that so far.

Thanks for that.

Yes, that's what it means. For example, a CPU needs to be compatible with AES-NI encryption, or you may as well not use it (think encryption taking up all your CPU power). 

Yes. ZFS has an Auto Volume Import button that doesn't ask for a password no matter which system I plug the drives into as long as they are FreeNAS even with this AES encryption. That's not with the password encryption though.

Well, when you enable password encryption (they prefer you use a passphrase rather than a word), it creates a key file for you. Then you put a passphrase onto the key file and make a backup. This key file allows you to import the volumes into a system. Then you make a recovery key (which doesn't need the passphrase). You need either of those keys to import the volumes in FreeNAS, or you can't access them. Like, the passphrase key requires you to input the passphrase to import the volumes. The recovery key doesn't (so you can just auto-import like normal after you give it the key).

The first key file is what you are meant to use normally to import the volumes (which you only have to do once unless you unmount them later) and so can be lost or otherwise without worry. The recovery key file is the backup to that which you should keep safe (different system, maybe an encrypted USB drive in a drawer, etc).

The GUI makes all that a lot easier than it sounds. Literally "Check Passphrase Encryption" > "Input Passphrase to be used" > "Download both keys using the GUI (there are buttons)" And you are done.

At least according to the FreeNAS wiki. 

[alpenwasser]

Thanks for that.

Yes, that's what it means. For example, a CPU needs to be compatible with AES-NI encryption, or you may as well not use it (think encryption taking up all your CPU power). 

Yes. ZFS has an Auto Volume Import button that doesn't ask for a password no matter which system I plug the drives into as long as they are FreeNAS even with this AES encryption. That's not with the password encryption though.

Well, when you enable password encryption (they prefer you use a passphrase rather than a word), it creates a key file for you. Then you put a passphrase onto the key file and make a backup. This key file allows you to import the volumes into a system. Then you make a recovery key (which doesn't need the passphrase). You need either of those keys to import the volumes in FreeNAS, or you can't access them. Like, the passphrase key requires you to input the passphrase to import the volumes. The recovery key doesn't (so you can just auto-import like normal after you give it the key).

The first key file is what you are meant to use normally to import the volumes (which you only have to do once unless you unmount them later) and so can be lost or otherwise without worry. The recovery key file is the backup to that which you should keep safe (different system, maybe an encrypted USB drive in a drawer, etc).

The GUI makes all that a lot easier than it sounds. Literally "Check Passphrase Encryption" > "Input Passphrase to be used" > "Download both keys using the GUI (there are buttons)" And you are done.

At least according to the FreeNAS wiki.

Ah, yes, of course, passphrase is indeed the correct term I believe.

Sounds similar to LUKS in Linux, and there as well you can have GUI

wrappers around it which simplify the process (although once you've

done it a few times it's actually not that complicated anymore, but

getting started if you wish to do it all by hand is a rather involved

process as I've found. ).

The issue with the GUI frontends for encryption under Linux is that

often they might do stuff you don't want them to do to simplify the

process a bit, whereas you have full control over what's happening

from the CLI. But then again that's a pretty common tradeoff in the

UNIX-ish ecosystem.

[Vitalius]

-snip-

True.

For me, I'm just wondering if my data is really, technically, encrypted. 

I'm pretty sure, if it is, it's with some generic passphrase that all FreeNAS systems use to encrypt the volumes so that only another FreeNAS system can access it. Actually, I think that's a pretty cool way to do it honestly. It gives some meager form of security at least. 

I'm going to ask a question regarding this on the FreeNAS forums to see if I can get some insight into it.

[alpenwasser]

True.

For me, I'm just wondering if my data is really, technically, encrypted. 

I'm pretty sure, if it is, it's with some generic passphrase that all FreeNAS systems use to encrypt the volumes so that only another FreeNAS system can access it. Actually, I think that's a pretty cool way to do it honestly. It gives some meager form of security at least. 

I'm going to ask a question regarding this on the FreeNAS forums to see if I can get some insight into it.

Yeah, good question actually, rather important I'd say.

Be sure to report back, I'd be very interested in that answer.

[Vitalius]

Yeah, good question actually, rather important I'd say.

Be sure to report back, I'd be very interested in that answer.

Apparently what I'm seeing is the Swap being encrypted. Swap is always encrypted regardless of whether the volumes are or not. Volumes are encrypted with 128, whereas Swap is encrypted with 256. Not sure why. The Wiki and the person who answered my thread doesn't say.